From ahu@outpost.ds9a.nl Fri Apr 1 01:01:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 01:01:26 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3191Ju3017215 for ; Fri, 1 Apr 2005 01:01:19 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id CE4E33FC3; Fri, 1 Apr 2005 11:01:16 +0200 (CEST) Date: Fri, 1 Apr 2005 11:01:16 +0200 From: bert hubert To: Ben Greear Cc: hadi@cyberus.ca, "David S. Miller" , netdev Subject: Re: RFC: Redirect-Device Message-ID: <20050401090116.GA21361@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Ben Greear , hadi@cyberus.ca, "David S. Miller" , netdev References: <424C6089.1080507@candelatech.com> <1112303627.1073.71.camel@jzny.localdomain> <424C6B10.6030200@candelatech.com> <1112306031.1073.109.camel@jzny.localdomain> <424C7813.4000101@candelatech.com> <20050331143531.30f4eb8f.davem@davemloft.net> <424C7F96.4070002@candelatech.com> <1112311618.1090.20.camel@jzny.localdomain> <424C8E2C.70302@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424C8E2C.70302@candelatech.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, Mar 31, 2005 at 03:56:28PM -0800, Ben Greear wrote: > >I think you are more comfortable with using netdevices and ioctls and > >/proc. > > Definately. Ever tried to sniff a socket with ethereal? :) On loopback, all the time. I'm probably dense but I don't understand what problem you've solved with this interface. Could you elaborate a bit? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From pekkas@netcore.fi Fri Apr 1 01:28:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 01:28:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j319SqP5018568 for ; Fri, 1 Apr 2005 01:28:53 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j319SiR11426; Fri, 1 Apr 2005 12:28:44 +0300 Date: Fri, 1 Apr 2005 12:28:44 +0300 (EEST) From: Pekka Savola To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: RFC: Redirect-Device In-Reply-To: <424CDBA9.80703@candelatech.com> Message-ID: References: <424C6089.1080507@candelatech.com> <424CDBA9.80703@candelatech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Thu, 31 Mar 2005, Ben Greear wrote: >> Is there something in your problem statement I'm missing? > > That would be similar to what I'm doing, but I'm not really trying > to tunnel anything. I am trying to duplicate the behaviour of two > ethernet interfaces connected by an external cross-over cable, and I'm > trying to duplicate it at the network-device interface level so that > common tools (and my own tools) can treat these virtual interfaces > just like ethernet interfaces. Oh ok, what you seem to want is some kind of "Ethernet loopback++", but the "looped" packets should come back from a virtual interface instead of the same interface? Btw, does the kernel support traditional loopback, so that at the last stage, just before sending a packet on the wire, it would be pushed back. -- 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 herbert@gondor.apana.org.au Fri Apr 1 01:37:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 01:37:26 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j319bGoK019244 for ; Fri, 1 Apr 2005 01:37:17 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHIaL-00028u-00; Fri, 01 Apr 2005 19:37:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHIZt-0000N0-00; Fri, 01 Apr 2005 19:36:33 +1000 Date: Fri, 1 Apr 2005 19:36:33 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [NETLINK] cb_lock does not needs ref count on sk Message-ID: <20050401093633.GA32707@gondor.apana.org.au> References: <20050327091524.GA23215@elte.hu> <20050327133811.GA5569@elte.hu> <20050329104906.GA19836@gondor.apana.org.au> <20050329114926.GA14986@elte.hu> <20050330082640.GA8269@gondor.apana.org.au> <20050330170236.2bddf666.davem@davemloft.net> <20050331231922.GA26587@gondor.apana.org.au> <20050331232322.GA26693@gondor.apana.org.au> <20050331203313.57e1c5c3.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20050331203313.57e1c5c3.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here is a little optimisation for the cb_lock used by netlink_dump. While fixing that race earlier, I noticed that the reference count held by cb_lock is completely useless. The reason is that in order to obtain the protection of the reference count, you have to take the cb_lock. But the only way to take the cb_lock is through dereferencing the socket. That is, you must already possess a reference count on the socket before you can take advantage of the reference count held by cb_lock. As a corollary, we can remve the reference count held by the cb_lock. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.75 vs edited ===== --- 1.75/net/netlink/af_netlink.c 2005-04-01 16:25:14 +10:00 +++ edited/net/netlink/af_netlink.c 2005-04-01 19:30:22 +10:00 @@ -374,7 +374,6 @@ nlk->cb->done(nlk->cb); netlink_destroy_callback(nlk->cb); nlk->cb = NULL; - __sock_put(sk); } spin_unlock(&nlk->cb_lock); @@ -1100,7 +1099,6 @@ spin_unlock(&nlk->cb_lock); netlink_destroy_callback(cb); - __sock_put(sk); return 0; } @@ -1139,7 +1137,6 @@ return -EBUSY; } nlk->cb = cb; - sock_hold(sk); spin_unlock(&nlk->cb_lock); netlink_dump(sk); --Nq2Wo0NMKNjxTN9z-- From abhishek@pal.ece.iisc.ernet.in Fri Apr 1 01:40:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 01:41:01 -0800 (PST) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j319em4l019848 for ; Fri, 1 Apr 2005 01:40:54 -0800 Received: from pal.ece.iisc.ernet.in (pal.ece.iisc.ernet.in [144.16.64.149]) by ece.iisc.ernet.in (8.12.6/8.12.6) with ESMTP id j319cS8V023201 for ; Fri, 1 Apr 2005 15:08:28 +0530 (IST) (envelope-from abhishek@pal.ece.iisc.ernet.in) Received: by pal.ece.iisc.ernet.in (Postfix, from userid 1047) id 97D6331E59; Fri, 1 Apr 2005 15:10:40 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by pal.ece.iisc.ernet.in (Postfix) with ESMTP id 8C98A31E57 for ; Fri, 1 Apr 2005 15:10:40 +0530 (IST) Date: Fri, 1 Apr 2005 15:10:40 +0530 (IST) From: Abhishek Gupta To: netdev@oss.sgi.com Subject: Problem using HTB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abhishek@pal.ece.iisc.ernet.in Precedence: bulk X-list: netdev hello everybody I am working on a project related to QoS. I am using Linux's tc to configure my PC based router. My setup is as follows:- eth0 eth1 eth0 eth0 PC-based server|----------|PC-based Router|---------|PC-Based Client (using tc) * All my ethernet cards are on 100Mbps lan * Traffic generators being used: > UDP: gen_send @ about 1Mbps (http://www.citi.umich.edu/projects/qbone/generator.html) * Kernel versions being used:- > At Router: linux-2.4.20 > At Client and Server: Linux-2.4.7-10 * iproute2 versions:- > At Router: iproute2-ss020116 > At Client and Server: iproute2-ss010824 * Packets before leaving sever and client are being marked with DSCP bits using Linux's tc option; Marking is done based on two-tuples: destination ip address and port number * At the Router, I have the following configuration(only related to HTB) for eth0 and similar configuration exits for eth1 too: ---Router Configuration Starts Here----- DEV0='eth0' tc qdisc add dev $DEV0 parent 1: handle 2: htb default 30 tc class add dev $DEV0 parent 2: classid 2:1 htb rate 100kbit burst 100 \ ceil 100kbit tc class add dev $DEV0 parent 2:1 classid 2:10 htb rate 60kbit burst 100 \ ceil 100kbit tc class add dev $DEV0 parent 2:1 classid 2:20 htb rate 30kbit burst 60 \ ceil 100kbit tc class add dev $DEV0 parent 2:1 classid 2:30 htb rate 10kbit burst 80 \ ceil 100kbit tc qdisc add dev $DEV0 parent 2:10 gred setup DPs 3 default 3 grio tc qdisc change dev $DEV0 parent 2:10 gred limit 185000 min 11394 \ max 11395 burst 100 avpkt 128 bandwidth 100kbit DP 1 probability 1 \ prio 1 tc qdisc change dev $DEV0 parent 2:10 gred limit 17972 min 4748 max 9493 \ burst 50 avpkt 1000 bandwidth 100kbit DP 2 probability 0.01 prio 2 tc qdisc change dev $DEV0 parent 2:10 gred limit 4368 min 1796 max 3582 \ burst 25 avpkt 1000 bandwidth 100kbit DP 3 probability 0.01 prio 2 tc qdisc add dev $DEV0 parent 2:20 gred setup DPs 2 default 2 grio tc qdisc change dev $DEV0 parent 2:20 gred limit 52480 min 11311 \ max 11312 burst 60 avpkt 256 bandwidth 100kbit DP 1 probability 1 \ prio 1 tc qdisc change dev $DEV0 parent 2:20 gred limit 47184 min 5898 \ max 11796 burst 60 avpkt 1000 bandwidth 100kbit DP 2 probability 0.01 \ prio 2 tc qdisc add dev $DEV0 parent 2:30 gred setup DPs 1 default 1 grio tc qdisc change dev $DEV0 parent 2:30 gred limit 15728 min 1966 \ max 3932 burst 80 avpkt 200 bandwidth 100kbit DP 1 probability 0.04 \ prio 1 -----Router Configuration Ends Here------ Now, the problem is that when I am sending packets from just one UDP source(at server), I am getting outbound bit rate at eth0(of Router) as 12kbps even though I have ceiled the corresponding HTB class to 100kbps; similar thing happens when I have two UDP sources(both at server). So, even though I have configured for 100kbps, I am getting only 12kbps as the link speed. Please help me out. Abhishek ========================================================================= ABHISHEK GUPTA E-mail:abhishek_it_bhu@yahoo.co.in ========================================================================= From akpm@osdl.org Fri Apr 1 02:11:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 02:12:01 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31ABrpd020835 for ; Fri, 1 Apr 2005 02:11:53 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j31ABgs4005803 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Apr 2005 02:11:42 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j31ABXgB002239; Fri, 1 Apr 2005 02:11:34 -0800 Date: Fri, 1 Apr 2005 02:11:21 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: lukeross@sys3175.co.uk Subject: Fw: [Bugme-new] [Bug 4430] New: Virtual interfaces cannot have their own mtu Message-Id: <20050401021121.76da449b.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev hm, mtu is implemented in the device driver - you might be out of luck. Begin forwarded message: Date: Fri, 1 Apr 2005 02:01:19 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4430] New: Virtual interfaces cannot have their own mtu http://bugme.osdl.org/show_bug.cgi?id=4430 Summary: Virtual interfaces cannot have their own mtu Kernel Version: kernel-2.6.9-1.6_FC2 Status: NEW Severity: low Owner: acme@conectiva.com.br Submitter: lukeross@sys3175.co.uk Distribution: Fedora Core 2,3 Hardware Environment: Broadcom gigabit card using tg3 (Tyan s2885 onboard) Problem Description: eth0 and eth0:1 cannot have different mtus. I have a jumbo-frame capable switch with three devices plugged in. Two are PCs with jumbo-capable cards, the other is a wireless router which isn't, and hangs if either PC attempts to discover whether it can support jumbo frames. To get the benefit of jumbo frames between the two PCs, I tried to set up eth0:1 - on a different subnet to the wireless router - on both PCs, and set the mtu of the eth0:1 to 9000. However it is not possible to set the mtu for eth0:1 to 9000 without setting the mtu of eth0 to 9000 as well. Also noted in http://xcat.org/pipermail/xcat-user/2003-April/002358.html ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From hadi@cyberus.ca Fri Apr 1 03:03:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 03:03:35 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31B3SJF024059 for ; Fri, 1 Apr 2005 03:03:28 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DHJvw-0003ME-QW for netdev@oss.sgi.com; Fri, 01 Apr 2005 06:03:24 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHJvt-0007Pl-5B; Fri, 01 Apr 2005 06:03:21 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050401042106.GA27762@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112353398.1096.116.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 06:03:18 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2005-03-31 at 23:21, Herbert Xu wrote: > On Thu, Mar 31, 2005 at 08:37:21PM -0500, jamal wrote: > > > --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 > > +++ b/include/net/xfrm.h 2005-03-31 19:26:24.000000000 -0500 > > > > +/* callback structure passed from either netlink or pfkey */ > > +struct km_cb > > This name is a bit non-specific. > note: used by both SP/SA > > +{ > > + u32 data; /* callee to caller */ > > +}; > > Might as well put the event into it if we're going to keep this > structure. It'll help to shorten the function prototypes that > use it. > > And then we can just call this structure km_event. > sure. > > -extern void km_policy_expired(struct xfrm_policy *pol, int dir, int hard); > > +extern void km_policy_expired(struct xfrm_policy *pol, int dir, int event); > > Bogus prototype change. > agreed. > > +void xfrm_state_del_flush(struct xfrm_state *x) > > +{ > > + spin_lock_bh(&x->lock); > > + __xfrm_state_delete(x); > > + spin_unlock_bh(&x->lock); > > +} > > Sorry, I've changed my mind on this. This demonstrates why the > km_notify_* calls should be made from af_key/xfrm_user directly > instead of here. > > > Some of these functions are called internally as you discovered. > Since the notifications should only be generated by user requests, > calls to km_notify_* should be made at the places where the user > requests are handled, which is in the KM itself. > You need to be able to generate events at every km not just the one that generated the request. You also (most of the time) need to do it before affected object dissapears. So I am missing your point on this one. > Otherwise we'll have to add hacks like this to avoid the > notification for internal users. > I may be paranoid but i do this because x could be garbage collected way before i send the km user message - and i need it to use it to generate the event. I could take a copy of it ... > > void xfrm_state_delete(struct xfrm_state *x) > > { > > + int notif = 0; > > spin_lock_bh(&x->lock); > > + /* > > + * its unfortunate we have to freeze gc for this > > + * one moment - the other alternative would involve > > + * memcopying the state and then announcing that. > > + * think SMP where theres an iota where this could mess > > + * up - JHS > > + */ > > + spin_lock_bh(&xfrm_state_gc_lock); > > + if (x->km.state != XFRM_STATE_DEAD) > > + notif = 1; > > __xfrm_state_delete(x); > > + > > + if (notif) > > + km_state_notify(x, NULL, XFRM_SAP_DELETED); > > You've caught a real bug for af_key here. It's currently possible to > receive two delete notifications for the same state. Can you elaborate? > However, may I suggest that we code this differently. Make > __xfrm_state_delete return 0 if the state was really deleted > and -ESRCH otherwise. > > Then af_key/xfrm_user can simply call km_state_notify if the > return value was zero. > Again like i said: I need to tell every km user about the event, not just the originator. > BTW there is no need to grab xfrm_state_gc_lock. You've got > a reference count on the state from your caller. > Aha! I missed that - I will remove it. > > @@ -270,6 +319,10 @@ > > } > > } > > spin_unlock_bh(&xfrm_state_lock); > > + if (count) { > > + c.data = proto; > > + km_state_notify(NULL, &c, XFRM_SAP_FLUSHED); > > + } > > The notification should occur in all cases, even if count == 0. > Well, Masahide-San and I actually did discuss this and he was of the same opinion as you. My opinion: We only generate events when something happens, not just because someone issues a command. If flush was issued and there was nothing to flush why generate an event? does the PFKEY RFC say anything on this? > > @@ -957,8 +1020,9 @@ > > if (x->tunnel) { > > struct xfrm_state *t = x->tunnel; > > > > + /* XXX: Avoid announce?? */ > > if (atomic_read(&t->tunnel_users) == 2) > > - xfrm_state_delete(t); > > + xfrm_state_del_flush(t); > > That's right. We don't want to announce internal states to the world. > I will remove that comment. Thats achieved in the above code although the called funtion may not have the appropriate name . > > --- a/net/xfrm/xfrm_policy.c 2005-03-25 22:28:21.000000000 -0500 > > +++ b/net/xfrm/xfrm_policy.c 2005-03-31 19:26:24.000000000 -0500 > > @@ -298,7 +298,7 @@ > > * entry dead. The rule must be unlinked from lists to the moment. > > */ > > > > -static void xfrm_policy_kill(struct xfrm_policy *policy) > > +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir, int notif) > > Again, had you done the km_* calls from af_key/xfrm_user, then there'd > be no need to check notif here. > Refer to my comments above on being able to tell multiple managers about the events originated by one. Actually, given that this function is being called in many places i would say this is the exact central location you want to issue the announce from. > BTW, as it is you're announcing expired policies twice. Once as an > expire event and once as a delete event. This problem will also go > away if you move the km_* calls into af_key/xfrm_user. > Theres an announcement only when policy goes dead ;-> So only one not two. Same with the state as well. And again cant do it from af_key/xfrm_user if you want to have events generated by one km to be sent to another as well. Its pf_key that needs fixing. > > @@ -579,7 +586,7 @@ > > write_unlock_bh(&xfrm_policy_lock); > > > > if (old_pol) { > > - xfrm_policy_kill(old_pol); > > + xfrm_policy_kill(old_pol, dir, 1); > > } > > Please don't announce socket policies :) > I missed this one - sorry. > > --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 > > +++ b/net/xfrm/xfrm_user.c 2005-03-31 19:26:24.000000000 -0500 > > @@ -683,6 +683,10 @@ > > if (!xp) > > return err; > > > > + /* shouldnt excl be based on nlh flags?? > > + * Aha! this is anti-netlink really i.e more pfkey derived > > + * in netlink excl is a flag and you wouldnt need > > + * a type XFRM_MSG_UPDPOLICY - JHS */ > > Good point. Care to provide a patch to treat NEW + NLM_F_REPLACE > as UPD? > > > @@ -1053,10 +1057,10 @@ > > return -1; > > } > > > > -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) > > +static int xfrm_exp_state_notify(struct xfrm_state *x, u32 hard) > > How about calling this xfrm_notify_sa_expired for consistency? > Ditto for the policy function. sure. > > > +static int xfrm_notify_sa_flush(struct km_cb *c) > > +{ > > + struct xfrm_usersa_flush *p; > > + struct nlmsghdr *nlh; > > + struct sk_buff *skb; > > + unsigned char *b; > > + u32 ppid = 0; > > + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); > > + > > + skb = alloc_skb(len, GFP_ATOMIC); > > + if (skb == NULL) > > + return -ENOMEM; > > + b = skb->tail; > > + > > + nlh = NLMSG_PUT(skb, ppid, jiffies, > > If we're serious about providing sequence numbers then please > set it up as an atomic integer and use it throughout this file. > > Otherwise just pop zero in there. > I was just being lazy. I could send a 0 but whats wrong with using jiffies? > > + p = NLMSG_DATA(nlh); > > + if (!c) { > > + printk("xfrm_notify_sa_flush NULL km cb\n"); > > + p->proto = 0; > > Is anyone expected to call this with a NULL pointer? If not then > just let it OOPS. Same comment applies to the cb checks later on. > Will fix this. > > +static int xfrm_notify_sa( struct xfrm_state *x, int event, struct km_cb *c) > > > + if (event == XFRM_SAP_ADDED) > > + nlt = XFRM_MSG_NEWSA; > > + else if (event == XFRM_SAP_UPDATED) > > + nlt = XFRM_MSG_UPDSA; > > + else if (event == XFRM_SAP_DELETED) > > + nlt = XFRM_MSG_DELSA; > > + else > > + goto nlmsg_failure; > > Please use a switch. > sure. > > +static int xfrm_send_state_notify(struct xfrm_state *x, int event, struct km_cb *c) > > +{ > > + > > + if ((event == XFRM_SAP_ADDED) || > > + (event == XFRM_SAP_UPDATED) || > > + (event == XFRM_SAP_DELETED)) > > + return xfrm_notify_sa(x, event, c); > > + > > + if (event == XFRM_SAP_FLUSHED) > > + xfrm_notify_sa_flush(c); > > + > > + if (event != XFRM_SAP_EXPIRED) > > + return 0; > > Again a switch would be perfect. > Will fix this. BTW, Herbert, thanks for taking the time; appreciated. cheers, jamal From hadi@cyberus.ca Fri Apr 1 03:15:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 03:16:00 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31BFrHe024882 for ; Fri, 1 Apr 2005 03:15:54 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DHK7s-0005FE-I0 for netdev@oss.sgi.com; Fri, 01 Apr 2005 06:15:44 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHK7p-0008Tf-9u; Fri, 01 Apr 2005 06:15:41 -0500 Subject: Re: Resend: Re: PATCH: IPSEC acquire in presence of multiple managers From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: herbert@gondor.apana.org.au, "David S. Miller" , nakam@linux-ipv6.org, shinta.sugimoto@ericsson.com, netdev In-Reply-To: <20050331211340.0e6fbdfb.davem@davemloft.net> References: <1111795927.1089.749.camel@jzny.localdomain> <1111862131.1092.872.camel@jzny.localdomain> <20050331211340.0e6fbdfb.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112354137.1090.129.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 06:15:38 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 00:13, David S. Miller wrote: > On 26 Mar 2005 13:35:31 -0500 > jamal wrote: > > > Apologies, The last patch had some a glitch in the filename. Dave please > > apply this one instead > > Doesn't apply, in the current tree km_query() is marked static. > > Please regenerate your patch and sorry for not getting to this > sooner. Dave, I am combining this with the other event patch that is under discussion right now which i will end up sending to you. If you want it separate i could do that. cheers, jamal From herbert@gondor.apana.org.au Fri Apr 1 03:45:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 03:45:08 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Biv2i026089 for ; Fri, 1 Apr 2005 03:44:58 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHKZX-00032I-00; Fri, 01 Apr 2005 21:44:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHKYE-0000p4-00; Fri, 01 Apr 2005 21:42:58 +1000 Date: Fri, 1 Apr 2005 21:42:58 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050401114258.GA2932@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112353398.1096.116.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 06:03:18AM -0500, jamal wrote: > > > Some of these functions are called internally as you discovered. > > Since the notifications should only be generated by user requests, > > calls to km_notify_* should be made at the places where the user > > requests are handled, which is in the KM itself. > > You need to be able to generate events at every km not just the one that > generated the request. You also (most of the time) need to do it before I understand. However, that's not determined by where you put the km_notify call itself. Even when you call km_notify from af_key or xfrm_user it will notify every km in the system. It's the fact that we're calling km_notify instead of pfkey_broadcast or netlink_broadcast that's important, not the location. Having the km_notify call made in af_key/xfrm_user is convenient though for the reason I outlined above. > I may be paranoid but i do this because x could be garbage collected way > before i send the km user message - and i need it to use it to generate > the event. I could take a copy of it ... That's what the ref counter is for. > > You've caught a real bug for af_key here. It's currently possible to > > receive two delete notifications for the same state. > > Can you elaborate? Imagine you've got a KM that's trying to delete a state via af_key that's about to expire. If pfkey_delete looks up the state successfully, and then the timer triggers before the actual xfrm_state_delete, you will get one event generated by the timer and another by pfkey_delete. > Again like i said: I need to tell every km user about the event, not > just the originator. I'm suggesting that you add the km_notify calls to af_key and xfrm_user. That will take care of notifying everyone. > Well, Masahide-San and I actually did discuss this and he was of the > same opinion as you. My opinion: We only generate events when something > happens, not just because someone issues a command. If flush was issued > and there was nothing to flush why generate an event? does the PFKEY RFC > say anything on this? RFC 2367 says that: The messaging behavior for SADB_FLUSH is: Send an SADB_FLUSH message from a user process to the kernel. The kernel will return an SADB_FLUSH message to all listening sockets. As you can see, there is no exception for the case of an empty database. So my interpretation would be that a broadcast is needed. > Refer to my comments above on being able to tell multiple managers about > the events originated by one. May I also refer you to my comment above about this being achieved by calling km_notify, even if you do it from within af_key or xfrm_user :) > Actually, given that this function is being called in many places i > would say this is the exact central location you want to issue the > announce from. Try this as an exercise. List all the xfrm_policy_kills that need notifications and all those that don't, you will find that the former all originate from delete/flush commands in af_key/xfrm_user, while the latter originate from other callers. In other words, by placing the call in af_key/xfrm_user you simplify the logic and make it more maintainable. > > BTW, as it is you're announcing expired policies twice. Once as an > > expire event and once as a delete event. This problem will also go > > away if you move the km_* calls into af_key/xfrm_user. > > Theres an announcement only when policy goes dead ;-> > So only one not two. Same with the state as well. Well when the policy expires you will get one expire notification from the current timer code and a new one from your patch since the timer calls xfrm_policy_delete. See my point? By putting the call in xfrm_policy.c you have to be really careful in dividing the internal users which shouldn't generate notifications and the external users which should. By doing it in af_key/xfrm_user you can avoid all this work. > And again cant do it from af_key/xfrm_user if you want to have events > generated by one km to be sent to another as well. Its pf_key that needs > fixing. Well I must repeat that if you were calling km_notify from af_key/xfrm_user you will be sending these events to all km's no matter what their affiliation is :) > > If we're serious about providing sequence numbers then please > > set it up as an atomic integer and use it throughout this file. > > > > Otherwise just pop zero in there. > > I was just being lazy. I could send a 0 but whats wrong with using > jiffies? Using jiffies means that you can have two successive messages that share the same sequence number. It's not a big deal of course. But if we're going to indicate ordering, we might as well go the full length. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 1 03:47:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 03:47:20 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31BlDko026849 for ; Fri, 1 Apr 2005 03:47:13 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHKc0-000330-00; Fri, 01 Apr 2005 21:46:52 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHKbd-0000pi-00; Fri, 01 Apr 2005 21:46:29 +1000 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: [Bugme-new] [Bug 4430] New: Virtual interfaces cannot have their own mtu Cc: netdev@oss.sgi.com, lukeross@sys3175.co.uk Organization: Core In-Reply-To: <20050401021121.76da449b.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 01 Apr 2005 21:46:29 +1000 X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Andrew Morton wrote: > > the eth0:1 to 9000. However it is not possible to set the mtu for eth0:1 to 9000 > without setting the mtu of eth0 to 9000 as well. The solution is to set the mtu using ip route in addition to setting it on eth0, e.g., ip ro add x.0.0.0/8 via gw dev eth0 mtu 1500 src a.b.c.d ip ro add y.0.0.0/8 via gw2 dev eth0 mtu 9000 src e.f.g.h You still have to set the mtu on eth0 to 9000 since that determines the maximum receive size as well (MRU). -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Fri Apr 1 04:24:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 04:24:54 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31COmBE032004 for ; Fri, 1 Apr 2005 04:24:49 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DHLCf-0004Uu-JU for netdev@oss.sgi.com; Fri, 01 Apr 2005 07:24:45 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHLCb-0007cd-Jd; Fri, 01 Apr 2005 07:24:41 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050401114258.GA2932@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112358278.1096.160.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 07:24:38 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 06:42, Herbert Xu wrote: > On Fri, Apr 01, 2005 at 06:03:18AM -0500, jamal wrote: > > > > > Some of these functions are called internally as you discovered. > > > Since the notifications should only be generated by user requests, > > > calls to km_notify_* should be made at the places where the user > > > requests are handled, which is in the KM itself. > > > > You need to be able to generate events at every km not just the one that > > generated the request. You also (most of the time) need to do it before > > I understand. However, that's not determined by where you put the > km_notify call itself. Even when you call km_notify from af_key > or xfrm_user it will notify every km in the system. > > It's the fact that we're calling km_notify instead of pfkey_broadcast > or netlink_broadcast that's important, not the location. > > Having the km_notify call made in af_key/xfrm_user is convenient though > for the reason I outlined above. I think either scheme is fine really;-> I will definetely go back and consider the approach you are suggesting and see if it results into more maintanable code - then fair. Otherwise you realize its more work for me ;-> > > > You've caught a real bug for af_key here. It's currently possible to > > > receive two delete notifications for the same state. > > > > Can you elaborate? > > Imagine you've got a KM that's trying to delete a state via af_key that's > about to expire. If pfkey_delete looks up the state successfully, and > then the timer triggers before the actual xfrm_state_delete, you will > get one event generated by the timer and another by pfkey_delete. > I havent checked the state machine closely, but the following seems to make sense: The first thing that happens to delete the state/policy should win if the state/policy is transitioned to dead. > RFC 2367 says that: > > The messaging behavior for SADB_FLUSH is: > > Send an SADB_FLUSH message from a user process to the kernel. > > > > The kernel will return an SADB_FLUSH message to all listening > sockets. > > > > As you can see, there is no exception for the case of an empty database. > So my interpretation would be that a broadcast is needed. > Does it really make sense, Herbert? ;-> What is it that you just flushed that results in the event? The RFC is ambigous in my opinion. Look at what it says about deleting (same ambiguity). ---- 3.1.4 SADB_DELETE The SADB_DELETE message causes the kernel to delete a Security Association from the key table. The delete message consists of the base header followed by the association, and the source and destination sockaddrs in the address extension. The kernel deletes the security association matching the type, spi, source address, and destination address in the message. The message behavior for SADB_DELETE is as follows: Send an SADB_DELETE message from a user process to the kernel. The kernel returns the SADB_DELETE message to all listening processes. ------ So why would you generate an event in the case when you didnt delete anything? > > Actually, given that this function is being called in many places i > > would say this is the exact central location you want to issue the > > announce from. > > Try this as an exercise. List all the xfrm_policy_kills that need > notifications and all those that don't, you will find that the former > all originate from delete/flush commands in af_key/xfrm_user, while > the latter originate from other callers. > > In other words, by placing the call in af_key/xfrm_user you simplify > the logic and make it more maintainable. > I will go over the code and review. You may be absolutely right - thats the better approach to take. > BTW, as it is you're announcing expired policies twice. Once as an > > > expire event and once as a delete event. This problem will also go > > > away if you move the km_* calls into af_key/xfrm_user. > > > > Theres an announcement only when policy goes dead ;-> > > So only one not two. Same with the state as well. > > Well when the policy expires you will get one expire notification from > the current timer code and a new one from your patch since the timer > calls xfrm_policy_delete. > > See my point? By putting the call in xfrm_policy.c you have to be > really careful in dividing the internal users which shouldn't > generate notifications and the external users which should. By doing > it in af_key/xfrm_user you can avoid all this work. > Thats a bug really which is being exposed now. So it has nothing to do with the approach taken ;-> No expire should be sent if the policy has transitioned to dead. The bug is trivial to fix - and actually should be fixed regardless of this patch. > > I was just being lazy. I could send a 0 but whats wrong with using > > jiffies? > > Using jiffies means that you can have two successive messages that > share the same sequence number. It's not a big deal of course. But > if we're going to indicate ordering, we might as well go the full > length. > Good point. I will stay lazy and just set a 0 ;-> cheers, jamal From herbert@gondor.apana.org.au Fri Apr 1 04:37:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 04:37:50 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Cbcta032644 for ; Fri, 1 Apr 2005 04:37:39 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHLNt-0003Fl-00; Fri, 01 Apr 2005 22:36:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHLNS-0000ud-00; Fri, 01 Apr 2005 22:35:54 +1000 Date: Fri, 1 Apr 2005 22:35:54 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050401123554.GA3468@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112358278.1096.160.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 07:24:38AM -0500, jamal wrote: > > I think either scheme is fine really;-> I will definetely go back and > consider the approach you are suggesting and see if it results into > more maintanable code - then fair. Otherwise you realize its more work > for me ;-> Well I'm happy to code that part if you want :) > I havent checked the state machine closely, but the following seems to > make sense: > The first thing that happens to delete the state/policy should win if > the state/policy is transitioned to dead. Agreed. That's what we'll get if we make __xfrm_state_delete return success/failure. > So why would you generate an event in the case when you didnt delete anything? You're right that the RFC isn't very clear. Let's forget about the RFC and simply consider the usefulness of this. I contend that it is useful to see a FLUSH notification even when it flushed nothing. The reason is that this is an indication to all listeners that the database is completely empty. > > Well when the policy expires you will get one expire notification from > > the current timer code and a new one from your patch since the timer > > calls xfrm_policy_delete. > > > > See my point? By putting the call in xfrm_policy.c you have to be > > really careful in dividing the internal users which shouldn't > > generate notifications and the external users which should. By doing > > it in af_key/xfrm_user you can avoid all this work. > > Thats a bug really which is being exposed now. So it has nothing to do > with the approach taken ;-> You're right that it is a bug. However, this bug would've never triggered before because we simply didn't have delete policy notifications :) > No expire should be sent if the policy has transitioned to dead. The bug > is trivial to fix - and actually should be fixed regardless of this > patch. Yes the same fix to __xfrm_state_delete can be applied to xfrm_policy_delete. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Fri Apr 1 04:59:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 04:59:52 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Cxl2i001350 for ; Fri, 1 Apr 2005 04:59:48 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DHLkW-0001aH-N2 for netdev@oss.sgi.com; Fri, 01 Apr 2005 07:59:44 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHLkU-0002gZ-2l; Fri, 01 Apr 2005 07:59:42 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050401123554.GA3468@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112360379.1096.193.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 07:59:39 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 07:35, Herbert Xu wrote: > On Fri, Apr 01, 2005 at 07:24:38AM -0500, jamal wrote: > > > > I think either scheme is fine really;-> I will definetely go back and > > consider the approach you are suggesting and see if it results into > > more maintanable code - then fair. Otherwise you realize its more work > > for me ;-> > > Well I'm happy to code that part if you want :) > Let me review first. If it is valuable (we may have to leave expire alone). If i can get it done within next day or two fine - else if i get busyed out elsewhere i will hand it to you. Actually if you have plenty cycles and are very enthusiastic about this i can hand it to you right now ;-> Masahide and myself have some momentum going right now but i dont think this will be that disruptive. > You're right that the RFC isn't very clear. > > Let's forget about the RFC and simply consider the usefulness of this. > I contend that it is useful to see a FLUSH notification even when > it flushed nothing. > > The reason is that this is an indication to all listeners that the > database is completely empty. > Ok, let me hear from Masahide-san: If he still holds the same opinion as you then i will make the change. > > Thats a bug really which is being exposed now. So it has nothing to do > > with the approach taken ;-> > > You're right that it is a bug. However, this bug would've never triggered > before because we simply didn't have delete policy notifications :) > indeed. > > No expire should be sent if the policy has transitioned to dead. The bug > > is trivial to fix - and actually should be fixed regardless of this > > patch. > > Yes the same fix to __xfrm_state_delete can be applied to > xfrm_policy_delete. > agreed. cheers, jamal From hadi@cyberus.ca Fri Apr 1 05:18:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 05:18:49 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31DIif1002619 for ; Fri, 1 Apr 2005 05:18:45 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DHM2o-00010O-TF for netdev@oss.sgi.com; Fri, 01 Apr 2005 06:18:38 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHM2q-00055C-BD; Fri, 01 Apr 2005 08:18:40 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <1112360379.1096.193.camel@jzny.localdomain> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112360379.1096.193.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112361517.1089.197.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 08:18:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 07:59, jamal wrote: > Let me review first. If it is valuable (we may have to leave expire > alone). Ok, from a first review I would agree with you the result of doing it in km user will be more maintainable. It will result in a larger patch but in the long run more maintainable. > If i can get it done within next day or two fine - else if i get > busyed out elsewhere i will hand it to you. Let me code away at it - The offer still stands though ;-> cheers, jamal From nakam@linux-ipv6.org Fri Apr 1 06:20:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 06:20:05 -0800 (PST) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31EJxCd004700 for ; Fri, 1 Apr 2005 06:19:59 -0800 Received: from [192.168.2.196] (polaris.linux-ipv6.org [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id CD2CBFD9; Fri, 1 Apr 2005 23:19:47 +0900 (JST) Message-ID: <424D5881.4010005@linux-ipv6.org> Date: Fri, 01 Apr 2005 23:19:45 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca, Herbert Xu Cc: Patrick McHardy , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112360379.1096.193.camel@jzny.localdomain> In-Reply-To: <1112360379.1096.193.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello Jamal and Herbert, jamal wrote: > Let me review first. If it is valuable (we may have to leave expire > alone). If i can get it done within next day or two fine - else if i get > busyed out elsewhere i will hand it to you. Actually if you have plenty > cycles and are very enthusiastic about this i can hand it to you right > now ;-> Masahide and myself have some momentum going right now but i > dont think this will be that disruptive. > > >>You're right that the RFC isn't very clear. >> >>Let's forget about the RFC and simply consider the usefulness of this. >>I contend that it is useful to see a FLUSH notification even when >>it flushed nothing. >> >>The reason is that this is an indication to all listeners that the >>database is completely empty. >> > > > Ok, let me hear from Masahide-san: If he still holds the same opinion as > you then i will make the change. I think FLUSH should be sent in such case. Because flushing empty SADB/SPD is not an error (at current code), it is reasonable to broadcast it. Regards, -- Masahide NAKAMURA From dada1@cosmosbay.com Fri Apr 1 06:39:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 06:40:05 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31EdvAi005615 for ; Fri, 1 Apr 2005 06:39:58 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j31Edm5v023180; Fri, 1 Apr 2005 16:39:49 +0200 Message-ID: <424D5D34.4030800@cosmosbay.com> Date: Fri, 01 Apr 2005 16:39:48 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> In-Reply-To: <20050331221352.13695124.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Fri, 01 Apr 2005 16:39:49 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev David S. Miller a écrit : > On Thu, 17 Mar 2005 20:52:44 +0100 > Eric Dumazet wrote: > > >> - Move the spinlocks out of tr_hash_table[] to a fixed size table : Saves a lot of memory (particulary on UP) > > > If spinlock_t is a zero sized structure on UP, how can this save memory > on UP? :-) Because I deleted the __attribute__((__aligned__(8))) constraint on struct rt_hash_bucket. So sizeof(struct rt_hash_bucket) is now 4 instead of 8 on 32 bits architectures. May I remind you some people still use 32 bits CPU ? :-) By the way I have an updated patch... surviving very serious loads. > > Anyways, I think perhaps you should dynamically allocate this lock table. Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS) ? > Otherwise it looks fine. > > From Robert.Olsson@data.slu.se Fri Apr 1 07:53:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 07:53:12 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Fr6ax007887 for ; Fri, 1 Apr 2005 07:53:07 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j31Fr21P015728; Fri, 1 Apr 2005 17:53:02 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 43674EE2B1; Fri, 1 Apr 2005 17:53:02 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16973.28254.203492.400896@robur.slu.se> Date: Fri, 1 Apr 2005 17:53:02 +0200 To: Eric Dumazet Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <424D5D34.4030800@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Hello! Eric Dumazet writes: > By the way I have an updated patch... surviving very serious loads. Did you check for performance changes too? From what I understand we can add new lookup and cache miss in the fast packet path. > > Anyways, I think perhaps you should dynamically allocate this lock table. > > Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS) ? IMO we should be careful with adding new complexity the route hash. Also was this dynamic behavior gc_interval needed to fix the overflow? gc_interval is only sort of last resort timer. --ro From greearb@candelatech.com Fri Apr 1 08:29:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 08:29:27 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31GTLSX014658 for ; Fri, 1 Apr 2005 08:29:22 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j31GtHLH009322; Fri, 1 Apr 2005 08:55:17 -0800 Message-ID: <424D76DF.5070002@candelatech.com> Date: Fri, 01 Apr 2005 08:29:19 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "'netdev@oss.sgi.com'" Subject: Re: RFC: Redirect-Device References: <424C6089.1080507@candelatech.com> <424CDBA9.80703@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Pekka Savola wrote: > On Thu, 31 Mar 2005, Ben Greear wrote: > >>> Is there something in your problem statement I'm missing? >> >> >> That would be similar to what I'm doing, but I'm not really trying >> to tunnel anything. I am trying to duplicate the behaviour of two >> ethernet interfaces connected by an external cross-over cable, and I'm >> trying to duplicate it at the network-device interface level so that >> common tools (and my own tools) can treat these virtual interfaces >> just like ethernet interfaces. > > > Oh ok, what you seem to want is some kind of "Ethernet loopback++", but > the "looped" packets should come back from a virtual interface instead > of the same interface? Yes. In practice, I use a pair of virtual interfaces, so I send on one virtual and receive on the other. I use separate software to bridge, or the normal linux stacks to route, the packets to other interfaces, including real interfaces. > Btw, does the kernel support traditional loopback, so that at the last > stage, just before sending a packet on the wire, it would be pushed back. Not that I'm aware of. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dada1@cosmosbay.com Fri Apr 1 08:34:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 08:34:33 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31GYSnC015284 for ; Fri, 1 Apr 2005 08:34:29 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j31GYIaH026085; Fri, 1 Apr 2005 18:34:19 +0200 Message-ID: <424D780A.9000101@cosmosbay.com> Date: Fri, 01 Apr 2005 18:34:18 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Robert Olsson CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <16973.28254.203492.400896@robur.slu.se> In-Reply-To: <16973.28254.203492.400896@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Fri, 01 Apr 2005 18:34:19 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Robert Olsson a écrit : > Hello! > > Did you check for performance changes too? From what I understand > we can add new lookup and cache miss in the fast packet path. Performance is better because in case of stress (lot of incoming packets per second), the 1024 bytes of the locks are all in cache. As the size of the hash is divided by a 2 factor, rt_check_expire() and/or rt_garbage_collect() have to touch less cache lines. According to oprofile, an unpatched kernel was spending more than 15% of time in route.c routines, now I see ip_route_input() at 1.88% > > > > Anyways, I think perhaps you should dynamically allocate this lock table. > > > > Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS) ? > > IMO we should be careful with adding new complexity the route hash. > Also was this dynamic behavior gc_interval needed to fix the overflow? In my case yes, because I have huge route cache. > gc_interval is only sort of last resort timer. Actually not : gc_interval controls the rt_check_expire() to clean the hash table after use. All old enough entries can be deleted smoothly, on behalf of a timer tick (so network interrupts can still occur) I found it was better to adjust gc_interval to 1 (to let it fire every second and examine 1/300 table slots, or more if the dynamic behavior triggers), and ajust params so that rt_garbage_collect() doesnt run at all : rt_garbage_collect() can take forever to complete, blocking network trafic. Eric Dumazet From ak@muc.de Fri Apr 1 08:40:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 08:40:16 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Ge9g6015890 for ; Fri, 1 Apr 2005 08:40:10 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 97B16D033E; Fri, 1 Apr 2005 18:40:07 +0200 (CEST) To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: [RFC] netif_rx: receive path optimization References: <20050330132815.605c17d0@dxpl.pdx.osdl.net> <20050331120410.7effa94d@dxpl.pdx.osdl.net> <1112303431.1073.67.camel@jzny.localdomain> <424C6A98.1070509@hp.com> From: Andi Kleen Date: Fri, 01 Apr 2005 18:40:07 +0200 In-Reply-To: <424C6A98.1070509@hp.com> (Rick Jones's message of "Thu, 31 Mar 2005 13:24:40 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Rick Jones writes: > At the risk of again chewing on my toes (yum), if multiple CPUs are > pulling packets from the per-device queue there will be packet > reordering. HP-UX 10.0 did just that and it was quite nasty even at > low CPU counts (<=4). It was changed by HP-UX 10.20 (ca 1995) to > per-CPU queues with queue selection computed from packet headers (hash > the IP and TCP/UDP header to pick a CPU) It was called IPS for Inbound > Packet Scheduling. 11.0 (ca 1998) later changed that to "find where > the connection last ran and queue to that CPU" That was called TOPS - > Thread Optimized Packet Scheduling. We went over this a lot several years ago when Linux got multi threaded RX with softnet in 2.1. You might want to go over the archives. Some things that came out of it was a sender side TCP optimization to tolerate reordering without slowing down (works great with other Linux peers) and NAPI style polling mode (which was mostly designed for routing and still seems to have regressions for the client/server case :/) Something like TOPS was discussed, but afaik nobody ever implemented it. Of course benchmark guys do it manually by setting interrupt and scheduler affinity. -Andi From greearb@candelatech.com Fri Apr 1 08:58:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 08:59:02 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31GwuW4016989 for ; Fri, 1 Apr 2005 08:58:57 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j31HOoLH009680; Fri, 1 Apr 2005 09:24:51 -0800 Message-ID: <424D7DCC.5030202@candelatech.com> Date: Fri, 01 Apr 2005 08:58:52 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: hadi@cyberus.ca, "David S. Miller" , netdev Subject: Re: RFC: Redirect-Device References: <424C6089.1080507@candelatech.com> <1112303627.1073.71.camel@jzny.localdomain> <424C6B10.6030200@candelatech.com> <1112306031.1073.109.camel@jzny.localdomain> <424C7813.4000101@candelatech.com> <20050331143531.30f4eb8f.davem@davemloft.net> <424C7F96.4070002@candelatech.com> <1112311618.1090.20.camel@jzny.localdomain> <424C8E2C.70302@candelatech.com> <20050401090116.GA21361@outpost.ds9a.nl> In-Reply-To: <20050401090116.GA21361@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev bert hubert wrote: > On Thu, Mar 31, 2005 at 03:56:28PM -0800, Ben Greear wrote: > > >>>I think you are more comfortable with using netdevices and ioctls and >>>/proc. >> >>Definately. Ever tried to sniff a socket with ethereal? :) > > > On loopback, all the time. I'm probably dense but I don't understand what > problem you've solved with this interface. Could you elaborate a bit? It allows me to place a software bridge that can intercept all packets from user-space via raw packet sockets, and kernel space via registering an 'all' protocol on the device. Please note that to bridge in this manner I have to remove the IP protocol (set IP to 0.0.0.0), otherwise the IP stack can interfere with the bridging behaviour. By using a virtual pair of interfaces that are looped back, I can add an IP to the second virtual network interface that does not interfere with the two bridged interfaces (one physical, one redirect, both with 0.0.0.0 IP addresses). If there were an API to register handlers dynamically that act like the netpoll hook (ie, with ability to consume frames), then I would not have to remove the IP from the physical interface and I probably would not have had to create these redirect devices. But, when I was suggesting such a hook in the past, it was shot down because it could allow someone to write their own TCP stack, and the network guys did not want to allow this possibility. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From Robert.Olsson@data.slu.se Fri Apr 1 09:26:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 09:26:46 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31HQfZm018140 for ; Fri, 1 Apr 2005 09:26:42 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j31HQWQG025702; Fri, 1 Apr 2005 19:26:32 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 9CDC6EE2B1; Fri, 1 Apr 2005 19:26:32 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16973.33864.613333.389857@robur.slu.se> Date: Fri, 1 Apr 2005 19:26:32 +0200 To: Eric Dumazet Cc: Robert Olsson , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <424D780A.9000101@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <16973.28254.203492.400896@robur.slu.se> <424D780A.9000101@cosmosbay.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Eric Dumazet writes: > According to oprofile, an unpatched kernel was spending more than 15% of time in route.c routines, now I see ip_route_input() at 1.88% Would like to see absolute numbers for UP/SMP single flow and DoS to be confident. > I found it was better to adjust gc_interval to 1 (to let it fire every second and examine 1/300 table slots, or more if the dynamic behavior > triggers), and ajust params so that rt_garbage_collect() doesnt run at all : rt_garbage_collect() can take forever to complete, blocking > network trafic. I don't think you can depend on timer for GC solely. Timer tick is eternity for todays packet rates. You can distribute the GC load by allowing it to run more frequent this in combination with huge cache seems to be a very interesting approach given that you have memory. --ro From nakam@linux-ipv6.org Fri Apr 1 09:28:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 09:28:20 -0800 (PST) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31HSFxd018552 for ; Fri, 1 Apr 2005 09:28:16 -0800 Received: from [192.168.2.195] (polaris.linux-ipv6.org [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id BDA70AE5; Sat, 2 Apr 2005 02:28:09 +0900 (JST) Message-ID: <424D84A7.6060707@linux-ipv6.org> Date: Sat, 02 Apr 2005 02:28:07 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca, Herbert Xu Cc: Patrick McHardy , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events References: <1112319441.1089.83.camel@jzny.localdomain> In-Reply-To: <1112319441.1089.83.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Jamal and Herbert, jamal wrote: > Herbert et al, > > Ok, heres the final patch with all the changes discussed. > > include/linux/xfrm.h | 2 > include/net/xfrm.h | 29 ++++++- > net/key/af_key.c | 24 +++++- > net/xfrm/xfrm_policy.c | 25 ++++-- > net/xfrm/xfrm_state.c | 84 +++++++++++++++++++-- > net/xfrm/xfrm_user.c | 188 > ++++++++++++++++++++++++++++++++++++++++++++++++- > 6 files changed, 323 insertions(+), 29 deletions(-) > > I have tested this with both setkey and iproute2 (about 10 scenarios or > so). Masahide-san is doing a lot more thorough testing with key servers > as well. He has not tested this patch yet (time difference) but it is > based on the last one he tested. Short report: I've tested on this patched kernel and it works. - add/del/flush for SA/SP and allocspi/acquire/upd for SA through netlink socket - racoon runs fine (pfkey works for normal operation) both without and with opening netlink socket to listen Since we have discussion which is still going on about the patch, the code will be change and I'll need to test again anyway. Thanks, -- Masahide NAKAMURA From roland@topspin.com Fri Apr 1 09:53:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 09:54:00 -0800 (PST) Received: from exch-1.topspincom.com (webmail.topspin.com [12.162.17.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31HrqZc019816 for ; Fri, 1 Apr 2005 09:53:53 -0800 Received: from localhost.localdomain ([10.3.1.93]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Apr 2005 09:45:33 -0800 Received: by localhost.localdomain (Postfix, from userid 1113) id 7EA6C4FDF2; Fri, 1 Apr 2005 09:45:33 -0800 (PST) To: akpm@osdl.org Cc: linux-kernel@vger.kernel.org, openib-general@openib.org, netdev@oss.sgi.com, davem@davemloft.net Subject: [PATCH][4/3] IPoIB: document conversion to debugfs X-Message-Flag: Warning: May contain useful information References: <20053311936.XaQmN4N9new7dTCP@topspin.com> From: Roland Dreier Date: Fri, 01 Apr 2005 09:45:33 -0800 In-Reply-To: <20053311936.XaQmN4N9new7dTCP@topspin.com> (Roland Dreier's message of "Thu, 31 Mar 2005 19:36:12 -0800") Message-ID: <52r7hujsqq.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Apr 2005 17:45:33.0676 (UTC) FILETIME=[9AC0C2C0:01C536E2] X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Update IPoIB documentation now that multicast debugging files have moved from ipoibdebugfs to debugfs. Signed-off-by: Roland Dreier --- linux-export.orig/Documentation/infiniband/ipoib.txt 2005-03-31 19:07:01.000000000 -0800 +++ linux-export/Documentation/infiniband/ipoib.txt 2005-04-01 09:43:27.122520190 -0800 @@ -32,14 +32,13 @@ mcast_debug_level to 1. These parameters can be controlled at runtime through files in /sys/module/ib_ipoib/. - CONFIG_INFINIBAND_IPOIB_DEBUG also enables the "ipoib_debugfs" + CONFIG_INFINIBAND_IPOIB_DEBUG also enables files in the debugfs virtual filesystem. By mounting this filesystem, for example with - mkdir -p /ipoib_debugfs - mount -t ipoib_debugfs none /ipoib_debufs + mount -t debugfs none /sys/kernel/debug - it is possible to get statistics about multicast groups from the - files /ipoib_debugfs/ib0_mcg and so on. + it is possible to get statistics about munlticast groups from the + files /sys/kernel/debug/ipoib/ib0_mcg and so on. The performance impact of this option is negligible, so it is safe to enable this option with debug_level set to 0 for normal From rick.jones2@hp.com Fri Apr 1 10:55:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 10:56:03 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Itxgb022131 for ; Fri, 1 Apr 2005 10:55:59 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 29A4E1F36E7 for ; Fri, 1 Apr 2005 10:22:52 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id KAA01022 for ; Fri, 1 Apr 2005 10:22:51 -0800 (PST) Message-ID: <424D917B.2060108@hp.com> Date: Fri, 01 Apr 2005 10:22:51 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev Subject: Re: [RFC] netif_rx: receive path optimization References: <20050330132815.605c17d0@dxpl.pdx.osdl.net> <20050331120410.7effa94d@dxpl.pdx.osdl.net> <1112303431.1073.67.camel@jzny.localdomain> <424C6A98.1070509@hp.com> <1112305084.1073.94.camel@jzny.localdomain> <424C7CDC.8050801@hp.com> <1112312206.1096.25.camel@jzny.localdomain> <424C90DA.7030600@hp.com> <1112318229.1090.63.camel@jzny.localdomain> In-Reply-To: <1112318229.1090.63.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev >>The main idea behind TOPS and prior to that IPS was to spread-out >>the processing of packets across as many CPUs as we could, as "correctly" as we >>could. > > > Very very hard to do. Why do you say that? "Correct" can be defined as either the same CPU for each packet in a given flow (IPS) or the same CPU as last accessed the endpoint (TOPS). > Isnt MSI supposed to give you ability such that a > NIC can pick a CPU to interupt? That would help in a small way That gives the NIC the knowledge of how to direct to a CPU, but as you know does not tell it how to decide where. Since I doubt that the NIC wants to reach-out and touch connection state in the host (nor I suppose do we want it to either) the best a NIC with MSI could do would be IPS >>TOPS lets the process (I suppose the scheduler really) decide where some of the >>processing for the packet will happen - the part after the handoff. >> > > I think this last part should be easy to do - but perhaps the expense of > landing on the wrong CPU may override any benefits perceived. Unless one has a scheduler that likes to migrate processes, the chances of landing on the wrong CPU are minimal and shortlived, and overall, the chances of being right are greater than if not doing anything and sticking with the interrupt CPU. (Handwaving based on experience-driven intuition and a bit of math as one increases the CPU count) This is all on the premis that one is running with numNIC << numCPU. With numNIC == numCPU one does things as seen in certain networking-intensive benchmarks :) rick jones From shemminger@osdl.org Fri Apr 1 12:07:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 12:07:41 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31K7aJG024341 for ; Fri, 1 Apr 2005 12:07:36 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j31K7Rs4028918 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Apr 2005 12:07:27 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j31K7RLd030565; Fri, 1 Apr 2005 12:07:27 -0800 Date: Fri, 1 Apr 2005 12:07:27 -0800 From: Stephen Hemminger To: lartc@mailman.ds9a.nl, linux-kernel@vger.kernel.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [ANNOUNCE] iproute2 2.6.11-050330 Message-ID: <20050401120727.62700e8c@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev An updated version of the iproute2 utilities is available at: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.11-050330.tar.gz It supports the latest features from 2.6, but is backwards compatiable with 2.4. This update includes several bugfixes and build clean from the previous version (2.6.11-050314): [Jamal Hadi Salim] * Proper verison of iptables headers (from 1.3.1) * Set revision file in m_ipt * Fix action_util naming in mirred * don't call ll_init_map in mirred [Thomas Graf] * Warn about wildcard deletions and provide IFA_ADDRESS upon deletions to enforce prefix length validation for IPv4. * Fix netlink message alignment when the last routing attribute added has a data length not aligned to RTA_ALIGNTO. [Masahide NAKAMURA] * ipv6 xfrm allocspi and monitor support. [Stephen Hemminger] * include/linux/netfilter_ipv4/ip_tables.h dont include compiler.h because it isn't needed and not on all systems * Update rtnetlink.h and pkt_cls.h to be stripped versions of headers from 2.6.12-rc1 * switch to stack for netem tables * add -force option to batch mode * handle midline comments in batch mode * sum per cpu fields in lnstat correctly From sds@tycho.nsa.gov Fri Apr 1 12:15:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 12:15:29 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31KFLo9025229 for ; Fri, 1 Apr 2005 12:15:22 -0800 Received: from tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j31KBvhV026499; Fri, 1 Apr 2005 20:11:57 GMT Received: from moss-spartans.epoch.ncsc.mil (moss-spartans [144.51.25.121]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j31KG5Do015003; Fri, 1 Apr 2005 15:16:05 -0500 (EST) Subject: [PATCH] Fix SELinux for removal of i_sock From: Stephen Smalley To: "David S. Miller" , James Morris , lkml , netdev@oss.sgi.com, matthew@wil.cx Content-Type: text/plain Organization: National Security Agency Date: Fri, 01 Apr 2005 15:06:37 -0500 Message-Id: <1112385997.14481.192.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-14) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@tycho.nsa.gov Precedence: bulk X-list: netdev Hi, This patch against -bk eliminates the use of i_sock by SELinux as it appears to have been removed recently, breaking the build of SELinux in -bk. Simply replacing the i_sock test with an S_ISSOCK test would be unsafe in the SELinux code, as the latter will also return true for the inodes of socket files in the filesystem, not just the actual socket objects IIUC. Hence this patch reworks the SELinux code to avoid the need to apply such a test in the first place, part of which was obsoleted anyway by earlier changes to SELinux. Please apply. Signed-off-by: Stephen Smalley Signed-off-by: James Morris security/selinux/hooks.c | 21 +++------------------ 1 files changed, 3 insertions(+), 18 deletions(-) ===== security/selinux/hooks.c 1.93 vs edited ===== --- 1.93/security/selinux/hooks.c 2005-03-28 17:21:19 -05:00 +++ edited/security/selinux/hooks.c 2005-04-01 15:01:58 -05:00 @@ -877,18 +877,8 @@ static int inode_doinit_with_dentry(stru isec->initialized = 1; out: - if (inode->i_sock) { - struct socket *sock = SOCKET_I(inode); - if (sock->sk) { - isec->sclass = socket_type_to_security_class(sock->sk->sk_family, - sock->sk->sk_type, - sock->sk->sk_protocol); - } else { - isec->sclass = SECCLASS_SOCKET; - } - } else { + if (isec->sclass == SECCLASS_FILE) isec->sclass = inode_mode_to_security_class(inode->i_mode); - } if (hold_sem) up(&isec->sem); @@ -2979,18 +2969,15 @@ out: static void selinux_socket_post_create(struct socket *sock, int family, int type, int protocol, int kern) { - int err; struct inode_security_struct *isec; struct task_security_struct *tsec; - err = inode_doinit(SOCK_INODE(sock)); - if (err < 0) - return; isec = SOCK_INODE(sock)->i_security; tsec = current->security; isec->sclass = socket_type_to_security_class(family, type, protocol); isec->sid = kern ? SECINITSID_KERNEL : tsec->sid; + isec->initialized = 1; return; } @@ -3158,14 +3145,12 @@ static int selinux_socket_accept(struct if (err) return err; - err = inode_doinit(SOCK_INODE(newsock)); - if (err < 0) - return err; newisec = SOCK_INODE(newsock)->i_security; isec = SOCK_INODE(sock)->i_security; newisec->sclass = isec->sclass; newisec->sid = isec->sid; + newisec->initialized = 1; return 0; } -- Stephen Smalley National Security Agency From davem@davemloft.net Fri Apr 1 12:28:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 12:29:01 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31KSt7x029634 for ; Fri, 1 Apr 2005 12:28:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHSkM-0002UR-00; Fri, 01 Apr 2005 12:28:02 -0800 Date: Fri, 1 Apr 2005 12:28:02 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050401122802.7c71afbc.davem@davemloft.net> In-Reply-To: <424D5D34.4030800@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 01 Apr 2005 16:39:48 +0200 Eric Dumazet wrote: > > If spinlock_t is a zero sized structure on UP, how can this save memory > > on UP? :-) > > Because I deleted the __attribute__((__aligned__(8))) constraint on struct rt_hash_bucket. Right. > > Anyways, I think perhaps you should dynamically allocate this lock table. > > Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS) ? Even for NR_CPUS, I think the table should be dynamically allocated. It is a goal to eliminate all of these huge arrays in the static kernel image, which has grown incredibly too much in recent times. I work often to eliminate such things, let's not add new ones :-) From davem@davemloft.net Fri Apr 1 12:36:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 12:36:18 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31KaD6Z030336 for ; Fri, 1 Apr 2005 12:36:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHSrQ-0002Xi-00; Fri, 01 Apr 2005 12:35:20 -0800 Date: Fri, 1 Apr 2005 12:35:20 -0800 From: "David S. Miller" To: Stephen Smalley Cc: jmorris@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, matthew@wil.cx Subject: Re: [PATCH] Fix SELinux for removal of i_sock Message-Id: <20050401123520.7532528b.davem@davemloft.net> In-Reply-To: <1112385997.14481.192.camel@moss-spartans.epoch.ncsc.mil> References: <1112385997.14481.192.camel@moss-spartans.epoch.ncsc.mil> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 01 Apr 2005 15:06:37 -0500 Stephen Smalley wrote: > This patch against -bk eliminates the use of i_sock by SELinux as it > appears to have been removed recently, breaking the build of SELinux in > -bk. Simply replacing the i_sock test with an S_ISSOCK test would be > unsafe in the SELinux code, as the latter will also return true for the > inodes of socket files in the filesystem, not just the actual socket > objects IIUC. Hence this patch reworks the SELinux code to avoid the > need to apply such a test in the first place, part of which was > obsoleted anyway by earlier changes to SELinux. Please apply. > > Signed-off-by: Stephen Smalley > Signed-off-by: James Morris Applied, thanks Stephen. From dada1@cosmosbay.com Fri Apr 1 13:05:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:05:58 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31L5plG031537 for ; Fri, 1 Apr 2005 13:05:52 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j31L5csf030409; Fri, 1 Apr 2005 23:05:43 +0200 Message-ID: <424DB7A1.8090803@cosmosbay.com> Date: Fri, 01 Apr 2005 23:05:37 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> In-Reply-To: <20050401122802.7c71afbc.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Fri, 01 Apr 2005 23:05:44 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev David S. Miller a écrit : > On Fri, 01 Apr 2005 16:39:48 +0200 > Eric Dumazet wrote: > >>Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS) ? > > > Even for NR_CPUS, I think the table should be dynamically allocated. > > It is a goal to eliminate all of these huge arrays in the static > kernel image, which has grown incredibly too much in recent times. > I work often to eliminate such things, let's not add new ones :-) You mean you prefer : static spinlock_t *rt_hash_lock ; /* rt_hash_lock = alloc_memory_at_boot_time(...) */ instead of static spinlock_t rt_hash_lock[RT_HASH_LOCK_SZ] ; In both cases, memory is taken from lowmem, and size of kernel image is roughly the same (bss section takes no space in image) Then the runtime cost is more expensive in the 'dynamic case' because of the extra indirection... ? From jheffner@psc.edu Fri Apr 1 13:05:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:06:03 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31L5ufx031548 for ; Fri, 1 Apr 2005 13:05:56 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j31LAYiG018305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 16:10:38 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j31L5nhA018741; Fri, 1 Apr 2005 16:05:50 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j31L5nZa018738; Fri, 1 Apr 2005 16:05:49 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Fri, 1 Apr 2005 16:05:49 -0500 (EST) From: John Heffner To: davem@davemloft.net, netdev@oss.sgi.com Subject: [PATCH] skb pcount with MTU discovery Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev The problem is that when doing MTU discovery, the too-large segments in the write queue will be calculated as having a pcount of >1. When tcp_write_xmit() is trying to send, tcp_snd_test() fails the cwnd test when pcount > cwnd. The segments are eventually transmitted one at a time by keepalive, but this can take a long time. This patch checks if TSO is enabled when setting pcount. -John Signed-off-by: John Heffner ===== include/net/tcp.h 1.114 vs edited ===== --- 1.114/include/net/tcp.h 2005-03-31 11:51:09 -05:00 +++ edited/include/net/tcp.h 2005-04-01 14:44:13 -05:00 @@ -1470,19 +1470,20 @@ tcp_minshall_check(tp)))); } -extern void tcp_set_skb_tso_segs(struct sk_buff *, unsigned int); +extern void tcp_set_skb_tso_segs(struct sock *, struct sk_buff *); /* This checks if the data bearing packet SKB (usually sk->sk_send_head) * should be put on the wire right now. */ -static __inline__ int tcp_snd_test(const struct tcp_sock *tp, +static __inline__ int tcp_snd_test(struct sock *sk, struct sk_buff *skb, unsigned cur_mss, int nonagle) { + struct tcp_sock *tp = tcp_sk(sk); int pkts = tcp_skb_pcount(skb); if (!pkts) { - tcp_set_skb_tso_segs(skb, tp->mss_cache_std); + tcp_set_skb_tso_segs(sk, skb); pkts = tcp_skb_pcount(skb); } @@ -1543,7 +1544,7 @@ if (skb) { if (!tcp_skb_is_last(sk, skb)) nonagle = TCP_NAGLE_PUSH; - if (!tcp_snd_test(tp, skb, cur_mss, nonagle) || + if (!tcp_snd_test(sk, skb, cur_mss, nonagle) || tcp_write_xmit(sk, nonagle)) tcp_check_probe_timer(sk, tp); } @@ -1561,7 +1562,7 @@ struct sk_buff *skb = sk->sk_send_head; return (skb && - tcp_snd_test(tp, skb, tcp_current_mss(sk, 1), + tcp_snd_test(sk, skb, tcp_current_mss(sk, 1), tcp_skb_is_last(sk, skb) ? TCP_NAGLE_PUSH : tp->nonagle)); } ===== net/ipv4/tcp_output.c 1.90 vs edited ===== --- 1.90/net/ipv4/tcp_output.c 2005-04-01 09:08:34 -05:00 +++ edited/net/ipv4/tcp_output.c 2005-04-01 14:45:27 -05:00 @@ -433,7 +433,7 @@ struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb = sk->sk_send_head; - if (tcp_snd_test(tp, skb, cur_mss, TCP_NAGLE_PUSH)) { + if (tcp_snd_test(sk, skb, cur_mss, TCP_NAGLE_PUSH)) { /* Send it out now. */ TCP_SKB_CB(skb)->when = tcp_time_stamp; tcp_tso_set_push(skb); @@ -446,9 +446,12 @@ } } -void tcp_set_skb_tso_segs(struct sk_buff *skb, unsigned int mss_std) +void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb) { - if (skb->len <= mss_std) { + struct tcp_sock *tp = tcp_sk(sk); + + if (skb->len <= tp->mss_cache_std || + !(sk->sk_route_caps & NETIF_F_TSO)) { /* Avoid the costly divide in the normal * non-TSO case. */ @@ -457,10 +460,10 @@ } else { unsigned int factor; - factor = skb->len + (mss_std - 1); - factor /= mss_std; + factor = skb->len + (tp->mss_cache_std - 1); + factor /= tp->mss_cache_std; skb_shinfo(skb)->tso_segs = factor; - skb_shinfo(skb)->tso_size = mss_std; + skb_shinfo(skb)->tso_size = tp->mss_cache_std; } } @@ -531,8 +534,8 @@ } /* Fix up tso_factor for both original and new SKB. */ - tcp_set_skb_tso_segs(skb, tp->mss_cache_std); - tcp_set_skb_tso_segs(buff, tp->mss_cache_std); + tcp_set_skb_tso_segs(sk, skb); + tcp_set_skb_tso_segs(sk, buff); if (TCP_SKB_CB(skb)->sacked & TCPCB_LOST) { tp->lost_out += tcp_skb_pcount(skb); @@ -607,7 +610,7 @@ * factor and mss. */ if (tcp_skb_pcount(skb) > 1) - tcp_set_skb_tso_segs(skb, tcp_skb_mss(skb)); + tcp_set_skb_tso_segs(sk, skb); return 0; } @@ -815,7 +818,7 @@ sk_stream_free_skb(sk, skb); } else { TCP_SKB_CB(skb)->seq += copy; - tcp_set_skb_tso_segs(skb, tp->mss_cache_std); + tcp_set_skb_tso_segs(sk, skb); } len += copy; @@ -824,7 +827,7 @@ __skb_insert(nskb, skb->prev, skb, &sk->sk_write_queue); sk->sk_send_head = nskb; - tcp_set_skb_tso_segs(nskb, tp->mss_cache_std); + tcp_set_skb_tso_segs(sk, nskb); /* We're ready to send. If this fails, the probe will * be resegmented into mss-sized pieces by tcp_write_xmit(). */ @@ -885,7 +888,7 @@ mss_now = tcp_current_mss(sk, 1); while ((skb = sk->sk_send_head) && - tcp_snd_test(tp, skb, mss_now, + tcp_snd_test(sk, skb, mss_now, tcp_skb_is_last(sk, skb) ? nonagle : TCP_NAGLE_PUSH)) { if (skb->len > mss_now) { @@ -1822,7 +1825,7 @@ tp->mss_cache = tp->mss_cache_std; } } else if (!tcp_skb_pcount(skb)) - tcp_set_skb_tso_segs(skb, tp->mss_cache_std); + tcp_set_skb_tso_segs(sk, skb); TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; From davem@davemloft.net Fri Apr 1 13:09:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:09:27 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31L9Nls032679 for ; Fri, 1 Apr 2005 13:09:23 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHTNY-0002m8-00; Fri, 01 Apr 2005 13:08:32 -0800 Date: Fri, 1 Apr 2005 13:08:32 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050401130832.1f972a3b.davem@davemloft.net> In-Reply-To: <424DB7A1.8090803@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> <424DB7A1.8090803@cosmosbay.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 01 Apr 2005 23:05:37 +0200 Eric Dumazet wrote: > You mean you prefer : > > static spinlock_t *rt_hash_lock ; /* rt_hash_lock = > alloc_memory_at_boot_time(...) */ > > instead of > > static spinlock_t rt_hash_lock[RT_HASH_LOCK_SZ] ; > > In both cases, memory is taken from lowmem, and size of kernel image > is roughly the same (bss section takes no space in image) In the former case the kernel image the bootloader has to load is smaller. That's important, believe it or not. It means less TLB entries need to be locked permanently into the MMU on certain platforms. From davem@davemloft.net Fri Apr 1 13:11:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:11:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31LBaXI000825 for ; Fri, 1 Apr 2005 13:11:36 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHTPh-0002mS-00; Fri, 01 Apr 2005 13:10:45 -0800 Date: Fri, 1 Apr 2005 13:10:45 -0800 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: [PATCH] skb pcount with MTU discovery Message-Id: <20050401131045.4e558f65.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Apr 2005 16:05:49 -0500 (EST) John Heffner wrote: > The problem is that when doing MTU discovery, the too-large segments in > the write queue will be calculated as having a pcount of >1. When > tcp_write_xmit() is trying to send, tcp_snd_test() fails the cwnd test > when pcount > cwnd. > > The segments are eventually transmitted one at a time by keepalive, but > this can take a long time. > > This patch checks if TSO is enabled when setting pcount. Why isn't the MSS properly updated at this point in time? If it were, the pcount setting would do the right thing. That's how this code is supposed to work. From jheffner@psc.edu Fri Apr 1 13:23:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:23:13 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31LN5Pf001621 for ; Fri, 1 Apr 2005 13:23:06 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j31LRi33009348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 16:27:48 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j31LMxdx018810; Fri, 1 Apr 2005 16:22:59 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j31LMx4H018807; Fri, 1 Apr 2005 16:22:59 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Fri, 1 Apr 2005 16:22:59 -0500 (EST) From: John Heffner To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [PATCH] skb pcount with MTU discovery In-Reply-To: <20050401131045.4e558f65.davem@davemloft.net> Message-ID: References: <20050401131045.4e558f65.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev On Fri, 1 Apr 2005, David S. Miller wrote: > On Fri, 1 Apr 2005 16:05:49 -0500 (EST) > John Heffner wrote: > > > The problem is that when doing MTU discovery, the too-large segments in > > the write queue will be calculated as having a pcount of >1. When > > tcp_write_xmit() is trying to send, tcp_snd_test() fails the cwnd test > > when pcount > cwnd. > > > > The segments are eventually transmitted one at a time by keepalive, but > > this can take a long time. > > > > This patch checks if TSO is enabled when setting pcount. > > Why isn't the MSS properly updated at this point in time? > If it were, the pcount setting would do the right thing. > > That's how this code is supposed to work. The problem occurs when TSO is disabled. Common case, start out with mss of 8948. Send 2 segments; neither are acknowledged, and we receive an ICMP can't fragment indicating a pmtu of 1500 so mss is set down to 1448. Now tcp_set_skb_tso_segs() sets tso_segs to 6, so tcp_snd_test thinks we are doing TSO and will send the full 6 mss, and fails the cwnd test since cwnd == 2. -John From colin@colino.net Fri Apr 1 13:28:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:28:11 -0800 (PST) Received: from paperstreet.colino.net (colino.net [213.41.131.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31LS3F5002218 for ; Fri, 1 Apr 2005 13:28:04 -0800 Received: by paperstreet.colino.net (Postfix, from userid 1015) id 3D0C3101D9; Fri, 1 Apr 2005 23:27:52 +0200 (CEST) Received: from jack.colino.net (jack.colino.net [192.168.0.11]) by paperstreet.colino.net (Postfix) with ESMTP id 974A9101A2; Fri, 1 Apr 2005 23:27:49 +0200 (CEST) Date: Fri, 1 Apr 2005 23:27:47 +0200 From: Colin Leroy To: David Brownell Cc: linux-usb-devel@lists.sourceforge.net, Andrew Morton , Jeroen Vreeken , netdev@oss.sgi.com Subject: Re: [linux-usb-devel] [PATCH] PM support for zd1201 Message-ID: <20050401232747.3f9ed365@jack.colino.net> In-Reply-To: <200504011030.57978.david-b@pacbell.net> References: <20050330144423.0dde5b71@jack.colino.net> <200504011030.57978.david-b@pacbell.net> X-Mailer: Sylpheed-Claws 1.9.6cvs18 (GTK+ 2.6.4; powerpc-unknown-linux-gnu) X-Face: Fy:*XpRna1/tz}cJ@O'0^:qYs:8b[Rg`*8,+o^[fI?<%5LeB,Xz8ZJK[r7V0hBs8G)*&C+XA0qHoR=LoTohe@7X5K$A-@cN6n~~J/]+{[)E4h'lK$13WQf$.R+Pi;E09tk&{t|;~dakRD%CLHrk6m!?gA,5|Sb=fJ=>[9#n1Bu8?VngkVM4{'^'V_qgdA.8yn3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev On 01 Apr 2005 at 10h04, David Brownell wrote: Hi, > Looked ok to me, other than needing to change "u32 state" into > a "pm_message_t message". And I'm not sure why "mac_enabled" > would be the right test, rather than maybe netif_running(). Here it is. Signed-off-by: Colin Leroy --- drivers/usb/net/zd1201.c.orig 2005-03-30 14:35:23.000000000 +0200 +++ drivers/usb/net/zd1201.c 2005-04-01 23:24:04.000000000 +0200 @@ -1896,12 +1896,50 @@ kfree(zd); } +#ifdef CONFIG_PM + +static int zd1201_suspend (struct usb_interface *interface, + pm_message_t message) +{ + struct zd1201 *zd = (struct zd1201 *)usb_get_intfdata(interface); + + netif_device_detach(zd->dev); + + zd->was_enabled = zd->mac_enabled; + + if (zd->was_enabled) + return zd1201_disable(zd); + else + return 0; +} + +static int zd1201_resume (struct usb_interface *interface) +{ + struct zd1201 *zd = (struct zd1201 *)usb_get_intfdata(interface); + + netif_device_attach(zd->dev); + + if (zd->was_enabled) + return zd1201_enable(zd); + else + return 0; +} + +#else + +#define zd1201_suspend NULL +#define zd1201_resume NULL + +#endif + struct usb_driver zd1201_usb = { .owner = THIS_MODULE, .name = "zd1201", .probe = zd1201_probe, .disconnect = zd1201_disconnect, .id_table = zd1201_table, + .suspend = zd1201_suspend, + .resume = zd1201_resume, }; static int __init zd1201_init(void) --- drivers/usb/net/zd1201.h.orig 2005-03-30 14:35:36.000000000 +0200 +++ drivers/usb/net/zd1201.h 2005-03-30 14:24:33.000000000 +0200 @@ -46,6 +46,7 @@ char essid[IW_ESSID_MAX_SIZE+1]; int essidlen; int mac_enabled; + int was_enabled; int monitor; int encode_enabled; int encode_restricted; From dada1@cosmosbay.com Fri Apr 1 13:43:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 13:43:58 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31LhqNT003067 for ; Fri, 1 Apr 2005 13:43:53 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j31Lhd6I031012; Fri, 1 Apr 2005 23:43:45 +0200 Message-ID: <424DC08A.3020204@cosmosbay.com> Date: Fri, 01 Apr 2005 23:43:38 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> <424DB7A1.8090803@cosmosbay.com> <20050401130832.1f972a3b.davem@davemloft.net> In-Reply-To: <20050401130832.1f972a3b.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Fri, 01 Apr 2005 23:43:45 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev David S. Miller a écrit : > On Fri, 01 Apr 2005 23:05:37 +0200 > Eric Dumazet wrote: > > >>You mean you prefer : >> >>static spinlock_t *rt_hash_lock ; /* rt_hash_lock = >>alloc_memory_at_boot_time(...) */ >> >>instead of >> >>static spinlock_t rt_hash_lock[RT_HASH_LOCK_SZ] ; >> >>In both cases, memory is taken from lowmem, and size of kernel image >>is roughly the same (bss section takes no space in image) > > > In the former case the kernel image the bootloader has to > load is smaller. That's important, believe it or not. It > means less TLB entries need to be locked permanently into > the MMU on certain platforms. > > OK thanks for this clarification. I changed to : #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) /* * Instead of using one spinlock for each rt_hash_bucket, we use a table of spinlocks * The size of this table is a power of two and depends on the number of CPUS. */ #if NR_CPUS >= 32 #define RT_HASH_LOCK_SZ 4096 #elif NR_CPUS >= 16 #define RT_HASH_LOCK_SZ 2048 #elif NR_CPUS >= 8 #define RT_HASH_LOCK_SZ 1024 #elif NR_CPUS >= 4 #define RT_HASH_LOCK_SZ 512 #else #define RT_HASH_LOCK_SZ 256 #endif static spinlock_t *rt_hash_locks; # define rt_hash_lock_addr(slot) &rt_hash_locks[slot & (RT_HASH_LOCK_SZ - 1)] # define rt_hash_lock_init() { \ int i; \ rt_hash_locks = kmalloc(sizeof(spinlock_t) * RT_HASH_LOCK_SZ, GFP_KERNEL); \ if (!rt_hash_locks) panic("IP: failed to allocate rt_hash_locks\n"); \ for (i = 0; i < RT_HASH_LOCK_SZ; i++) \ spin_lock_init(&rt_hash_locks[i]); \ } #else # define rt_hash_lock_addr(slot) NULL # define rt_hash_lock_init() #endif Are you OK if I also use alloc_large_system_hash() to allocate rt_hash_table, instead of the current method ? This new method is used in net/ipv4/tcp.c for tcp_ehash and tcp_bhash and permits NUMA tuning. Eric From davem@davemloft.net Fri Apr 1 14:35:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 14:35:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31MZbk5005035 for ; Fri, 1 Apr 2005 14:35:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHUiw-0003Dx-00; Fri, 01 Apr 2005 14:34:42 -0800 Date: Fri, 1 Apr 2005 14:34:42 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050401143442.62ed8bb9.davem@davemloft.net> In-Reply-To: <424DC08A.3020204@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> <424DB7A1.8090803@cosmosbay.com> <20050401130832.1f972a3b.davem@davemloft.net> <424DC08A.3020204@cosmosbay.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 01 Apr 2005 23:43:38 +0200 Eric Dumazet wrote: > Are you OK if I also use alloc_large_system_hash() to allocate > rt_hash_table, instead of the current method ? This new method is used > in net/ipv4/tcp.c for tcp_ehash and tcp_bhash and permits NUMA tuning. Sure, that's fine. BTW, please line-wrap your emails. :-/ From herbert@gondor.apana.org.au Fri Apr 1 14:48:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 14:48:50 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31MmfmE005961 for ; Fri, 1 Apr 2005 14:48:42 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHUvx-0000Cu-00; Sat, 02 Apr 2005 08:48:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHUvP-00050C-00; Sat, 02 Apr 2005 08:47:35 +1000 From: Herbert Xu To: jheffner@psc.edu (John Heffner) Subject: Re: [PATCH] skb pcount with MTU discovery Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 02 Apr 2005 08:47:35 +1000 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev John Heffner wrote: > > Common case, start out with mss of 8948. Send 2 segments; neither are > acknowledged, and we receive an ICMP can't fragment indicating a pmtu of > 1500 so mss is set down to 1448. Now tcp_set_skb_tso_segs() sets tso_segs > to 6, so tcp_snd_test thinks we are doing TSO and will send the full 6 > mss, and fails the cwnd test since cwnd == 2. How about fixing tcp_snd_test directly like this? Of course all this will be moot once Dave finishes his TSO rewrite :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== include/net/tcp.h 1.107 vs edited ===== --- 1.107/include/net/tcp.h 2005-03-16 10:15:03 +11:00 +++ edited/include/net/tcp.h 2005-04-02 08:45:48 +10:00 @@ -1433,6 +1433,9 @@ pkts = tcp_skb_pcount(skb); } + if (!(tp->inet.sk.sk_route_caps & NETIF_F_TSO)) + pkts = 1; + /* RFC 1122 - section 4.2.3.4 * * We must queue if From dada1@cosmosbay.com Fri Apr 1 15:22:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:22:11 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NM2Gf007563 for ; Fri, 1 Apr 2005 15:22:03 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j31NLm32032417; Sat, 2 Apr 2005 01:21:54 +0200 Message-ID: <424DD78D.7070001@cosmosbay.com> Date: Sat, 02 Apr 2005 01:21:49 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> <424DB7A1.8090803@cosmosbay.com> <20050401130832.1f972a3b.davem@davemloft.net> <424DC08A.3020204@cosmosbay.com> <20050401143442.62ed8bb9.davem@davemloft.net> In-Reply-To: <20050401143442.62ed8bb9.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------090807070004040008080507" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Sat, 02 Apr 2005 01:21:55 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090807070004040008080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David S. Miller a écrit : > On Fri, 01 Apr 2005 23:43:38 +0200 > Eric Dumazet wrote: > > >>Are you OK if I also use alloc_large_system_hash() to allocate >>rt_hash_table, instead of the current method ? This new method is used >>in net/ipv4/tcp.c for tcp_ehash and tcp_bhash and permits NUMA tuning. > > > Sure, that's fine. > > BTW, please line-wrap your emails. :-/ > > :-) OK this patch includes everything... - Locking abstraction - rt_check_expire() fixes - New gc_interval_ms sysctl to be able to have timer gc_interval < 1 second - New gc_debug sysctl to let sysadmin tune gc - Less memory used by hash table (spinlocks moved to a smaller table) - sizing of spinlocks table depends on NR_CPUS - hash table allocated using alloc_large_system_hash() function - header fix for /proc/net/stat/rt_cache Thank you Eric --------------090807070004040008080507 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" diff -Nru linux-2.6.11/net/ipv4/route.c linux-2.6.11-ed/net/ipv4/route.c --- linux-2.6.11/net/ipv4/route.c 2005-03-02 08:38:38.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/route.c 2005-04-02 01:10:37.000000000 +0200 @@ -54,6 +54,8 @@ * Marc Boucher : routing by fwmark * Robert Olsson : Added rt_cache statistics * Arnaldo C. Melo : Convert proc stuff to seq_file + * Eric Dumazet : hashed spinlocks and rt_check_expire() fixes. + * : bugfix in rt_cpu_seq_show() * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -70,6 +72,7 @@ #include #include #include +#include #include #include #include @@ -107,12 +110,13 @@ #define IP_MAX_MTU 0xFFF0 #define RT_GC_TIMEOUT (300*HZ) +#define RT_GC_INTERVAL (RT_GC_TIMEOUT/10) /* rt_check_expire() scans 1/10 of the table each round */ static int ip_rt_min_delay = 2 * HZ; static int ip_rt_max_delay = 10 * HZ; static int ip_rt_max_size; static int ip_rt_gc_timeout = RT_GC_TIMEOUT; -static int ip_rt_gc_interval = 60 * HZ; +static int ip_rt_gc_interval = RT_GC_INTERVAL; static int ip_rt_gc_min_interval = HZ / 2; static int ip_rt_redirect_number = 9; static int ip_rt_redirect_load = HZ / 50; @@ -124,6 +128,7 @@ static int ip_rt_min_pmtu = 512 + 20 + 20; static int ip_rt_min_advmss = 256; static int ip_rt_secret_interval = 10 * 60 * HZ; +static int ip_rt_debug; static unsigned long rt_deadline; #define RTprint(a...) printk(KERN_DEBUG a) @@ -197,8 +202,38 @@ struct rt_hash_bucket { struct rtable *chain; - spinlock_t lock; -} __attribute__((__aligned__(8))); +}; + +#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) +/* + * Instead of using one spinlock for each rt_hash_bucket, we use a table of spinlocks + * The size of this table is a power of two and depends on the number of CPUS. + */ +#if NR_CPUS >= 32 +#define RT_HASH_LOCK_SZ 4096 +#elif NR_CPUS >= 16 +#define RT_HASH_LOCK_SZ 2048 +#elif NR_CPUS >= 8 +#define RT_HASH_LOCK_SZ 1024 +#elif NR_CPUS >= 4 +#define RT_HASH_LOCK_SZ 512 +#else +#define RT_HASH_LOCK_SZ 256 +#endif + + static spinlock_t *rt_hash_locks; +# define rt_hash_lock_addr(slot) &rt_hash_locks[slot & (RT_HASH_LOCK_SZ - 1)] +# define rt_hash_lock_init() { \ + int i; \ + rt_hash_locks = kmalloc(sizeof(spinlock_t) * RT_HASH_LOCK_SZ, GFP_KERNEL); \ + if (!rt_hash_locks) panic("IP: failed to allocate rt_hash_locks\n"); \ + for (i = 0; i < RT_HASH_LOCK_SZ; i++) \ + spin_lock_init(&rt_hash_locks[i]); \ + } +#else +# define rt_hash_lock_addr(slot) NULL +# define rt_hash_lock_init() +#endif static struct rt_hash_bucket *rt_hash_table; static unsigned rt_hash_mask; @@ -393,7 +428,7 @@ struct rt_cache_stat *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); + seq_printf(seq, "entries in_hit in_slow_tot in_slow_mc in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); return 0; } @@ -470,7 +505,7 @@ rth->u.dst.expires; } -static int rt_may_expire(struct rtable *rth, unsigned long tmo1, unsigned long tmo2) +static __inline__ int rt_may_expire(struct rtable *rth, unsigned long tmo1, unsigned long tmo2) { unsigned long age; int ret = 0; @@ -516,45 +551,93 @@ /* This runs via a timer and thus is always in BH context. */ static void rt_check_expire(unsigned long dummy) { - static int rover; - int i = rover, t; + static unsigned int rover; + static unsigned int effective_interval = RT_GC_INTERVAL; + static unsigned int cached_gc_interval = RT_GC_INTERVAL; + unsigned int i, goal; struct rtable *rth, **rthp; unsigned long now = jiffies; + unsigned int freed = 0 , t0; + u64 mult; - for (t = ip_rt_gc_interval << rt_hash_log; t >= 0; - t -= ip_rt_gc_timeout) { - unsigned long tmo = ip_rt_gc_timeout; - + if (cached_gc_interval != ip_rt_gc_interval) { /* ip_rt_gc_interval may have changed with sysctl */ + cached_gc_interval = ip_rt_gc_interval; + effective_interval = cached_gc_interval; + } + /* Computes the number of slots we should examin in this run : + * We want to perform a full scan every ip_rt_gc_timeout, and + * the timer is started every 'effective_interval' ticks. + * so goal = (number_of_slots) * (effective_interval / ip_rt_gc_timeout) + */ + mult = ((u64)effective_interval) << rt_hash_log; + do_div(mult, ip_rt_gc_timeout); + goal = (unsigned int)mult; + + i = atomic_read(&ipv4_dst_ops.entries) << 3; + if (i > ip_rt_max_size) { + goal <<= 1; /* be more aggressive */ + i >>= 1; + if (i > ip_rt_max_size) { + goal <<= 1; /* be more aggressive */ + i >>= 1; + if (i > ip_rt_max_size) { + goal <<= 1; /* be more aggressive */ + now++; /* give us one more tick (time) to do our job */ + } + } + } + if (goal > rt_hash_mask) goal = rt_hash_mask + 1; + t0 = goal; + i = rover; + for ( ; goal > 0; goal--) { i = (i + 1) & rt_hash_mask; rthp = &rt_hash_table[i].chain; - - spin_lock(&rt_hash_table[i].lock); - while ((rth = *rthp) != NULL) { - if (rth->u.dst.expires) { - /* Entry is expired even if it is in use */ - if (time_before_eq(now, rth->u.dst.expires)) { + if (*rthp) { + unsigned long tmo = ip_rt_gc_timeout; + spin_lock(rt_hash_lock_addr(i)); + while ((rth = *rthp) != NULL) { + if (rth->u.dst.expires) { + /* Entry is expired even if it is in use */ + if (time_before_eq(now, rth->u.dst.expires)) { + tmo >>= 1; + rthp = &rth->u.rt_next; + continue; + } + } else if (!rt_may_expire(rth, tmo, ip_rt_gc_timeout)) { tmo >>= 1; rthp = &rth->u.rt_next; continue; } - } else if (!rt_may_expire(rth, tmo, ip_rt_gc_timeout)) { - tmo >>= 1; - rthp = &rth->u.rt_next; - continue; - } - /* Cleanup aged off entries. */ - *rthp = rth->u.rt_next; - rt_free(rth); + /* Cleanup aged off entries. */ + *rthp = rth->u.rt_next; + freed++; + rt_free(rth); + } + spin_unlock(rt_hash_lock_addr(i)); } - spin_unlock(&rt_hash_table[i].lock); - /* Fallback loop breaker. */ if (time_after(jiffies, now)) break; } rover = i; - mod_timer(&rt_periodic_timer, now + ip_rt_gc_interval); + if (goal != 0) { + /* Not enough time to perform our job, try to adjust the timer. + * Firing the timer sooner means less planned work. + * We allow the timer to be 1/8 of the sysctl value. + */ + effective_interval = (effective_interval + cached_gc_interval/8)/2; + } + else { + /* We finished our job before time limit, try to increase the timer + * The limit is the sysctl value, we use a weight of 3/1 to + * increase slowly. + */ + effective_interval = (3*effective_interval + cached_gc_interval + 3)/4; + } + if (ip_rt_debug & 1) + printk(KERN_WARNING "rt_check_expire() : %u freed, goal=%u/%u, interval=%u ticks\n", freed, goal, t0, effective_interval); + mod_timer(&rt_periodic_timer, jiffies + effective_interval); } /* This can run from both BH and non-BH contexts, the latter @@ -570,11 +653,11 @@ get_random_bytes(&rt_hash_rnd, 4); for (i = rt_hash_mask; i >= 0; i--) { - spin_lock_bh(&rt_hash_table[i].lock); + spin_lock_bh(rt_hash_lock_addr(i)); rth = rt_hash_table[i].chain; if (rth) rt_hash_table[i].chain = NULL; - spin_unlock_bh(&rt_hash_table[i].lock); + spin_unlock_bh(rt_hash_lock_addr(i)); for (; rth; rth = next) { next = rth->u.rt_next; @@ -704,7 +787,7 @@ k = (k + 1) & rt_hash_mask; rthp = &rt_hash_table[k].chain; - spin_lock_bh(&rt_hash_table[k].lock); + spin_lock_bh(rt_hash_lock_addr(k)); while ((rth = *rthp) != NULL) { if (!rt_may_expire(rth, tmo, expire)) { tmo >>= 1; @@ -715,7 +798,7 @@ rt_free(rth); goal--; } - spin_unlock_bh(&rt_hash_table[k].lock); + spin_unlock_bh(rt_hash_lock_addr(k)); if (goal <= 0) break; } @@ -792,7 +875,7 @@ rthp = &rt_hash_table[hash].chain; - spin_lock_bh(&rt_hash_table[hash].lock); + spin_lock_bh(rt_hash_lock_addr(hash)); while ((rth = *rthp) != NULL) { if (compare_keys(&rth->fl, &rt->fl)) { /* Put it first */ @@ -813,7 +896,7 @@ rth->u.dst.__use++; dst_hold(&rth->u.dst); rth->u.dst.lastuse = now; - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); rt_drop(rt); *rp = rth; @@ -854,7 +937,7 @@ if (rt->rt_type == RTN_UNICAST || rt->fl.iif == 0) { int err = arp_bind_neighbour(&rt->u.dst); if (err) { - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); if (err != -ENOBUFS) { rt_drop(rt); @@ -895,7 +978,7 @@ } #endif rt_hash_table[hash].chain = rt; - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); *rp = rt; return 0; } @@ -962,7 +1045,7 @@ { struct rtable **rthp; - spin_lock_bh(&rt_hash_table[hash].lock); + spin_lock_bh(rt_hash_lock_addr(hash)); ip_rt_put(rt); for (rthp = &rt_hash_table[hash].chain; *rthp; rthp = &(*rthp)->u.rt_next) @@ -971,7 +1054,7 @@ rt_free(rt); break; } - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); } void ip_rt_redirect(u32 old_gw, u32 daddr, u32 new_gw, @@ -2569,6 +2652,23 @@ .strategy = &sysctl_jiffies, }, { + .ctl_name = NET_IPV4_ROUTE_GC_INTERVAL_MS, + .procname = "gc_interval_ms", + .data = &ip_rt_gc_interval, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, + }, + { + .ctl_name = NET_IPV4_ROUTE_GC_DEBUG, + .procname = "gc_debug", + .data = &ip_rt_debug, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = NET_IPV4_ROUTE_REDIRECT_LOAD, .procname = "redirect_load", .data = &ip_rt_redirect_load, @@ -2718,12 +2818,13 @@ int __init ip_rt_init(void) { - int i, order, goal, rc = 0; rt_hash_rnd = (int) ((num_physpages ^ (num_physpages>>8)) ^ (jiffies ^ (jiffies >> 7))); #ifdef CONFIG_NET_CLS_ROUTE + { + int order; for (order = 0; (PAGE_SIZE << order) < 256 * sizeof(struct ip_rt_acct) * NR_CPUS; order++) /* NOTHING */; @@ -2731,6 +2832,7 @@ if (!ip_rt_acct) panic("IP: failed to allocate ip_rt_acct\n"); memset(ip_rt_acct, 0, PAGE_SIZE << order); + } #endif ipv4_dst_ops.kmem_cachep = kmem_cache_create("ip_dst_cache", @@ -2741,39 +2843,24 @@ if (!ipv4_dst_ops.kmem_cachep) panic("IP: failed to allocate ip_dst_cache\n"); - goal = num_physpages >> (26 - PAGE_SHIFT); - if (rhash_entries) - goal = (rhash_entries * sizeof(struct rt_hash_bucket)) >> PAGE_SHIFT; - for (order = 0; (1UL << order) < goal; order++) - /* NOTHING */; - - do { - rt_hash_mask = (1UL << order) * PAGE_SIZE / - sizeof(struct rt_hash_bucket); - while (rt_hash_mask & (rt_hash_mask - 1)) - rt_hash_mask--; - rt_hash_table = (struct rt_hash_bucket *) - __get_free_pages(GFP_ATOMIC, order); - } while (rt_hash_table == NULL && --order > 0); - - if (!rt_hash_table) - panic("Failed to allocate IP route cache hash table\n"); - - printk(KERN_INFO "IP: routing cache hash table of %u buckets, %ldKbytes\n", - rt_hash_mask, - (long) (rt_hash_mask * sizeof(struct rt_hash_bucket)) / 1024); + rt_hash_table = (struct rt_hash_bucket *) + alloc_large_system_hash("IP route cache", + sizeof(struct rt_hash_bucket), + rhash_entries, + (num_physpages >= 128 * 1024) ? + (27 - PAGE_SHIFT) : + (29 - PAGE_SHIFT), + HASH_HIGHMEM, + &rt_hash_log, + &rt_hash_mask, + 0); - for (rt_hash_log = 0; (1 << rt_hash_log) != rt_hash_mask; rt_hash_log++) - /* NOTHING */; + memset(rt_hash_table, 0, rt_hash_mask * sizeof(struct rt_hash_bucket)); + rt_hash_lock_init(); + ipv4_dst_ops.gc_thresh = rt_hash_mask; + ip_rt_max_size = rt_hash_mask * 16; rt_hash_mask--; - for (i = 0; i <= rt_hash_mask; i++) { - spin_lock_init(&rt_hash_table[i].lock); - rt_hash_table[i].chain = NULL; - } - - ipv4_dst_ops.gc_thresh = (rt_hash_mask + 1); - ip_rt_max_size = (rt_hash_mask + 1) * 16; rt_cache_stat = alloc_percpu(struct rt_cache_stat); if (!rt_cache_stat) @@ -2819,7 +2906,7 @@ xfrm_init(); xfrm4_init(); #endif - return rc; + return 0; } EXPORT_SYMBOL(__ip_select_ident); diff -Nru linux-2.6.11/Documentation/filesystems/proc.txt linux-2.6.11-ed/Documentation/filesystems/proc.txt --- linux-2.6.11/Documentation/filesystems/proc.txt 2005-04-02 01:19:15.000000000 +0200 +++ linux-2.6.11-ed/Documentation/filesystems/proc.txt 2005-04-02 01:19:04.000000000 +0200 @@ -1709,12 +1709,13 @@ Writing to this file results in a flush of the routing cache. -gc_elasticity, gc_interval, gc_min_interval_ms, gc_timeout, gc_thresh +gc_elasticity, gc_interval_ms, gc_min_interval_ms, gc_timeout, gc_thresh, gc_debug --------------------------------------------------------------------- Values to control the frequency and behavior of the garbage collection algorithm for the routing cache. gc_min_interval is deprecated and replaced -by gc_min_interval_ms. +by gc_min_interval_ms. gc_interval is deprecated and replaced by +gc_interval_ms. gc_debug enables some printk() max_size diff -Nru linux-2.6.11/include/linux/sysctl.h linux-2.6.11-ed/include/linux/sysctl.h --- linux-2.6.11/include/linux/sysctl.h 2005-03-02 08:38:10.000000000 +0100 +++ linux-2.6.11-ed/include/linux/sysctl.h 2005-04-02 00:43:11.000000000 +0200 @@ -367,6 +367,8 @@ NET_IPV4_ROUTE_MIN_ADVMSS=17, NET_IPV4_ROUTE_SECRET_INTERVAL=18, NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19, + NET_IPV4_ROUTE_GC_INTERVAL_MS=20, + NET_IPV4_ROUTE_GC_DEBUG=21, }; enum --------------090807070004040008080507-- From tgraf@suug.ch Fri Apr 1 15:26:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:26:45 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NQbov008184 for ; Fri, 1 Apr 2005 15:26:38 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C77938A; Sat, 2 Apr 2005 01:26:12 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 354251C0EB; Sat, 2 Apr 2005 01:26:54 +0200 (CEST) Date: Sat, 2 Apr 2005 01:26:54 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCHSET] action statistics dumping fix & gnet_stats improvements Message-ID: <20050401232654.GJ3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Fixes a stupid bug I introduced in the last patchset which for some reason didn't get caught in the testing process. The other two patches change the behaviour of yet unused but likely use cases to what one would expect without reading the code. Please do a bk pull bk://kernel.bkbits.net/tgraf/net-2.6-tcf_exts This will update the following files: include/net/gen_stats.h | 3 ++- net/core/gen_stats.c | 48 +++++++++++++++++++++++++++++++----------------- net/sched/act_api.c | 2 ++ 3 files changed, 35 insertions(+), 18 deletions(-) through these ChangeSets: (05/04/01 1.2181.44.3) [NET]: Improve gnet_stats_* dumping logic to be less error prone The recent additions to make gnet_stats_* useable for action statistics dumping in two steps introcuded a few error prone assumptions which can easly be forgotten. This patch fixes this up by simplifying the process of adding new fields to struct gnet_dump or adding additional backward compatibility TLVs. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller (05/04/01 1.2181.44.2) [NET]: Allow dumping of application specific statistics if no primary TLV is used Although this case is hypothetical at the moment, more advanced actions are likely to need this in the future. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller (05/04/01 1.2181.44.1) [PKT_SCHED]: Properly return when no backward compatibility action statistics are to be dumped Fixes a stupid bug introcuded in my "Fix action statistics dumping in compatibility mode" patch, no clue why it actually worked without this fix. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller From tgraf@suug.ch Fri Apr 1 15:27:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:27:15 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NR9eD008422 for ; Fri, 1 Apr 2005 15:27:09 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id F1549F; Sat, 2 Apr 2005 01:26:46 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 5D8641C0EA; Sat, 2 Apr 2005 01:27:30 +0200 (CEST) Date: Sat, 2 Apr 2005 01:27:30 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/3] [PKT_SCHED]: Properly return when no backward compatibility action statistics are to be dumped Message-ID: <20050401232730.GK3086@postel.suug.ch> References: <20050401232654.GJ3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401232654.GJ3086@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/01 14:05:21+02:00 tgraf@suug.ch # [PKT_SCHED]: Properly return when no backward compatibility action statistics are to be dumped # # Fixes a stupid bug introcuded in my "Fix action statistics dumping in # compatibility mode" patch, no clue why it actually worked without this fix. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/sched/act_api.c # 2005/04/01 14:05:09+02:00 tgraf@suug.ch +2 -0 # [PKT_SCHED]: Properly return when no backward compatibility action statistics are to be dumped # diff -Nru a/net/sched/act_api.c b/net/sched/act_api.c --- a/net/sched/act_api.c 2005-04-02 01:18:40 +02:00 +++ b/net/sched/act_api.c 2005-04-02 01:18:40 +02:00 @@ -397,6 +397,8 @@ if (a->type == TCA_OLD_COMPAT) err = gnet_stats_start_copy_compat(skb, 0, TCA_STATS, TCA_XSTATS, h->stats_lock, &d); + else + return 0; } else err = gnet_stats_start_copy(skb, TCA_ACT_STATS, h->stats_lock, &d); From tgraf@suug.ch Fri Apr 1 15:27:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:27:47 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NRfgu008967 for ; Fri, 1 Apr 2005 15:27:41 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id A1105F; Sat, 2 Apr 2005 01:27:18 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 100F31C0EB; Sat, 2 Apr 2005 01:28:02 +0200 (CEST) Date: Sat, 2 Apr 2005 01:28:01 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/3] [NET]: Allow dumping of application specific statistics if no primary TLV is used Message-ID: <20050401232801.GL3086@postel.suug.ch> References: <20050401232654.GJ3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401232654.GJ3086@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/01 14:24:14+02:00 tgraf@suug.ch # [NET]: Allow dumping of application specific statistics if no primary TLV is used # # Although this case is hypothetical at the moment, more advanced actions are # likely to need this in the future. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/core/gen_stats.c # 2005/04/01 14:23:57+02:00 tgraf@suug.ch +7 -4 # [NET]: Allow dumping of application specific statistics if no primary TLV is used # # include/net/gen_stats.h # 2005/04/01 14:23:57+02:00 tgraf@suug.ch +2 -1 # [NET]: Allow dumping of application specific statistics if no primary TLV is used # diff -Nru a/include/net/gen_stats.h b/include/net/gen_stats.h --- a/include/net/gen_stats.h 2005-04-02 01:18:33 +02:00 +++ b/include/net/gen_stats.h 2005-04-02 01:18:33 +02:00 @@ -15,7 +15,8 @@ /* Backward compatability */ int compat_tc_stats; int compat_xstats; - struct rtattr * xstats; + void * xstats; + int xstats_len; struct tc_stats tc_stats; }; diff -Nru a/net/core/gen_stats.c b/net/core/gen_stats.c --- a/net/core/gen_stats.c 2005-04-02 01:18:33 +02:00 +++ b/net/core/gen_stats.c 2005-04-02 01:18:33 +02:00 @@ -177,8 +177,11 @@ int gnet_stats_copy_app(struct gnet_dump *d, void *st, int len) { - if (d->compat_xstats) - d->xstats = (struct rtattr *) d->skb->tail; + if (d->compat_xstats) { + d->xstats = st; + d->xstats_len = len; + } + return gnet_stats_copy(d, TCA_STATS_APP, st, len); } @@ -206,8 +209,8 @@ return -1; if (d->compat_xstats && d->xstats) { - if (gnet_stats_copy(d, d->compat_xstats, RTA_DATA(d->xstats), - RTA_PAYLOAD(d->xstats)) < 0) + if (gnet_stats_copy(d, d->compat_xstats, d->xstats, + d->xstats_len) < 0) return -1; } From tgraf@suug.ch Fri Apr 1 15:28:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:28:21 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NSFVt009537 for ; Fri, 1 Apr 2005 15:28:15 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id ABB7AF; Sat, 2 Apr 2005 01:27:52 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 2556D1C0EA; Sat, 2 Apr 2005 01:28:36 +0200 (CEST) Date: Sat, 2 Apr 2005 01:28:36 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 3/3] [NET]: Improve gnet_stats_* dumping logic to be less error prone Message-ID: <20050401232835.GM3086@postel.suug.ch> References: <20050401232654.GJ3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401232654.GJ3086@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/01 15:01:24+02:00 tgraf@suug.ch # [NET]: Improve gnet_stats_* dumping logic to be less error prone # # The recent additions to make gnet_stats_* useable for action # statistics dumping in two steps introcuded a few error prone # assumptions which can easly be forgotten. This patch fixes this # up by simplifying the process of adding new fields to struct # gnet_dump or adding additional backward compatibility TLVs. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/core/gen_stats.c # 2005/04/01 15:01:12+02:00 tgraf@suug.ch +24 -13 # [NET]: Improve gnet_stats_* dumping logic to be less error prone # diff -Nru a/net/core/gen_stats.c b/net/core/gen_stats.c --- a/net/core/gen_stats.c 2005-04-02 01:18:26 +02:00 +++ b/net/core/gen_stats.c 2005-04-02 01:18:26 +02:00 @@ -26,9 +26,7 @@ static inline int gnet_stats_copy(struct gnet_dump *d, int type, void *buf, int size) { - if (type) - RTA_PUT(d->skb, type, size, buf); - + RTA_PUT(d->skb, type, size, buf); return 0; rtattr_failure: @@ -58,6 +56,8 @@ gnet_stats_start_copy_compat(struct sk_buff *skb, int type, int tc_stats_type, int xstats_type, spinlock_t *lock, struct gnet_dump *d) { + memset(d, 0, sizeof(*d)); + spin_lock_bh(lock); d->lock = lock; if (type) @@ -65,12 +65,11 @@ d->skb = skb; d->compat_tc_stats = tc_stats_type; d->compat_xstats = xstats_type; - d->xstats = NULL; - if (d->compat_tc_stats) - memset(&d->tc_stats, 0, sizeof(d->tc_stats)); + if (d->tail) + return gnet_stats_copy(d, type, NULL, 0); - return gnet_stats_copy(d, type, NULL, 0); + return 0; } /** @@ -111,8 +110,11 @@ d->tc_stats.bytes = b->bytes; d->tc_stats.packets = b->packets; } - - return gnet_stats_copy(d, TCA_STATS_BASIC, b, sizeof(*b)); + + if (d->tail) + return gnet_stats_copy(d, TCA_STATS_BASIC, b, sizeof(*b)); + + return 0; } /** @@ -134,7 +136,10 @@ d->tc_stats.pps = r->pps; } - return gnet_stats_copy(d, TCA_STATS_RATE_EST, r, sizeof(*r)); + if (d->tail) + return gnet_stats_copy(d, TCA_STATS_RATE_EST, r, sizeof(*r)); + + return 0; } /** @@ -157,8 +162,11 @@ d->tc_stats.backlog = q->backlog; d->tc_stats.overlimits = q->overlimits; } - - return gnet_stats_copy(d, TCA_STATS_QUEUE, q, sizeof(*q)); + + if (d->tail) + return gnet_stats_copy(d, TCA_STATS_QUEUE, q, sizeof(*q)); + + return 0; } /** @@ -182,7 +190,10 @@ d->xstats_len = len; } - return gnet_stats_copy(d, TCA_STATS_APP, st, len); + if (d->tail) + return gnet_stats_copy(d, TCA_STATS_APP, st, len); + + return 0; } /** From shemminger@osdl.org Fri Apr 1 15:44:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:44:22 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31Ni4j6010722 for ; Fri, 1 Apr 2005 15:44:08 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j31Nhns4014569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Apr 2005 15:43:49 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j31Nhm42010798; Fri, 1 Apr 2005 15:43:48 -0800 Date: Fri, 1 Apr 2005 15:43:48 -0800 From: Stephen Hemminger To: jaganav@us.ibm.com Cc: Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050401154348.553f3c46@dxpl.pdx.osdl.net> In-Reply-To: <1112321619.424cae539e75e@imap.linux.ibm.com> References: <1112321619.424cae539e75e@imap.linux.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 31 Mar 2005 21:13:39 -0500 jaganav@us.ibm.com wrote: > Quoting Roland Dreier : > > I have to admit I don't know much about the TOE / RDMA/TCP / RNIC (or > > whatever you want to call it) world. However I know that the large > > majority of InfiniBand use right now is running on Linux, and I hope > > the Linux community is willing to work with the IB community. > > > > Just want to let everyone know know that we have started an opensource > effort (www.openrdma.org) for enablement of RNICs (RDMA enabled NICs). This > community has now come up with an architecture > (http://rdma.sourceforge.net/architecture.pdf) to build this support in Linux. > Would really appreciate if you review and provide any comments. We have just > started to hack but no code is available on this project yet. > > Thanks > Venkat OpenRdma is a misnomer, because as I read your architecture you are trying to create a "kernel abstraction layer" for closed source vendor RDMA drivers. This will never be accepted, please go back to the drawing board and figure out how to make real open source drivers. From davem@davemloft.net Fri Apr 1 15:50:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:50:56 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NooXX011406 for ; Fri, 1 Apr 2005 15:50:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHVtn-0003gY-00; Fri, 01 Apr 2005 15:49:59 -0800 Date: Fri, 1 Apr 2005 15:49:59 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCHSET] action statistics dumping fix & gnet_stats improvements Message-Id: <20050401154959.1eef4880.davem@davemloft.net> In-Reply-To: <20050401232654.GJ3086@postel.suug.ch> References: <20050401232654.GJ3086@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 2 Apr 2005 01:26:54 +0200 Thomas Graf wrote: > Fixes a stupid bug I introduced in the last patchset which for some > reason didn't get caught in the testing process. The other two > patches change the behaviour of yet unused but likely use cases > to what one would expect without reading the code. > > Please do a > > bk pull bk://kernel.bkbits.net/tgraf/net-2.6-tcf_exts All looks good. Pulled, thanks Thomas. From asgeir@chelsio.com Fri Apr 1 15:51:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:52:00 -0800 (PST) Received: from stargate.chelsio.com (stargate.chelsio.com [64.186.171.138] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NprqB011864 for ; Fri, 1 Apr 2005 15:51:53 -0800 Received: from YOGI.asicdesigners.com (yogi.asicdesigners.com [10.192.160.7]) by stargate.chelsio.com (8.12.5/8.12.5) with SMTP id j31NotfZ012683; Fri, 1 Apr 2005 15:50:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Linux support for RDMA Date: Fri, 1 Apr 2005 15:50:55 -0800 Message-ID: <67D69596DDF0C2448DB0F0547D0F947E01781F1A@yogi.asicdesigners.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux support for RDMA Thread-Index: AcU2XRJTLR7JHDJ6RnC21gxkbfiaswAtOgbQ From: "Asgeir Eiriksson" To: , "H. Peter Anvin" Cc: "Roland Dreier" , "Dmitry Yusupov" , , "David S. Miller" , , , , , , , "Benjamin LaHaise" X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j31NprqB011864 X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asgeir@chelsio.com Precedence: bulk X-list: netdev Venkat Your assessment of the IB vs. Ethernet latencies isn't necessarily correct. - you already have available low latency 10GE switches (< 1us port-to-port) - you already have available low latency (cut-through processing) 10GE TOE engines The Veritest verified 10GE TOE end-to-end latency is < 10us today (end-to-end being from a Linux user-space-process to a Linux user-space-process through a switch; full report with detail of the setup is available at http://www.chelsio.com/technology/Chelsio10GbE_Fujitsu.pdf) For comparison: the published IB latency numbers are around 5us today and those use a polling receiver, and those don't include a context switch(es) as does the Ethernet number quoted above. 'Asgeir > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of jaganav@us.ibm.com > Sent: Thursday, March 31, 2005 5:49 PM > To: H. Peter Anvin > Cc: Roland Dreier; Dmitry Yusupov; open-iscsi@googlegroups.com; David S. > Miller; mpm@selenic.com; andrea@suse.de; michaelc@cs.wisc.edu; > James.Bottomley@HansenPartnership.com; ksummit-2005-discuss@thunk.org; > netdev@oss.sgi.com; Benjamin LaHaise > Subject: Re: Linux support for RDMA > > Quoting "H. Peter Anvin" : > > Benjamin LaHaise wrote: > > > > > > I'm curious how the 10Gig ethernet market will pan out. Time and > again > > > the market has shown that ethernet always has the cost advantage in > the > > > end. If something like Intel's I/O Acceleration Technology makes it > > > that much easier for commodity ethernet to achieve similar performance > > > characteristics over ethernet to that of IB and fibre channel, the > cost > > > advantage alone might switch some new customers over. But the > hardware > > > isn't near what IB offers today, making IB an important niche filler. > > > > > > > From what I've seen coming down the pipe, I think 10GE is going to > > eventually win over IB, just like previous generations did over Token > > Ring, FDDI and other niche filler technologies. It doesn't, as you say, > > mean that e.g. IB doesn't matter *now*; furthermore, it also matters for > > the purpose of fixing the kind of issues that are going to have to be > > fixed anyway. > > > > -hpa > > > > > > > > No doubt, Ethernet will eventually win .. btw, Hasn't history proven this > over > ATM? More specifically when the industry predicted that ATM will replace > ethernet :) > > However, I'll have to agree with Ben that IB technolgy will fill an > important > niche segment, more specifically so in the low end of High Performance > Computing > (HPC) segment which is in a transition mode currently moving away from > proprietary interconnects to industry standards based IB technology. > Eventhough, > ethernet may eventually may catch up with IB in terms of the bandwidth but > IB > fabrics can offer better latencies. > > Thanks > Venkat From davem@davemloft.net Fri Apr 1 15:55:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 15:55:43 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31NtbXM012578 for ; Fri, 1 Apr 2005 15:55:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHVyM-0003hr-00; Fri, 01 Apr 2005 15:54:42 -0800 Date: Fri, 1 Apr 2005 15:54:42 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050401155442.3bbd6a73.davem@davemloft.net> In-Reply-To: <424DD78D.7070001@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> <4239E00C.4080309@cosmosbay.com> <20050331221352.13695124.davem@davemloft.net> <424D5D34.4030800@cosmosbay.com> <20050401122802.7c71afbc.davem@davemloft.net> <424DB7A1.8090803@cosmosbay.com> <20050401130832.1f972a3b.davem@davemloft.net> <424DC08A.3020204@cosmosbay.com> <20050401143442.62ed8bb9.davem@davemloft.net> <424DD78D.7070001@cosmosbay.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 02 Apr 2005 01:21:49 +0200 Eric Dumazet wrote: > OK this patch includes everything... > > - Locking abstraction > - rt_check_expire() fixes > - New gc_interval_ms sysctl to be able to have timer gc_interval < 1 second > - New gc_debug sysctl to let sysadmin tune gc > - Less memory used by hash table (spinlocks moved to a smaller table) > - sizing of spinlocks table depends on NR_CPUS > - hash table allocated using alloc_large_system_hash() function > - header fix for /proc/net/stat/rt_cache Looks fine to me. I'd like to see some feedback from folks like Robert Olsson and co. before applying this, so let's allow the patch to simmer over the weekend, ok? :-) From dima@neterion.com Fri Apr 1 16:03:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 16:03:51 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3203jR6013216 for ; Fri, 1 Apr 2005 16:03:46 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j3202eOC027166; Fri, 1 Apr 2005 19:02:40 -0500 (EST) Received: from beastie ([10.16.16.220]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j3202cDD002273; Fri, 1 Apr 2005 19:02:38 -0500 (EST) Subject: RE: Linux support for RDMA From: Dmitry Yusupov To: Asgeir Eiriksson Cc: jaganav@us.ibm.com, "H. Peter Anvin" , Roland Dreier , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, Benjamin LaHaise In-Reply-To: <67D69596DDF0C2448DB0F0547D0F947E01781F1A@yogi.asicdesigners.com> References: <67D69596DDF0C2448DB0F0547D0F947E01781F1A@yogi.asicdesigners.com> Content-Type: text/plain Organization: Neterion, Inc Date: Fri, 01 Apr 2005 16:02:37 -0800 Message-Id: <1112400157.9559.98.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dima@neterion.com Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 15:50 -0800, Asgeir Eiriksson wrote: > Venkat > > Your assessment of the IB vs. Ethernet latencies isn't necessarily > correct. > - you already have available low latency 10GE switches (< 1us > port-to-port) > - you already have available low latency (cut-through processing) 10GE > TOE engines > > The Veritest verified 10GE TOE end-to-end latency is < 10us today > (end-to-end being from a Linux user-space-process to a Linux > user-space-process through a switch; full report with detail of the > setup is available at > http://www.chelsio.com/technology/Chelsio10GbE_Fujitsu.pdf) > > For comparison: the published IB latency numbers are around 5us today > and those use a polling receiver, and those don't include a context > switch(es) as does the Ethernet number quoted above. yep. I should agree in here. On 10Gbps network latencies numbers are around 5-15us. Even with non-TOE card, I managed to get 13us latency with regular TCP/IP stack. [root@localhost root]# ./nptcp -a -t -l 256 -u 98304 -i 256 -p 5100 -P - h 17.1.1.227 Latency: 0.000013 Now starting main loop 0: 256 bytes 7 times --> 131.37 Mbps in 0.000015 sec 1: 512 bytes 65 times --> 239.75 Mbps in 0.000016 sec Dima > 'Asgeir > > > > -----Original Message----- > > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > > Behalf Of jaganav@us.ibm.com > > Sent: Thursday, March 31, 2005 5:49 PM > > To: H. Peter Anvin > > Cc: Roland Dreier; Dmitry Yusupov; open-iscsi@googlegroups.com; David > S. > > Miller; mpm@selenic.com; andrea@suse.de; michaelc@cs.wisc.edu; > > James.Bottomley@HansenPartnership.com; ksummit-2005-discuss@thunk.org; > > netdev@oss.sgi.com; Benjamin LaHaise > > Subject: Re: Linux support for RDMA > > > > Quoting "H. Peter Anvin" : > > > Benjamin LaHaise wrote: > > > > > > > > I'm curious how the 10Gig ethernet market will pan out. Time and > > again > > > > the market has shown that ethernet always has the cost advantage > in > > the > > > > end. If something like Intel's I/O Acceleration Technology makes > it > > > > that much easier for commodity ethernet to achieve similar > performance > > > > characteristics over ethernet to that of IB and fibre channel, the > > cost > > > > advantage alone might switch some new customers over. But the > > hardware > > > > isn't near what IB offers today, making IB an important niche > filler. > > > > > > > > > > From what I've seen coming down the pipe, I think 10GE is going to > > > eventually win over IB, just like previous generations did over > Token > > > Ring, FDDI and other niche filler technologies. It doesn't, as you > say, > > > mean that e.g. IB doesn't matter *now*; furthermore, it also matters > for > > > the purpose of fixing the kind of issues that are going to have to > be > > > fixed anyway. > > > > > > -hpa > > > > > > > > > > > > > No doubt, Ethernet will eventually win .. btw, Hasn't history proven > this > > over > > ATM? More specifically when the industry predicted that ATM will > replace > > ethernet :) > > > > However, I'll have to agree with Ben that IB technolgy will fill an > > important > > niche segment, more specifically so in the low end of High Performance > > Computing > > (HPC) segment which is in a transition mode currently moving away from > > proprietary interconnects to industry standards based IB technology. > > Eventhough, > > ethernet may eventually may catch up with IB in terms of the bandwidth > but > > IB > > fabrics can offer better latencies. > > > > Thanks > > Venkat > > > > From herbert@gondor.apana.org.au Fri Apr 1 16:51:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 16:51:50 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j320pdAt018588 for ; Fri, 1 Apr 2005 16:51:40 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHWqX-0001AE-00; Sat, 02 Apr 2005 10:50:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHWpo-0006Mj-00; Sat, 02 Apr 2005 10:49:56 +1000 Date: Sat, 2 Apr 2005 10:49:56 +1000 To: "David S. Miller" Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-ID: <20050402004956.GA24339@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20050331212325.5e996432.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: On Thu, Mar 31, 2005 at 09:23:25PM -0800, David S. Miller wrote: > On Thu, 31 Mar 2005 10:46:58 +1000 > Herbert Xu wrote: > > > > # This is a BitKeeper generated diff -Nru style patch. > > > # > > > # ChangeSet > > > # 2005/03/30 06:02:45+02:00 kaber@coreworks.de > > > # [IPSEC]: Check SPI in xfrm_state_find() > > > # > > > # Signed-off-by: Patrick McHardy > > > > Looks good. > > > > Signed-off-by: Herbert Xu > > To me too, both patches applied, thanks Patrick. Actually I only signed off on the first patch :) The second patch creates a dead lock since it does a nested read lock. The solution is simply to get rid of xfrm_init_tempsel and call the afinfo version directly. Signed-off-by: Herbert Xu BTW I'd like to start cleaning up the locking in net/xfrm. I don't want these changes to go into 2.6.12. However, I'd like to have them sit in mm for a while so that they get some testing coverage. What's the best way to do this? Could you create a tree slated for 2.6.13? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/xfrm/xfrm_state.c 1.60 vs edited ===== --- 1.60/net/xfrm/xfrm_state.c 2005-04-01 15:19:54 +10:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-02 10:35:06 +10:00 @@ -283,20 +283,6 @@ } EXPORT_SYMBOL(xfrm_state_flush); -static int -xfrm_init_tempsel(struct xfrm_state *x, struct flowi *fl, - struct xfrm_tmpl *tmpl, - xfrm_address_t *daddr, xfrm_address_t *saddr, - unsigned short family) -{ - struct xfrm_state_afinfo *afinfo = xfrm_state_get_afinfo(family); - if (!afinfo) - return -1; - afinfo->init_tempsel(x, fl, tmpl, daddr, saddr); - xfrm_state_put_afinfo(afinfo); - return 0; -} - struct xfrm_state * xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t *saddr, struct flowi *fl, struct xfrm_tmpl *tmpl, @@ -370,7 +356,7 @@ } /* Initialize temporary selector matching only * to current session. */ - xfrm_init_tempsel(x, fl, tmpl, daddr, saddr, family); + afinfo->init_tempsel(x, fl, tmpl, daddr, saddr); if (km_query(x, tmpl, pol) == 0) { x->km.state = XFRM_STATE_ACQ; --YiEDa0DAkWCtVeE4-- From hadi@cyberus.ca Fri Apr 1 17:04:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:04:21 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3214FuF019427 for ; Fri, 1 Apr 2005 17:04:16 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DHX3g-0006qh-TC for netdev@oss.sgi.com; Fri, 01 Apr 2005 20:04:16 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHX3a-0006Je-Ca; Fri, 01 Apr 2005 20:04:10 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050401123554.GA3468@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112403845.1088.14.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 20:04:05 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Herbert, Staring at the code, obversation: -> PFKEY is going to be interesting to have it actually generate events as a result of some app using netlink such as ip x - the reverse is actually easier to deal with. This problem doesnt exist with current approach i am taking. The issue is that pfkey echoes back a few things from the original message - important ones being version, pid, seq, and msgtype (as a sample take a look at pfkey_add()). So these need to be remembered... Brings back the original behavior i had netlink doing which was similar (but innacurate now that i stare at this). At the time i carried the nlmsg header around in the cb. So we would have to do the same for netlink[1]. The good news is all these fields happen to exist on netlink (except for the version - to which, for netlink created events, we could pass a hardcoded matching PFKEY2). In other words the structure i called km_cb will now have to have these fields i mentioned above. Thoughts before i start ? cheers, jamal [1]I actually would have no problems using a pid/seq etc generated by pfkey on a netlink header and viceversa. It shouldnt be an issue. From davem@davemloft.net Fri Apr 1 17:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:21:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321Lp5B024479 for ; Fri, 1 Apr 2005 17:21:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHXJ1-0005XH-00; Fri, 01 Apr 2005 17:20:07 -0800 Date: Fri, 1 Apr 2005 17:20:07 -0800 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-Id: <20050401172007.7296eced.davem@davemloft.net> In-Reply-To: <20050402004956.GA24339@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 2 Apr 2005 10:49:56 +1000 Herbert Xu wrote: > The second patch creates a dead lock since it does a nested read > lock. The solution is simply to get rid of xfrm_init_tempsel > and call the afinfo version directly. read locks nest even in the presence of pending writers From hadi@cyberus.ca Fri Apr 1 17:25:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:26:01 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321Pt8b025072 for ; Fri, 1 Apr 2005 17:25:55 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DHXOc-0007og-Kj for netdev@oss.sgi.com; Fri, 01 Apr 2005 20:25:54 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHXOY-0008VP-6i; Fri, 01 Apr 2005 20:25:50 -0500 Subject: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu , "David S. Miller" , Masahide NAKAMURA Cc: psec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com, kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com Content-Type: text/plain Organization: jamalopolous Message-Id: <1112405144.1096.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 20:25:44 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Folks, Theres something wrong in the way acquire works - IMO in both pfkey and netlink. I asked this before but didnt get satisfactory answer. Masahide-san and myself have had private exchanges and we are both unsatisfied with current situation. Theres probably a spec or known good practise documented somewhere ... Let me provide some testcases then theorize. The idea is to simulate a situation where the kernel thinks a km is listening (it could be there but just non-responsive) or just a scenario where the acquire gets lost. You need the current events patches to see this. test1)on one window run setkey -x: ping -c 1 someDST -1) packet arrives towards outbound 0) Larval state created 1) one acquire sent. 2) timeout. 3) packet dropped. -ESRCH returned. 4) larval state deleted So question 1): Shouldnt the return code be -ERESTART to ask the app to retry? question 2) Why is there a hardcoding of 1 try only? ping -c2 someDST Same as above (Steps -1 to 4) repeated twice one for each packet sent ping -c3 DST Same as above repeated 3 times. test2) With ip x m (but not setkey). ping -c 1 DST -1) packet arrives 0) Larval state created Loop: 1) one acquire sent. 2) timeout. go to loop. So loop has no way to break. ping is hang waiting. the only way to break out is by hitting control-c on prompt. I think ping gets a -ERESTART which i believe is the correct signal? When you hit control-c Larval state is deleted. Clearly this is not desirable. We want at some point to give up. Question: Can we have a configurable max retries (sysctl settable) for acquire - or does it already exist just not being used? Couldnt find any staring at the code. ping -c2/3 DST does not change the above behavior. Ping is hang after first packet - so it doesnt matter. The conclusion we reached in our discussion is: a) -ERESTART is the correct signal to return b) number of acquire retries should be configurable preferably a system wide value. Thoughts? cheers, jamal From herbert@gondor.apana.org.au Fri Apr 1 17:28:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:28:55 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321Sjxf025671 for ; Fri, 1 Apr 2005 17:28:46 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHXR8-0001Ml-00; Sat, 02 Apr 2005 11:28:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHXQr-0006Qw-00; Sat, 02 Apr 2005 11:28:13 +1000 Date: Sat, 2 Apr 2005 11:28:13 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050402012813.GA24575@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112403845.1088.14.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Hi Jamal: On Fri, Apr 01, 2005 at 08:04:05PM -0500, jamal wrote: > > The issue is that pfkey echoes back a few things from the original > message - important ones being version, pid, seq, and msgtype (as a > sample take a look at pfkey_add()). So these need to be remembered... You're right. The pid and seq should be stored in km_event by af_key and xfrm_user before they call km_notify. In fact bring back that the km_type field too and put it in km_event. That'll become useful when we figure out a way to include it in the netlink message so that the originator can be uniquely identified. The version should always be set by the kernel though. This is because the packet we're broadcasting has been regenerated by the kernel. If we ever get PFKEY v3 then in order that all existing applications understand these messages you'll have to reformat them as PFKEY v2 anyway. msgtype should be derived from the event as you did in xfrm_user. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jaganav@us.ibm.com Fri Apr 1 17:37:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:37:33 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321bQ3b026512 for ; Fri, 1 Apr 2005 17:37:26 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j321bK5j733728 for ; Fri, 1 Apr 2005 20:37:20 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j321bKlD200322 for ; Fri, 1 Apr 2005 18:37:20 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j321bJ1U014970 for ; Fri, 1 Apr 2005 18:37:20 -0700 Received: from imap.linux.ibm.com (imap.rtp.raleigh.ibm.com [9.42.107.100]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j321bFBZ014935; Fri, 1 Apr 2005 18:37:19 -0700 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 3D36E7C015; Fri, 1 Apr 2005 20:37:14 -0500 (EST) Received: from dyn9047018082.beaverton.ibm.com (dyn9047018082.beaverton.ibm.com [9.47.18.82]) by imap.rtp.raleigh.ibm.com (IMP) with HTTP for ; Fri, 1 Apr 2005 20:37:13 -0500 Message-ID: <1112405833.424df749e61b5@imap.linux.ibm.com> Date: Fri, 1 Apr 2005 20:37:13 -0500 From: jaganav@us.ibm.com To: Stephen Hemminger Cc: Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-Originating-IP: 9.47.18.82 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaganav@us.ibm.com Precedence: bulk X-list: netdev Quoting Stephen Hemminger : > On Thu, 31 Mar 2005 21:13:39 -0500 > jaganav@us.ibm.com wrote: > > > Quoting Roland Dreier : > > > I have to admit I don't know much about the TOE / RDMA/TCP / RNIC (or > > > whatever you want to call it) world. However I know that the large > > > majority of InfiniBand use right now is running on Linux, and I hope > > > the Linux community is willing to work with the IB community. > > > > > > > Just want to let everyone know know that we have started an opensource > > effort (www.openrdma.org) for enablement of RNICs (RDMA enabled NICs). > This > > community has now come up with an architecture > > (http://rdma.sourceforge.net/architecture.pdf) to build this support in > Linux. > > Would really appreciate if you review and provide any comments. We have > just > > started to hack but no code is available on this project yet. > > > > Thanks > > Venkat > > OpenRdma is a misnomer, because as I read your architecture you are trying > to > create a "kernel abstraction layer" for closed source vendor RDMA drivers. > This will > never be accepted, please go back to the drawing board and figure out how to > make > real open source drivers. > > First let me say that the purpose of this project is to make the entire stack (with all of the enablement layers) including the drivers opensourced. The kernel abstraction layer will be built around standards based (opengroup.org/icsc) RNIC-PI interface and which allows the RNIC vendors to opensource their drivers using that interface. BTW, RNIC-PI interface is work-in-progress and the first draft is targeted to be published soon. Several RNIC adapter vendors, who contribute to the openRDMA effort, are quite willing to opensource their drivers through openRDMA project. BTW, I understood why you got the impression that the this is for closed source vendor drivers: Our intention is not to allow the kernel verbs provider code (kVP) to be private and that was an error. Thanks for pointing this out but we'll make this change soon. Thanks Venkat From hadi@cyberus.ca Fri Apr 1 17:42:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:43:00 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321gsmJ027199 for ; Fri, 1 Apr 2005 17:42:54 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DHXex-0007wz-2o for netdev@oss.sgi.com; Fri, 01 Apr 2005 18:42:47 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHXf1-0001oe-Em; Fri, 01 Apr 2005 20:42:51 -0500 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050402012813.GA24575@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112406164.1088.54.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2005 20:42:45 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Herbert, On Fri, 2005-04-01 at 20:28, Herbert Xu wrote: > Hi Jamal: > > On Fri, Apr 01, 2005 at 08:04:05PM -0500, jamal wrote: > > > > The issue is that pfkey echoes back a few things from the original > > message - important ones being version, pid, seq, and msgtype (as a > > sample take a look at pfkey_add()). So these need to be remembered... > > You're right. The pid and seq should be stored in km_event by > af_key and xfrm_user before they call km_notify. In fact bring > back that the km_type field too and put it in km_event. Do we need km_type? Given we have: the event, seq, pid (regardless of where it was generated) we have sufficient info to create eitehr a netlink or pfkey message. > That'll > become useful when we figure out a way to include it in the netlink > message so that the originator can be uniquely identified. > The pid seems pretty accurate to describe what process generated the initial message. hold on: Ah, I think i may get what you are trying to get to: You want iproute to display something along the lines of "this was created by a pfkey app pid 1534". Did i read you correctly? > The version should always be set by the kernel though. This is because > the packet we're broadcasting has been regenerated by the kernel. If > we ever get PFKEY v3 then in order that all existing applications > understand these messages you'll have to reformat them as PFKEY v2 > anyway. > So always go v2? > msgtype should be derived from the event as you did in xfrm_user. > indeed. cheers, jamal From herbert@gondor.apana.org.au Fri Apr 1 17:46:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:46:47 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321kbQW027801 for ; Fri, 1 Apr 2005 17:46:38 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHXiE-0001SM-00; Sat, 02 Apr 2005 11:46:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHXhn-0006TH-00; Sat, 02 Apr 2005 11:45:43 +1000 Date: Sat, 2 Apr 2005 11:45:43 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050402014543.GA24861@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112406164.1088.54.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 08:42:45PM -0500, jamal wrote: > > hold on: Ah, I think i may get what you are trying to get to: You want > iproute to display something along the lines of "this was created by a > pfkey app pid 1534". Did i read you correctly? That's right. Someone with a pathological mind might do pfkey and netlink from the same pid :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 1 17:46:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 17:46:58 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j321kqw2027873 for ; Fri, 1 Apr 2005 17:46:52 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHXiY-0001TB-00; Sat, 02 Apr 2005 11:46:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHXiN-0006Tc-00; Sat, 02 Apr 2005 11:46:19 +1000 Date: Sat, 2 Apr 2005 11:46:19 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050402014619.GB24861@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112406164.1088.54.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 08:42:45PM -0500, jamal wrote: > > So always go v2? Yes since that's the only version that the kernel knows how to generate. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jaganav@us.ibm.com Fri Apr 1 18:00:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 18:00:21 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32208Nk029126 for ; Fri, 1 Apr 2005 18:00:14 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j322014I563788 for ; Fri, 1 Apr 2005 21:00:01 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j32200dg184050 for ; Fri, 1 Apr 2005 19:00:00 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j321xx6X031851 for ; Fri, 1 Apr 2005 19:00:00 -0700 Received: from imap.linux.ibm.com (imap.rtp.raleigh.ibm.com [9.42.107.100]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j321xwQY031721; Fri, 1 Apr 2005 18:59:59 -0700 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 34C8D7C015; Fri, 1 Apr 2005 20:59:47 -0500 (EST) Received: from dyn9047018082.beaverton.ibm.com (dyn9047018082.beaverton.ibm.com [9.47.18.82]) by imap.rtp.raleigh.ibm.com (IMP) with HTTP for ; Fri, 1 Apr 2005 20:59:46 -0500 Message-ID: <1112407186.424dfc92dc37a@imap.linux.ibm.com> Date: Fri, 1 Apr 2005 20:59:46 -0500 From: jaganav@us.ibm.com To: Dmitry Yusupov Cc: Asgeir Eiriksson , "H. Peter Anvin" , Roland Dreier , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, Benjamin LaHaise Subject: RE: Linux support for RDMA MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-Originating-IP: 9.47.18.82 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaganav@us.ibm.com Precedence: bulk X-list: netdev Quoting Dmitry Yusupov : > On Fri, 2005-04-01 at 15:50 -0800, Asgeir Eiriksson wrote: > > Venkat > > > > Your assessment of the IB vs. Ethernet latencies isn't necessarily > > correct. > > - you already have available low latency 10GE switches (< 1us > > port-to-port) > > - you already have available low latency (cut-through processing) 10GE > > TOE engines > > > > The Veritest verified 10GE TOE end-to-end latency is < 10us today > > (end-to-end being from a Linux user-space-process to a Linux > > user-space-process through a switch; full report with detail of the > > setup is available at > > http://www.chelsio.com/technology/Chelsio10GbE_Fujitsu.pdf) > > > > For comparison: the published IB latency numbers are around 5us today > > and those use a polling receiver, and those don't include a context > > switch(es) as does the Ethernet number quoted above. > > yep. I should agree in here. On 10Gbps network latencies numbers are > around 5-15us. Even with non-TOE card, I managed to get 13us latency > with regular TCP/IP stack. > > [root@localhost root]# ./nptcp -a -t -l 256 -u 98304 -i 256 -p 5100 -P - h > 17.1.1.227 > Latency: 0.000013 > Now starting main loop > 0: 256 bytes 7 times --> 131.37 Mbps in 0.000015 sec > 1: 512 bytes 65 times --> 239.75 Mbps in 0.000016 sec > > Dima When I mentioned about latency, the measurement is from end-to-end (i.e. from app to app) but not just the switching or port to port latencies. With IB, I have seen the best numbers ranging from 5 to 7 us and which is far better than ethernet today (15 to 35us) with the network we have. I am not denyig the fact that ethernet is trying to close the gap here but IB has got a relative advantage now. Good to see you have got 5us in one case but what were the switch and adapter latencies in this case. Thanks Venkat From herbert@gondor.apana.org.au Fri Apr 1 18:11:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 18:11:07 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j322AwI7030178 for ; Fri, 1 Apr 2005 18:10:59 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHY5c-0001Zm-00; Sat, 02 Apr 2005 12:10:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHY55-0006Vk-00; Sat, 02 Apr 2005 12:09:47 +1000 Date: Sat, 2 Apr 2005 12:09:47 +1000 To: "David S. Miller" Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-ID: <20050402020947.GA24998@gondor.apana.org.au> References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401172007.7296eced.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 05:20:07PM -0800, David S. Miller wrote: > On Sat, 2 Apr 2005 10:49:56 +1000 > Herbert Xu wrote: > > > The second patch creates a dead lock since it does a nested read > > lock. The solution is simply to get rid of xfrm_init_tempsel > > and call the afinfo version directly. > > read locks nest even in the presence of pending writers Doh! I should've read the code first :) It's still a valid clean-up patch though. There is another reason why it won't dead lock. We don't actually ever hold the write lock on afinfo :) Is there any reason why we dont't just use xfrm_state_afinfo_lock instead of afinfo->lock? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 1 18:14:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 18:14:36 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j322ES0j030810 for ; Fri, 1 Apr 2005 18:14:29 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHY8k-0001bB-00; Sat, 02 Apr 2005 12:13:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHY7o-0006WQ-00; Sat, 02 Apr 2005 12:12:36 +1000 Date: Sat, 2 Apr 2005 12:12:36 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , psec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com, kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com Subject: Re: IPSEC: on behavior of acquire Message-ID: <20050402021236.GA25054@gondor.apana.org.au> References: <1112405144.1096.33.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112405144.1096.33.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 08:25:44PM -0500, jamal wrote: > > The conclusion we reached in our discussion is: > a) -ERESTART is the correct signal to return > b) number of acquire retries should be configurable preferably a system > wide value. > > Thoughts? Once we have the xfrm resolution stuff that Patrick is working on, we can have knobs for these cases just like those in the neighbour code. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From greg@kroah.com Fri Apr 1 21:29:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 21:29:29 -0800 (PST) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j325TG8L007523 for ; Fri, 1 Apr 2005 21:29:16 -0800 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j325Rsi06304; Fri, 1 Apr 2005 21:27:54 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DHbAY-4ZB-00; Fri, 01 Apr 2005 21:27:38 -0800 Date: Fri, 1 Apr 2005 21:27:38 -0800 From: Greg KH To: jaganav@us.ibm.com Cc: Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050402052738.GA17506@kroah.com> References: <20050401154348.553f3c46@dxpl.pdx.osdl.net> <1112405833.424df749e61b5@imap.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112405833.424df749e61b5@imap.linux.ibm.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 08:37:13PM -0500, jaganav@us.ibm.com wrote: > > Several RNIC adapter vendors, who contribute to the > openRDMA effort, are quite willing to opensource > their drivers through openRDMA project. "Several"? Why not all? And why the dual license? What good is writing Linux kernel code that is BSD licensed for such a core component? Didn't you all learn from the openib licensing mess? thanks, greg k-h From greg@kroah.com Fri Apr 1 22:02:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 22:02:53 -0800 (PST) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3262fL9008963 for ; Fri, 1 Apr 2005 22:02:41 -0800 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j3262Ri06657; Fri, 1 Apr 2005 22:02:27 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DHbi4-4dJ-00; Fri, 01 Apr 2005 22:02:16 -0800 Date: Fri, 1 Apr 2005 22:02:16 -0800 From: Greg KH To: jaganav@us.ibm.com Cc: Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050402060216.GA17766@kroah.com> References: <20050401154348.553f3c46@dxpl.pdx.osdl.net> <1112405833.424df749e61b5@imap.linux.ibm.com> <20050402052738.GA17506@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402052738.GA17506@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 09:27:38PM -0800, Greg KH wrote: > On Fri, Apr 01, 2005 at 08:37:13PM -0500, jaganav@us.ibm.com wrote: > > > > Several RNIC adapter vendors, who contribute to the > > openRDMA effort, are quite willing to opensource > > their drivers through openRDMA project. > > "Several"? Why not all? > > And why the dual license? What good is writing Linux kernel code that > is BSD licensed for such a core component? Didn't you all learn from > the openib licensing mess? Oh, and for those of you who might not know what mess I am talking about: The openib code was set up to be dual GPL and BSD licensed for the express purpose of taking the openib code and placing it into a closed source operating system (not any of the *BSDs). Needless to say, this has prevented me from doing any openib work, and probably the same for a number of other Linux kernel developers. If you all wish to duplicate this stupidity, feel free, but do not expect to get any help from the community... thanks, greg k-h From a.kasparas@gmc.lt Fri Apr 1 23:10:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 23:10:19 -0800 (PST) Received: from smtp02.omnitel.sun (smtp02-neptunas.omnitel.net [194.176.45.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j327ADSH011054 for ; Fri, 1 Apr 2005 23:10:14 -0800 Received: from smtp04-neptunas.omnitel.net ([194.176.45.42]) by smtp02.omnitel.sun (Sun Java System Messaging Server 6.1 HotFix 0.01 (built Jun 24 2004)) with ESMTP id <0IEB0018L58VLY00@smtp02.omnitel.sun> for netdev@oss.sgi.com; Sat, 02 Apr 2005 10:10:07 +0300 (EEST) Received: from smtp04-neptunas.omnitel.net (localhost [127.0.0.1]) by smtp04-neptunas.omnitel.net (Postfix) with SMTP id 59872398079; Sat, 02 Apr 2005 10:10:05 +0300 (EEST) Received: from [192.168.0.128] (unknown [62.212.195.62]) by smtp04-neptunas.omnitel.net (Postfix) with ESMTP id DB5F9398069; Sat, 02 Apr 2005 10:10:04 +0300 (EEST) Date: Sat, 02 Apr 2005 10:10:05 +0300 From: Aidas Kasparas Subject: Re: IPSEC: on behavior of acquire In-reply-to: <1112405303.1096.37.camel@jzny.localdomain> To: hadi@cyberus.ca Cc: ipsec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com, nakam@linux-ipv6.org Message-id: <424E454D.4090402@gmc.lt> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: lt, en, ru, fr X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <1112405303.1096.37.camel@jzny.localdomain> User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev jamal wrote: > test1)on one window run setkey -x: > > ping -c 1 someDST > > -1) packet arrives towards outbound > 0) Larval state created > 1) one acquire sent. > 2) timeout. > 3) packet dropped. -ESRCH returned. > 4) larval state deleted > > So question 1): Shouldnt the return code be -ERESTART to ask > the app to retry? > question 2) Why is there a hardcoding of 1 try only? Re 1 try only. There is little sense to do more tries. If there is no deamon listening to pfkey messages, then no connection will be made no matter how many retries you'll do. If deamon/link/peer is slow and SA was not established before timeout expired, then repeated acquire will be simply ignored (deamon will find out that negotiation is already in progress, there is no reason to start another negotiation and therefore will drop that acquire request). And the only situation where repeated acquires may help is when pfkey messages are lost. But pfkey was not designed to survive message loses, therefore you should not operate your boxes in mode when lost pfkey messages are a rule, not an exception. And on the other hand, occasional pfkey message loses can be worked around by applications/user retry. Re error code returned. Error codes returned by pfkey never were perfect. But your experiment is not perfect too. You sent pings with no KE deamon running. pfkey code found that there is nothing receiving acquire messages => there is no chance that any process will setup required SAs and tried to inform about that (I agree, return code is not very informative, at least until you learn about reasons why it is such). If you would have racoon (or other pfkey based ISAKMP daemon) running, you would get "resource temporarily unavailable" (don't know which error code corresponds to that message), which IMHO is ok (if it is not, please explain). Re netlink behaviour I can not comment as I don't use it for ipsec purposes, but would like to read similar explanation. Reason for that - idea that ipsec-tools one day could support operation via netlink is not ruled out of our minds. Yet, afaik nobody is working on it at the moment. -- Aidas Kasparas IT administrator GM Consult Group, UAB From jaganav@us.ibm.com Fri Apr 1 23:30:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Apr 2005 23:30:27 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j327UFIh012085 for ; Fri, 1 Apr 2005 23:30:21 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j327U8ua333834 for ; Sat, 2 Apr 2005 02:30:08 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j327U8dg153986 for ; Sat, 2 Apr 2005 00:30:08 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j327U70n002154 for ; Sat, 2 Apr 2005 00:30:08 -0700 Received: from imap.linux.ibm.com (imap.rtp.raleigh.ibm.com [9.42.107.100]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j327U3OI001848; Sat, 2 Apr 2005 00:30:07 -0700 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 05DA67C015; Sat, 2 Apr 2005 02:29:51 -0500 (EST) Received: from sig-9-65-29-50.mts.ibm.com (sig-9-65-29-50.mts.ibm.com [9.65.29.50]) by imap.rtp.raleigh.ibm.com (IMP) with HTTP for ; Sat, 2 Apr 2005 02:29:51 -0500 Message-ID: <1112426991.424e49ef57e2b@imap.linux.ibm.com> Date: Sat, 2 Apr 2005 02:29:51 -0500 From: jaganav@us.ibm.com To: Greg KH Cc: Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-Originating-IP: 9.65.29.50 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaganav@us.ibm.com Precedence: bulk X-list: netdev Quoting Greg KH : > On Fri, Apr 01, 2005 at 09:27:38PM -0800, Greg KH wrote: > > On Fri, Apr 01, 2005 at 08:37:13PM -0500, jaganav@us.ibm.com wrote: > > > > > > Several RNIC adapter vendors, who contribute to the > > > openRDMA effort, are quite willing to opensource > > > their drivers through openRDMA project. > > > > "Several"? Why not all? Because I haven't heard from 'all' of them yet that they would opensource. I am sure every vendor will do when the most of the other vendors are opensourcing it but I can't speak for them. I have asked in the past and will continue to ask every vendor to opensource their driver and make it part of openRDMA stack. > > > > And why the dual license? What good is writing Linux kernel code that > > is BSD licensed for such a core component? Didn't you all learn from > > the openib licensing mess? > > Oh, and for those of you who might not know what mess I am talking > about: > > The openib code was set up to be dual GPL and BSD licensed for the > express purpose of taking the openib code and placing it into a closed > source operating system (not any of the *BSDs). Needless to say, this > has prevented me from doing any openib work, and probably the same for a > number of other Linux kernel developers. > Absolutely understand the dual-license mess with openIB code. -:) However the intention of dual license with OpenRDMA is not for placing the code in closed source OSes but specifically for BSD* and in fact, the request is specifically made by the most adapter vendors as they wanted to offer the same on BSD platforms as well. BTW, unlike OpenIB initial stack (i.e. Gen1) which was already developed when it got opensourced, the openRDMA code is developed from scratch in true opensource fashion (of course, OpenIB has also followed this approach for their next generation stack though) with no ifdef code for BSD*. If this dual license is a concern to other kernel developers as well from contributing to OpenRDMA, we would seriously consider this and discuss with the adapter vendors. Thanks Venkat From herbert@gondor.apana.org.au Sat Apr 2 00:22:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 00:22:34 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j328MLgN017287 for ; Sat, 2 Apr 2005 00:22:24 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHdt3-0002t0-00; Sat, 02 Apr 2005 18:21:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHdsP-0003Lr-00; Sat, 02 Apr 2005 18:21:05 +1000 From: Herbert Xu To: dada1@cosmosbay.com (Eric Dumazet) Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Cc: davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se Organization: Core In-Reply-To: <424DD78D.7070001@cosmosbay.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 02 Apr 2005 18:21:05 +1000 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Eric Dumazet wrote: > > OK this patch includes everything... > > - Locking abstraction > - rt_check_expire() fixes > - New gc_interval_ms sysctl to be able to have timer gc_interval < 1 second > - New gc_debug sysctl to let sysadmin tune gc > - Less memory used by hash table (spinlocks moved to a smaller table) > - sizing of spinlocks table depends on NR_CPUS > - hash table allocated using alloc_large_system_hash() function > - header fix for /proc/net/stat/rt_cache This patch is doing too many things. How about splitting it up? For instance the spin lock stuff is pretty straightforward and should be in its own patch. The benefits of the GC changes are not obvious to me. rt_check_expire is simply meant to kill off old entries. It's not really meant to be used to free up entries when the table gets full. rt_garbage_collect on the other hand is designed to free entries when it is needed. Eric raised the point that rt_garbage_collect is pretty expensive. So what about amortising its cost a bit more? For instance, we can set a new threshold that's lower than gc_thresh and perform GC on the chain being inserted in rt_intern_hash if we're above that threshold. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mroos@tartu.cyber.ee Sat Apr 2 00:41:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 00:41:22 -0800 (PST) Received: from tartu.cyber.ee (tartu.cyber.ee [193.40.6.68]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j328fHft018280 for ; Sat, 2 Apr 2005 00:41:18 -0800 Received: Message by Barricade tartu.cyber.ee with ESMTP id j328LgA06688; Sat, 2 Apr 2005 11:21:42 +0300 Received: from rhn.tartu-labor (rhn.tartu-labor [192.168.74.17]) by ondatra.tartu-labor (Postfix) with ESMTP id 65A2314C48; Sat, 2 Apr 2005 10:41:11 +0200 (EET) Received: from mroos by rhn.tartu-labor with local (Exim 4.50) id 1DHeBr-0002mb-2L; Sat, 02 Apr 2005 11:41:11 +0300 From: Meelis Roos To: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: RFC: Redirect-Device In-Reply-To: <1112303627.1073.71.camel@jzny.localdomain> User-Agent: tin/1.7.8-20050315 ("Scalpay") (UNIX) (Linux/2.6.12-rc1 (i686)) Message-Id: Date: Sat, 02 Apr 2005 11:41:11 +0300 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev j> I must be missing something: What is it that this device can do that the j> mirred action cant do? I know what I am missing here: documentation. There is very basic documentation about tc qdisc+class+filter level and almost nothing on the newer features. Without good documentation only some developers understand it. -- Meelis Roos From dada1@cosmosbay.com Sat Apr 2 01:23:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 01:23:23 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j329NGlo020425 for ; Sat, 2 Apr 2005 01:23:16 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j329LV9q008040; Sat, 2 Apr 2005 11:21:36 +0200 Message-ID: <424E641A.1020609@cosmosbay.com> Date: Sat, 02 Apr 2005 11:21:30 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Sat, 02 Apr 2005 11:21:37 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Herbert Xu a écrit : > Eric Dumazet wrote: > >>OK this patch includes everything... >> >> - Locking abstraction >> - rt_check_expire() fixes >> - New gc_interval_ms sysctl to be able to have timer gc_interval < 1 second >> - New gc_debug sysctl to let sysadmin tune gc >> - Less memory used by hash table (spinlocks moved to a smaller table) >> - sizing of spinlocks table depends on NR_CPUS >> - hash table allocated using alloc_large_system_hash() function >> - header fix for /proc/net/stat/rt_cache > > > This patch is doing too many things. How about splitting it up? > > For instance the spin lock stuff is pretty straightforward and > should be in its own patch. > > The benefits of the GC changes are not obvious to me. rt_check_expire > is simply meant to kill off old entries. It's not really meant to be > used to free up entries when the table gets full. Well, I began my work because of the overflow bug in rt_check_expire()... Then I realize this function could not work as expected. On a loaded machine, one timer tick is 1 ms. During this time, number of chains that are scanned is ridiculous. With the standard timer of 60 second, fact is rt_check_expire() is useless. > > rt_garbage_collect on the other hand is designed to free entries > when it is needed. Eric raised the point that rt_garbage_collect > is pretty expensive. So what about amortising its cost a bit more? Yes. rt_garbage_collect() has serious problems. But this function is sooo complex I dont want to touch it and let experts do it if they want. But then one may think why we have two similar functions that are doing basically the same thing : garbage collection. One of a production machine rtstat -i 1 output is : rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| | | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| 2618087| 28581| 7673| 0| 0| 0| 0| 0| 1800| 1450| 0| 0| 0| 0| 0| 37630| 4783| 2618689| 25444| 4918| 0| 0| 0| 0| 0| 2051| 1699| 0| 0| 0| 0| 0| 27741| 5461| 2619369| 25000| 4567| 0| 0| 0| 0| 0| 1860| 1304| 0| 0| 0| 0| 0| 26606| 4563| 2618396| 24830| 4633| 0| 0| 0| 0| 0| 1959| 1492| 0| 0| 0| 0| 0| 26643| 4930| Without serious tuning, this machine could not handle this load, or even half of it. Crashes usually occurs when secret_interval interval is elapsed : rt_cache_flush(0); is called, and the whole machine begins to die. > > For instance, we can set a new threshold that's lower than gc_thresh > and perform GC on the chain being inserted in rt_intern_hash if we're > above that threshold. We could also try to perform GC on L1_CACHE_SIZE/sizeof(struct rt_hash_bucket) chains, not only the 'current chain', to fully use the cache miss. > > Cheers, Thank you From akpm@osdl.org Sat Apr 2 01:56:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 01:56:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j329ufvY021947 for ; Sat, 2 Apr 2005 01:56:42 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j329uas4032011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 2 Apr 2005 01:56:36 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j329uZIu002985; Sat, 2 Apr 2005 01:56:35 -0800 Date: Sat, 2 Apr 2005 01:56:22 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: kernel@wpascanner.com Subject: Fw: [Bugme-new] [Bug 4434] New: Tulip based NIC card causes hard lock up of PC Message-Id: <20050402015622.41dff439.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Sat, 2 Apr 2005 01:49:50 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4434] New: Tulip based NIC card causes hard lock up of PC http://bugme.osdl.org/show_bug.cgi?id=4434 Summary: Tulip based NIC card causes hard lock up of PC Kernel Version: 2.6.11 Status: NEW Severity: high Owner: acme@conectiva.com.br Submitter: kernel@wpascanner.com Distribution: Knoppix V3.8 CeBIT, V3.7 PC-Welt, ANY Knoppix under kernel 2.6.x Hardware Environment: #1 FIC PA-2007 MB 160MB RAM BIOS V1.09CD12 #2 ABIT K7R MB 384MB RAM LAN Cards OEM DEC Tulip 21041 DLink DE-530+ LAN Cards Intel 21143 Tulip based Software Environment: de4x5 Problem Description: Hard lock up on setting up LAN/NIC card Steps to reproduce: Can not boot to working enviroment with DHCP enabled (default for Knoppix) or after booting via NODHCP cheat code on command line and using netcardconfig results in the hard lock up. See: http://www.knoppix.net/forum/viewtopic.php?t=17985&highlight= http://www.knoppix.net/forum/viewtopic.php?t=17986&highlight= ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From linux781@gmail.com Sat Apr 2 02:31:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 02:31:45 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32AVex2023541 for ; Sat, 2 Apr 2005 02:31:41 -0800 Received: by zproxy.gmail.com with SMTP id 34so92309nzf for ; Sat, 02 Apr 2005 02:31:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=m8KmkOw5qebPHfeH+i3pMbrY/IbFik0mgjgGVabMStvpnnuBglcvbkF810DYXX7mhlZyBICiTYXcoExX3TB/uLXNrMC9g5TzzrVn9jW1V0kD9Z8MyHmIMWY30VUCqz/HWq37msrhni/axG7jZg18xPMzdOqKIHcs/U7DZb8EZL0= Received: by 10.36.5.5 with SMTP id 5mr6599nze; Sat, 02 Apr 2005 02:31:35 -0800 (PST) Received: by 10.36.58.7 with HTTP; Sat, 2 Apr 2005 02:31:35 -0800 (PST) Message-ID: <72252ed05040202313a309e77@mail.gmail.com> Date: Sat, 2 Apr 2005 05:31:35 -0500 From: Akshay Kawale Reply-To: Akshay Kawale To: netdev@oss.sgi.com Subject: Problem accessing IP header fields. Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux781@gmail.com Precedence: bulk X-list: netdev Hi, I am trying to access the tot_len field in the IP Header using a sk_buff structure inside a Netfilter hook. I do something like: (**skb).nh.iph->tot_len += 64 I have tried other variants of the same statement but none of them work. I want to increment the length by 64 bytes, but it gives me an error saying that I am trying to access an 'incomplete data type'. Can anyone shed some light on this problem? tot_len if of type __u16 (unsigned short int). Thanks. - Akshay From herbert@gondor.apana.org.au Sat Apr 2 03:24:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 03:25:06 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32BOrml027752 for ; Sat, 2 Apr 2005 03:24:54 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHgjp-0003nQ-00; Sat, 02 Apr 2005 21:24:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHgiW-00063U-00; Sat, 02 Apr 2005 21:23:04 +1000 Date: Sat, 2 Apr 2005 21:23:04 +1000 To: Eric Dumazet Cc: davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, hadi@cyberus.ca Subject: Get rid of rt_check_expire and rt_garbage_collect Message-ID: <20050402112304.GA11321@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424E641A.1020609@cosmosbay.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 11:21:30AM +0200, Eric Dumazet wrote: > > Well, I began my work because of the overflow bug in rt_check_expire()... > Then I realize this function could not work as expected. On a loaded > machine, one timer tick is 1 ms. > During this time, number of chains that are scanned is ridiculous. > With the standard timer of 60 second, fact is rt_check_expire() is useless. I see. What we've got here is a scalability problem with respect to the number of hash buckets. As the number of buckets increases, the amount of work the timer GC has to perform inreases proportionally. Since the timer GC parameters are fixed, this will eventually break. Rather than changing the timer GC so that it runs more often to keep up with the large routing cache, we should get out of this by reducing the amount of work we have to do. Imagine an ideal balanced hash table with 2.6 million entries. That is, all incoming/outgoing packets belong to flows that are already in the hash table. Imagine also that there is no PMTU/link failure taking place so all entries are valid forever. In this state there is absolutely no need to execute the timer GC. Let's remove one of those assumptions and allow there to be entries which need to expire after a set period. Instead of having the timer GC clean them up, we can move the expire check to the place where the entries are used. That is, we make ip_route_input/ip_route_output/ipv4_dst_check check whether the entry has expired. On the face of it we're doing more work since every routing cache hit will need to check the validity of the dst. However, because it's a single subtraction it is actually pretty cheap. There is also no additional cache miss compared to doing it in the timer GC since we have to read the dst anyway. Let's go one step further and make the routing cache come to life. Now there are new entries coming in and we need to remove old ones in order to make room for them. That task is currently carried out by the timer GC in rt_check_expire and on demand by rt_garbage_collect. Either way we have to walk the entire routing cache looking for entries to get rid of. This is quite expensive when the routing cache is large. However, there is a better way. The reason we keep a cap on the routing cache (for a given hash size) is so that individual chains do not degenerate into long linked lists. In other words, we don't really care about how many entries there are in the routing cache. But we do care about how long each hash chain is. So instead of walking the entire routing cache to keep the number of entries down, what we should do is keep each hash chain as short as possible. Assuming that the hash function is good, this should achieve the same end result. Here is how it can be done: Every time a routing entry is inserted into a hash chain, we perform GC on that chain unconditionally. It might seem that we're doing more work again. However, as before because we're traversing the chain anyway, it is very cheap to perform the GC operations which mainly involve the checks in rt_may_expire. OK that's enough thinking and it's time to write some code to see whether this is all bullshit :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From zilvinas@barclay.balt.net Sat Apr 2 04:26:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 04:28:20 -0800 (PST) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32CQiid001289 for ; Sat, 2 Apr 2005 04:26:45 -0800 Received: from barclay.balt.net (zilvinas@localhost [127.0.0.1]) by barclay.balt.net (8.13.2/8.13.1/Debian-15) with ESMTP id j32CPsuD007894; Sat, 2 Apr 2005 15:25:54 +0300 Received: (from zilvinas@localhost) by barclay.balt.net (8.13.2/8.13.1/Submit) id j32CPrsa007893; Sat, 2 Apr 2005 15:25:53 +0300 Date: Sat, 2 Apr 2005 15:25:53 +0300 From: Zilvinas Valinskas To: Aidas Kasparas Cc: hadi@cyberus.ca, ipsec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com, nakam@linux-ipv6.org Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire Message-ID: <20050402122553.GA7521@gemtek.lt> Reply-To: Zilvinas Valinskas References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424E454D.4090402@gmc.lt> X-Attribution: Zilvinas X-Url: http://www.gemtek.lt/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 10:10:05AM +0300, Aidas Kasparas wrote: > > > jamal wrote: > >test1)on one window run setkey -x: > > > >ping -c 1 someDST > > > >-1) packet arrives towards outbound > >0) Larval state created > >1) one acquire sent. > >2) timeout. > >3) packet dropped. -ESRCH returned. > >4) larval state deleted > > > >So question 1): Shouldnt the return code be -ERESTART to ask > >the app to retry? > >question 2) Why is there a hardcoding of 1 try only? > > Re 1 try only. There is little sense to do more tries. If there is no > deamon listening to pfkey messages, then no connection will be made no > matter how many retries you'll do. If deamon/link/peer is slow and SA > was not established before timeout expired, then repeated acquire will > be simply ignored (deamon will find out that negotiation is already in > progress, there is no reason to start another negotiation and therefore > will drop that acquire request). And the only situation where repeated > acquires may help is when pfkey messages are lost. But pfkey was not > designed to survive message loses, therefore you should not operate your > boxes in mode when lost pfkey messages are a rule, not an exception. And > on the other hand, occasional pfkey message loses can be worked around > by applications/user retry. > > Re error code returned. Error codes returned by pfkey never were > perfect. But your experiment is not perfect too. You sent pings with no > KE deamon running. pfkey code found that there is nothing receiving > acquire messages => there is no chance that any process will setup > required SAs and tried to inform about that (I agree, return code is not > very informative, at least until you learn about reasons why it is > such). If you would have racoon (or other pfkey based ISAKMP daemon) > running, you would get "resource temporarily unavailable" (don't know > which error code corresponds to that message), which IMHO is ok (if it > is not, please explain). EBUSY I think it is. I am not entirely sure it is ok to return such error, some applications are not coping nicely with it. Perhaps ECONNREFUSED is more reasonable - as it doesn't brake old apps assumption (connection cannot be established, doesn't matter if that is due to routing or IPsec SPD or anything else). Although it is quite simple to fix applications to handle EBUSY and retry ... I thought it was annoying that applications quit because of EBUSY - when I had tried IPsec first time. Now I think it is quite handy - especially from scripts, I am sure that if something goes wrong - ping (or other application) won't block ... > > Re netlink behaviour I can not comment as I don't use it for ipsec > purposes, but would like to read similar explanation. Reason for that - > idea that ipsec-tools one day could support operation via netlink is not > ruled out of our minds. Yet, afaik nobody is working on it at the moment. > > > -- > Aidas Kasparas > IT administrator > GM Consult Group, UAB > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ipsec-tools-devel mailing list > Ipsec-tools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel From khc@pm.waw.pl Sat Apr 2 05:29:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 05:29:30 -0800 (PST) Received: from khc.piap.pl (khc.piap.pl [195.187.100.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32DTEYT004128 for ; Sat, 2 Apr 2005 05:29:16 -0800 Received: by khc.piap.pl (Postfix, from userid 500) id F0E7E1084C; Sat, 2 Apr 2005 15:29:12 +0200 (CEST) To: Jeff Garzik Cc: Subject: [PATCH] Generic HDLC update From: Krzysztof Halasa Date: Sat, 02 Apr 2005 15:29:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev --=-=-= Hi, The attached patch updates generic HDLC to version 1.18. Lab-tested. Please apply to Linux 2.6. Thanks. Changes: - doc updates - added Cisco LMI support to Frame-Relay code - cleaned hdlc_fr.c a bit, removed some orphaned #defines etc. - fixed a problem with non-functional LMI in FR DCE mode. - changed diagnostic messages to better conform to FR standards - all protocols: information about carrier changes (DCD line) is now printed to kernel logs. Signed-Off-By: Krzysztof Halasa -- Krzysztof Halasa --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hdlc-2.6-1.18.patch --- linux-2.6/Documentation/networking/generic-hdlc.txt 25 May 2003 22:13:37 -0000 1.4 +++ linux-2.6/Documentation/networking/generic-hdlc.txt 2 Apr 2005 13:12:18 -0000 @@ -1,21 +1,21 @@ Generic HDLC layer Krzysztof Halasa -January, 2003 Generic HDLC layer currently supports: -- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP). - Normal (routed) and Ethernet-bridged (Ethernet device emulation) - interfaces can share a single PVC. -- raw HDLC - either IP (IPv4) interface or Ethernet device emulation. -- Cisco HDLC, -- PPP (uses syncppp.c), -- X.25 (uses X.25 routines). - -There are hardware drivers for the following cards: -- C101 by Moxa Technologies Co., Ltd. -- RISCom/N2 by SDL Communications Inc. -- and others, some not in the official kernel. +1. Frame Relay (ANSI, CCITT, Cisco and no LMI). + - Normal (routed) and Ethernet-bridged (Ethernet device emulation) + interfaces can share a single PVC. + - ARP support (no InARP support in the kernel - there is an + experimental InARP user-space daemon available on: + http://www.kernel.org/pub/linux/utils/net/hdlc/). +2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation. +3. Cisco HDLC. +4. PPP (uses syncppp.c). +5. X.25 (uses X.25 routines). + +Generic HDLC is a protocol driver only - it needs a low-level driver +for your particular hardware. Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging). @@ -24,7 +24,7 @@ Make sure the hdlc.o and the hardware driver are loaded. It should create a number of "hdlc" (hdlc0 etc) network devices, one for each WAN port. You'll need the "sethdlc" utility, get it from: - http://hq.pm.waw.pl/hdlc/ + http://www.kernel.org/pub/linux/utils/net/hdlc/ Compile sethdlc.c utility: gcc -O2 -Wall -o sethdlc sethdlc.c @@ -52,12 +52,12 @@ * v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port if the card has software-selectable interfaces loopback - activate hardware loopback (for testing only) -* clock ext - external clock (uses DTE RX and TX clock) -* clock int - internal clock (provides clock signal on DCE clock output) -* clock txint - TX internal, RX external (provides TX clock on DCE output) -* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output) -* rate - sets clock rate in bps (not required for external clock or - for txfromrx) +* clock ext - both RX clock and TX clock external +* clock int - both RX clock and TX clock internal +* clock txint - RX clock external, TX clock internal +* clock txfromrx - RX clock external, TX clock derived from RX clock +* rate - sets clock rate in bps (for "int" or "txint" clock only) + Setting protocol: @@ -79,7 +79,7 @@ * x25 - sets X.25 mode * fr - Frame Relay mode - lmi ansi / ccitt / none - LMI (link management) type + lmi ansi / ccitt / cisco / none - LMI (link management) type dce - Frame Relay DCE (network) side LMI instead of default DTE (user). It has nothing to do with clocks! t391 - link integrity verification polling timer (in seconds) - user @@ -119,13 +119,14 @@ -If you have a problem with N2 or C101 card, you can issue the "private" -command to see port's packet descriptor rings (in kernel logs): +If you have a problem with N2, C101 or PLX200SYN card, you can issue the +"private" command to see port's packet descriptor rings (in kernel logs): sethdlc hdlc0 private -The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS. +The hardware driver has to be build with #define DEBUG_RINGS. Attaching this info to bug reports would be helpful. Anyway, let me know if you have problems using this. -For patches and other info look at http://hq.pm.waw.pl/hdlc/ +For patches and other info look at: +. --- linux-2.6/include/linux/hdlc.h 28 Oct 2004 06:16:08 -0000 1.12 +++ linux-2.6/include/linux/hdlc.h 2 Apr 2005 13:12:18 -0000 @@ -1,7 +1,7 @@ /* * Generic HDLC support routines for Linux * - * Copyright (C) 1999-2003 Krzysztof Halasa + * Copyright (C) 1999-2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -41,6 +41,7 @@ #define LMI_NONE 1 /* No LMI, all PVCs are static */ #define LMI_ANSI 2 /* ANSI Annex D */ #define LMI_CCITT 3 /* ITU-T Annex A */ +#define LMI_CISCO 4 /* The "original" LMI, aka Gang of Four */ #define HDLC_MAX_MTU 1500 /* Ethernet 1500 bytes */ #define HDLC_MAX_MRU (HDLC_MAX_MTU + 10 + 14 + 4) /* for ETH+VLAN over FR */ @@ -89,6 +90,7 @@ unsigned int deleted: 1; unsigned int fecn: 1; unsigned int becn: 1; + unsigned int bandwidth; /* Cisco LMI reporting only */ }state; }pvc_device; --- linux-2.6/drivers/net/wan/hdlc_fr.c 22 Jun 2004 03:25:28 -0000 1.13 +++ linux-2.6/drivers/net/wan/hdlc_fr.c 2 Apr 2005 13:12:18 -0000 @@ -2,7 +2,7 @@ * Generic HDLC support routines for Linux * Frame Relay support * - * Copyright (C) 1999 - 2003 Krzysztof Halasa + * Copyright (C) 1999 - 2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -27,6 +27,10 @@ active = open and "link reliable" exist = new = not used + CCITT LMI: ITU-T Q.933 Annex A + ANSI LMI: ANSI T1.617 Annex D + CISCO LMI: the original, aka "Gang of Four" LMI + */ #include @@ -49,45 +53,41 @@ #undef DEBUG_ECN #undef DEBUG_LINK -#define MAXLEN_LMISTAT 20 /* max size of status enquiry frame */ +#define FR_UI 0x03 +#define FR_PAD 0x00 + +#define NLPID_IP 0xCC +#define NLPID_IPV6 0x8E +#define NLPID_SNAP 0x80 +#define NLPID_PAD 0x00 +#define NLPID_CCITT_ANSI_LMI 0x08 +#define NLPID_CISCO_LMI 0x09 + + +#define LMI_CCITT_ANSI_DLCI 0 /* LMI DLCI */ +#define LMI_CISCO_DLCI 1023 + +#define LMI_CALLREF 0x00 /* Call Reference */ +#define LMI_ANSI_LOCKSHIFT 0x95 /* ANSI locking shift */ +#define LMI_ANSI_CISCO_REPTYPE 0x01 /* report type */ +#define LMI_CCITT_REPTYPE 0x51 +#define LMI_ANSI_CISCO_ALIVE 0x03 /* keep alive */ +#define LMI_CCITT_ALIVE 0x53 +#define LMI_ANSI_CISCO_PVCSTAT 0x07 /* PVC status */ +#define LMI_CCITT_PVCSTAT 0x57 + +#define LMI_FULLREP 0x00 /* full report */ +#define LMI_INTEGRITY 0x01 /* link integrity report */ +#define LMI_SINGLE 0x02 /* single PVC report */ -#define PVC_STATE_NEW 0x01 -#define PVC_STATE_ACTIVE 0x02 -#define PVC_STATE_FECN 0x08 /* FECN condition */ -#define PVC_STATE_BECN 0x10 /* BECN condition */ - - -#define FR_UI 0x03 -#define FR_PAD 0x00 - -#define NLPID_IP 0xCC -#define NLPID_IPV6 0x8E -#define NLPID_SNAP 0x80 -#define NLPID_PAD 0x00 -#define NLPID_Q933 0x08 - - -#define LMI_DLCI 0 /* LMI DLCI */ -#define LMI_PROTO 0x08 -#define LMI_CALLREF 0x00 /* Call Reference */ -#define LMI_ANSI_LOCKSHIFT 0x95 /* ANSI lockshift */ -#define LMI_REPTYPE 1 /* report type */ -#define LMI_CCITT_REPTYPE 0x51 -#define LMI_ALIVE 3 /* keep alive */ -#define LMI_CCITT_ALIVE 0x53 -#define LMI_PVCSTAT 7 /* pvc status */ -#define LMI_CCITT_PVCSTAT 0x57 -#define LMI_FULLREP 0 /* full report */ -#define LMI_INTEGRITY 1 /* link integrity report */ -#define LMI_SINGLE 2 /* single pvc report */ #define LMI_STATUS_ENQUIRY 0x75 #define LMI_STATUS 0x7D /* reply */ #define LMI_REPT_LEN 1 /* report type element length */ #define LMI_INTEG_LEN 2 /* link integrity element length */ -#define LMI_LENGTH 13 /* standard LMI frame length */ -#define LMI_ANSI_LENGTH 14 +#define LMI_CCITT_CISCO_LENGTH 13 /* LMI frame lengths */ +#define LMI_ANSI_LENGTH 14 typedef struct { @@ -223,51 +223,34 @@ } -static inline u16 status_to_dlci(u8 *status, int *active, int *new) -{ - *new = (status[2] & 0x08) ? 1 : 0; - *active = (status[2] & 0x02) ? 1 : 0; - - return ((status[0] & 0x3F) << 4) | ((status[1] & 0x78) >> 3); -} - - -static inline void dlci_to_status(u16 dlci, u8 *status, int active, int new) -{ - status[0] = (dlci >> 4) & 0x3F; - status[1] = ((dlci << 3) & 0x78) | 0x80; - status[2] = 0x80; - - if (new) - status[2] |= 0x08; - else if (active) - status[2] |= 0x02; -} - - - static int fr_hard_header(struct sk_buff **skb_p, u16 dlci) { u16 head_len; struct sk_buff *skb = *skb_p; switch (skb->protocol) { - case __constant_ntohs(ETH_P_IP): + case __constant_ntohs(NLPID_CCITT_ANSI_LMI): head_len = 4; skb_push(skb, head_len); - skb->data[3] = NLPID_IP; + skb->data[3] = NLPID_CCITT_ANSI_LMI; break; - case __constant_ntohs(ETH_P_IPV6): + case __constant_ntohs(NLPID_CISCO_LMI): head_len = 4; skb_push(skb, head_len); - skb->data[3] = NLPID_IPV6; + skb->data[3] = NLPID_CISCO_LMI; break; - case __constant_ntohs(LMI_PROTO): + case __constant_ntohs(ETH_P_IP): head_len = 4; skb_push(skb, head_len); - skb->data[3] = LMI_PROTO; + skb->data[3] = NLPID_IP; + break; + + case __constant_ntohs(ETH_P_IPV6): + head_len = 4; + skb_push(skb, head_len); + skb->data[3] = NLPID_IPV6; break; case __constant_ntohs(ETH_P_802_3): @@ -461,13 +444,14 @@ hdlc_device *hdlc = dev_to_hdlc(dev); struct sk_buff *skb; pvc_device *pvc = hdlc->state.fr.first_pvc; - int len = (hdlc->state.fr.settings.lmi == LMI_ANSI) ? LMI_ANSI_LENGTH - : LMI_LENGTH; - int stat_len = 3; + int lmi = hdlc->state.fr.settings.lmi; + int dce = hdlc->state.fr.settings.dce; + int len = lmi == LMI_ANSI ? LMI_ANSI_LENGTH : LMI_CCITT_CISCO_LENGTH; + int stat_len = (lmi == LMI_CISCO) ? 6 : 3; u8 *data; int i = 0; - if (hdlc->state.fr.settings.dce && fullrep) { + if (dce && fullrep) { len += hdlc->state.fr.dce_pvc_count * (2 + stat_len); if (len > HDLC_MAX_MRU) { printk(KERN_WARNING "%s: Too many PVCs while sending " @@ -484,29 +468,31 @@ } memset(skb->data, 0, len); skb_reserve(skb, 4); - skb->protocol = __constant_htons(LMI_PROTO); - fr_hard_header(&skb, LMI_DLCI); + if (lmi == LMI_CISCO) { + skb->protocol = __constant_htons(NLPID_CISCO_LMI); + fr_hard_header(&skb, LMI_CISCO_DLCI); + } else { + skb->protocol = __constant_htons(NLPID_CCITT_ANSI_LMI); + fr_hard_header(&skb, LMI_CCITT_ANSI_DLCI); + } data = skb->tail; data[i++] = LMI_CALLREF; - data[i++] = hdlc->state.fr.settings.dce - ? LMI_STATUS : LMI_STATUS_ENQUIRY; - if (hdlc->state.fr.settings.lmi == LMI_ANSI) + data[i++] = dce ? LMI_STATUS : LMI_STATUS_ENQUIRY; + if (lmi == LMI_ANSI) data[i++] = LMI_ANSI_LOCKSHIFT; - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_REPTYPE : LMI_REPTYPE; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_REPTYPE : + LMI_ANSI_CISCO_REPTYPE; data[i++] = LMI_REPT_LEN; data[i++] = fullrep ? LMI_FULLREP : LMI_INTEGRITY; - - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_ALIVE : LMI_ALIVE; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_ALIVE : LMI_ANSI_CISCO_ALIVE; data[i++] = LMI_INTEG_LEN; data[i++] = hdlc->state.fr.txseq =fr_lmi_nextseq(hdlc->state.fr.txseq); data[i++] = hdlc->state.fr.rxseq; - if (hdlc->state.fr.settings.dce && fullrep) { + if (dce && fullrep) { while (pvc) { - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_PVCSTAT : LMI_PVCSTAT; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_PVCSTAT : + LMI_ANSI_CISCO_PVCSTAT; data[i++] = stat_len; /* LMI start/restart */ @@ -523,8 +509,20 @@ fr_log_dlci_active(pvc); } - dlci_to_status(pvc->dlci, data + i, - pvc->state.active, pvc->state.new); + if (lmi == LMI_CISCO) { + data[i] = pvc->dlci >> 8; + data[i + 1] = pvc->dlci & 0xFF; + } else { + data[i] = (pvc->dlci >> 4) & 0x3F; + data[i + 1] = ((pvc->dlci << 3) & 0x78) | 0x80; + data[i + 2] = 0x80; + } + + if (pvc->state.new) + data[i + 2] |= 0x08; + else if (pvc->state.active) + data[i + 2] |= 0x02; + i += stat_len; pvc = pvc->next; } @@ -569,6 +567,8 @@ pvc_carrier(0, pvc); pvc->state.exist = pvc->state.active = 0; pvc->state.new = 0; + if (!hdlc->state.fr.settings.dce) + pvc->state.bandwidth = 0; pvc = pvc->next; } } @@ -583,11 +583,12 @@ int i, cnt = 0, reliable; u32 list; - if (hdlc->state.fr.settings.dce) + if (hdlc->state.fr.settings.dce) { reliable = hdlc->state.fr.request && time_before(jiffies, hdlc->state.fr.last_poll + hdlc->state.fr.settings.t392 * HZ); - else { + hdlc->state.fr.request = 0; + } else { hdlc->state.fr.last_errors <<= 1; /* Shift the list */ if (hdlc->state.fr.request) { if (hdlc->state.fr.reliable) @@ -634,65 +635,88 @@ static int fr_lmi_recv(struct net_device *dev, struct sk_buff *skb) { hdlc_device *hdlc = dev_to_hdlc(dev); - int stat_len; pvc_device *pvc; - int reptype = -1, error, no_ram; u8 rxseq, txseq; - int i; + int lmi = hdlc->state.fr.settings.lmi; + int dce = hdlc->state.fr.settings.dce; + int stat_len = (lmi == LMI_CISCO) ? 6 : 3, reptype, error, no_ram, i; - if (skb->len < ((hdlc->state.fr.settings.lmi == LMI_ANSI) - ? LMI_ANSI_LENGTH : LMI_LENGTH)) { + if (skb->len < (lmi == LMI_ANSI ? LMI_ANSI_LENGTH : + LMI_CCITT_CISCO_LENGTH)) { printk(KERN_INFO "%s: Short LMI frame\n", dev->name); return 1; } - if (skb->data[5] != (!hdlc->state.fr.settings.dce ? - LMI_STATUS : LMI_STATUS_ENQUIRY)) { - printk(KERN_INFO "%s: LMI msgtype=%x, Not LMI status %s\n", - dev->name, skb->data[2], - hdlc->state.fr.settings.dce ? "enquiry" : "reply"); + if (skb->data[3] != (lmi == LMI_CISCO ? NLPID_CISCO_LMI : + NLPID_CCITT_ANSI_LMI)) { + printk(KERN_INFO "%s: Received non-LMI frame with LMI" + " DLCI\n", dev->name); return 1; } - i = (hdlc->state.fr.settings.lmi == LMI_ANSI) ? 7 : 6; + if (skb->data[4] != LMI_CALLREF) { + printk(KERN_INFO "%s: Invalid LMI Call reference (0x%02X)\n", + dev->name, skb->data[4]); + return 1; + } + + if (skb->data[5] != (dce ? LMI_STATUS_ENQUIRY : LMI_STATUS)) { + printk(KERN_INFO "%s: Invalid LMI Message type (0x%02X)\n", + dev->name, skb->data[5]); + return 1; + } + + if (lmi == LMI_ANSI) { + if (skb->data[6] != LMI_ANSI_LOCKSHIFT) { + printk(KERN_INFO "%s: Not ANSI locking shift in LMI" + " message (0x%02X)\n", dev->name, skb->data[6]); + return 1; + } + i = 7; + } else + i = 6; - if (skb->data[i] != - ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_REPTYPE : LMI_REPTYPE)) { - printk(KERN_INFO "%s: Not a report type=%x\n", + if (skb->data[i] != (lmi == LMI_CCITT ? LMI_CCITT_REPTYPE : + LMI_ANSI_CISCO_REPTYPE)) { + printk(KERN_INFO "%s: Not an LMI Report type IE (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - i++; /* Skip length field */ + if (skb->data[++i] != LMI_REPT_LEN) { + printk(KERN_INFO "%s: Invalid LMI Report type IE length" + " (%u)\n", dev->name, skb->data[i]); + return 1; + } - reptype = skb->data[i++]; + reptype = skb->data[++i]; + if (reptype != LMI_INTEGRITY && reptype != LMI_FULLREP) { + printk(KERN_INFO "%s: Unsupported LMI Report type (0x%02X)\n", + dev->name, reptype); + return 1; + } - if (skb->data[i]!= - ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_ALIVE : LMI_ALIVE)) { - printk(KERN_INFO "%s: Unsupported status element=%x\n", - dev->name, skb->data[i]); + if (skb->data[++i] != (lmi == LMI_CCITT ? LMI_CCITT_ALIVE : + LMI_ANSI_CISCO_ALIVE)) { + printk(KERN_INFO "%s: Not an LMI Link integrity verification" + " IE (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - i++; /* Skip length field */ + if (skb->data[++i] != LMI_INTEG_LEN) { + printk(KERN_INFO "%s: Invalid LMI Link integrity verification" + " IE length (%u)\n", dev->name, skb->data[i]); + return 1; + } + i++; hdlc->state.fr.rxseq = skb->data[i++]; /* TX sequence from peer */ rxseq = skb->data[i++]; /* Should confirm our sequence */ txseq = hdlc->state.fr.txseq; - if (hdlc->state.fr.settings.dce) { - if (reptype != LMI_FULLREP && reptype != LMI_INTEGRITY) { - printk(KERN_INFO "%s: Unsupported report type=%x\n", - dev->name, reptype); - return 1; - } + if (dce) hdlc->state.fr.last_poll = jiffies; - } error = 0; if (!hdlc->state.fr.reliable) @@ -703,7 +727,7 @@ error = 1; } - if (hdlc->state.fr.settings.dce) { + if (dce) { if (hdlc->state.fr.fullrep_sent && !error) { /* Stop sending full report - the last one has been confirmed by DTE */ hdlc->state.fr.fullrep_sent = 0; @@ -725,6 +749,7 @@ hdlc->state.fr.dce_changed = 0; } + hdlc->state.fr.request = 1; /* got request */ fr_lmi_send(dev, reptype == LMI_FULLREP ? 1 : 0); return 0; } @@ -739,7 +764,6 @@ if (reptype != LMI_FULLREP) return 0; - stat_len = 3; pvc = hdlc->state.fr.first_pvc; while (pvc) { @@ -750,24 +774,35 @@ no_ram = 0; while (skb->len >= i + 2 + stat_len) { u16 dlci; + u32 bw; unsigned int active, new; - if (skb->data[i] != ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_PVCSTAT : LMI_PVCSTAT)) { - printk(KERN_WARNING "%s: Invalid PVCSTAT ID: %x\n", - dev->name, skb->data[i]); + if (skb->data[i] != (lmi == LMI_CCITT ? LMI_CCITT_PVCSTAT : + LMI_ANSI_CISCO_PVCSTAT)) { + printk(KERN_INFO "%s: Not an LMI PVC status IE" + " (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - if (skb->data[i] != stat_len) { - printk(KERN_WARNING "%s: Invalid PVCSTAT length: %x\n", - dev->name, skb->data[i]); + if (skb->data[++i] != stat_len) { + printk(KERN_INFO "%s: Invalid LMI PVC status IE length" + " (%u)\n", dev->name, skb->data[i]); return 1; } i++; - dlci = status_to_dlci(skb->data + i, &active, &new); + new = !! (skb->data[i + 2] & 0x08); + active = !! (skb->data[i + 2] & 0x02); + if (lmi == LMI_CISCO) { + dlci = (skb->data[i] << 8) | skb->data[i + 1]; + bw = (skb->data[i + 3] << 16) | + (skb->data[i + 4] << 8) | + (skb->data[i + 5]); + } else { + dlci = ((skb->data[i] & 0x3F) << 4) | + ((skb->data[i + 1] & 0x78) >> 3); + bw = 0; + } pvc = add_pvc(dev, dlci); @@ -783,9 +818,11 @@ pvc->state.deleted = 0; if (active != pvc->state.active || new != pvc->state.new || + bw != pvc->state.bandwidth || !pvc->state.exist) { pvc->state.new = new; pvc->state.active = active; + pvc->state.bandwidth = bw; pvc_carrier(active, pvc); fr_log_dlci_active(pvc); } @@ -801,6 +838,7 @@ pvc_carrier(0, pvc); pvc->state.active = pvc->state.new = 0; pvc->state.exist = 0; + pvc->state.bandwidth = 0; fr_log_dlci_active(pvc); } pvc = pvc->next; @@ -829,22 +867,15 @@ dlci = q922_to_dlci(skb->data); - if (dlci == LMI_DLCI) { - if (hdlc->state.fr.settings.lmi == LMI_NONE) - goto rx_error; /* LMI packet with no LMI? */ - - if (data[3] == LMI_PROTO) { - if (fr_lmi_recv(ndev, skb)) - goto rx_error; - else { - dev_kfree_skb_any(skb); - return NET_RX_SUCCESS; - } - } - - printk(KERN_INFO "%s: Received non-LMI frame with LMI DLCI\n", - ndev->name); - goto rx_error; + if ((dlci == LMI_CCITT_ANSI_DLCI && + (hdlc->state.fr.settings.lmi == LMI_ANSI || + hdlc->state.fr.settings.lmi == LMI_CCITT)) || + (dlci == LMI_CISCO_DLCI && + hdlc->state.fr.settings.lmi == LMI_CISCO)) { + if (fr_lmi_recv(ndev, skb)) + goto rx_error; + dev_kfree_skb_any(skb); + return NET_RX_SUCCESS; } pvc = find_pvc(hdlc, dlci); @@ -1170,7 +1201,8 @@ if ((new_settings.lmi != LMI_NONE && new_settings.lmi != LMI_ANSI && - new_settings.lmi != LMI_CCITT) || + new_settings.lmi != LMI_CCITT && + new_settings.lmi != LMI_CISCO) || new_settings.t391 < 1 || new_settings.t392 < 2 || new_settings.n391 < 1 || --- linux-2.6/drivers/net/wan/hdlc_generic.c 3 Jun 2004 05:04:21 -0000 1.15 +++ linux-2.6/drivers/net/wan/hdlc_generic.c 2 Apr 2005 13:12:18 -0000 @@ -1,7 +1,7 @@ /* * Generic HDLC support routines for Linux * - * Copyright (C) 1999 - 2003 Krzysztof Halasa + * Copyright (C) 1999 - 2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -38,7 +38,7 @@ #include -static const char* version = "HDLC support module revision 1.17"; +static const char* version = "HDLC support module revision 1.18"; #undef DEBUG_LINK @@ -126,10 +126,13 @@ if (!hdlc->open) goto carrier_exit; - if (hdlc->carrier) + if (hdlc->carrier) { + printk(KERN_INFO "%s: Carrier detected\n", dev->name); __hdlc_set_carrier_on(dev); - else + } else { + printk(KERN_INFO "%s: Carrier lost\n", dev->name); __hdlc_set_carrier_off(dev); + } carrier_exit: spin_unlock_irqrestore(&hdlc->state_lock, flags); @@ -157,8 +160,11 @@ spin_lock_irq(&hdlc->state_lock); - if (hdlc->carrier) + if (hdlc->carrier) { + printk(KERN_INFO "%s: Carrier detected\n", dev->name); __hdlc_set_carrier_on(dev); + } else + printk(KERN_INFO "%s: No carrier\n", dev->name); hdlc->open = 1; --=-=-=-- From Robert.Olsson@data.slu.se Sat Apr 2 05:48:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 05:48:49 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32Dmir2005056 for ; Sat, 2 Apr 2005 05:48:44 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j32DmWJo028236; Sat, 2 Apr 2005 15:48:33 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id AA1B9EE2B1; Sat, 2 Apr 2005 15:48:32 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16974.41648.568927.54429@robur.slu.se> Date: Sat, 2 Apr 2005 15:48:32 +0200 To: Eric Dumazet Cc: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <424E641A.1020609@cosmosbay.com> References: <424E641A.1020609@cosmosbay.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Eric Dumazet writes: > > This patch is doing too many things. How about splitting it up? > > > > For instance the spin lock stuff is pretty straightforward and > > should be in its own patch. Yes a good idea so it can be tested separatly.... > > The benefits of the GC changes are not obvious to me. rt_check_expire > > is simply meant to kill off old entries. It's not really meant to be > > used to free up entries when the table gets full. Agree with Herbert... > entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| > out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| > | | tot| mc| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| > _search|t_search| > 2618087| 28581| 7673| 0| 0| 0| 0| 0| 1800| 1450| 0| 0| 0| 0| 0| > Without serious tuning, this machine could not handle this load, or even half of it. Yes thats a pretty much load. Very short flows some reason? What's your ip_rt_gc_min_interval? GC should be allowed to run frequent to smoothen out the GC load. Also good idea to decrease gc_thresh and you hash is really huge. > Crashes usually occurs when secret_interval interval is elapsed : rt_cache_flush(0); is called, and the whole machine begins to die. A good idea to increase the secret_interval interval but it should survive. --ro From dada1@cosmosbay.com Sat Apr 2 06:00:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 06:00:24 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32E0I23005893 for ; Sat, 2 Apr 2005 06:00:19 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j32DwuRD012090; Sat, 2 Apr 2005 15:59:02 +0200 Message-ID: <424EA51F.6000300@cosmosbay.com> Date: Sat, 02 Apr 2005 15:58:55 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, hadi@cyberus.ca Subject: Re: Get rid of rt_check_expire and rt_garbage_collect References: <424E641A.1020609@cosmosbay.com> <20050402112304.GA11321@gondor.apana.org.au> In-Reply-To: <20050402112304.GA11321@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Sat, 02 Apr 2005 15:59:03 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Herbert Xu a écrit : > On Sat, Apr 02, 2005 at 11:21:30AM +0200, Eric Dumazet wrote: > >>Well, I began my work because of the overflow bug in rt_check_expire()... >>Then I realize this function could not work as expected. On a loaded >>machine, one timer tick is 1 ms. >>During this time, number of chains that are scanned is ridiculous. >>With the standard timer of 60 second, fact is rt_check_expire() is useless. > > > I see. What we've got here is a scalability problem with respect > to the number of hash buckets. As the number of buckets increases, > the amount of work the timer GC has to perform inreases proportionally. > > Since the timer GC parameters are fixed, this will eventually break. > > Rather than changing the timer GC so that it runs more often to keep > up with the large routing cache, we should get out of this by reducing > the amount of work we have to do. > > Imagine an ideal balanced hash table with 2.6 million entries. That > is, all incoming/outgoing packets belong to flows that are already in > the hash table. Imagine also that there is no PMTU/link failure taking > place so all entries are valid forever. > > In this state there is absolutely no need to execute the timer GC. > > Let's remove one of those assumptions and allow there to be entries > which need to expire after a set period. > > Instead of having the timer GC clean them up, we can move the expire > check to the place where the entries are used. That is, we make > ip_route_input/ip_route_output/ipv4_dst_check check whether the > entry has expired. > > On the face of it we're doing more work since every routing cache > hit will need to check the validity of the dst. However, because > it's a single subtraction it is actually pretty cheap. There is > also no additional cache miss compared to doing it in the timer > GC since we have to read the dst anyway. > > Let's go one step further and make the routing cache come to life. > Now there are new entries coming in and we need to remove old ones > in order to make room for them. > > That task is currently carried out by the timer GC in rt_check_expire > and on demand by rt_garbage_collect. Either way we have to walk the > entire routing cache looking for entries to get rid of. > > This is quite expensive when the routing cache is large. However, > there is a better way. > > The reason we keep a cap on the routing cache (for a given hash size) > is so that individual chains do not degenerate into long linked lists. > > In other words, we don't really care about how many entries there are > in the routing cache. But we do care about how long each hash chain > is. > > So instead of walking the entire routing cache to keep the number of > entries down, what we should do is keep each hash chain as short as > possible. > > Assuming that the hash function is good, this should achieve the > same end result. > > Here is how it can be done: Every time a routing entry is inserted into > a hash chain, we perform GC on that chain unconditionally. > > It might seem that we're doing more work again. However, as before > because we're traversing the chain anyway, it is very cheap to perform > the GC operations which mainly involve the checks in rt_may_expire. > > OK that's enough thinking and it's time to write some code to see > whether this is all bullshit :) > > Cheers, Well, it may work if you dont care about memory used. # grep dst /proc/slabinfo ip_dst_cache 2825575 2849590 384 10 1 : tunables 54 27 8 : slabdata 284959 284959 0 On this machine, route cache takes 1.1 GB of ram... impressive. Then if the network load decrease (or completely stop), only a timer driven gc could purge the cache. So rt_check_expire() is *needed* You are right saying that gc parameters are fixed, thus gc breaks at high load. Eric From kuznet@yakov.inr.ac.ru Sat Apr 2 06:01:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 06:01:55 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j32E1nGS006071 for ; Sat, 2 Apr 2005 06:01:50 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=B8c1/dbp/mKlnqQmR1uEiCDuXy7JrqjD3TOaLRO6GavyKIR5pkkfrtTkqwrL2rqtDeKJl2ixtsTFnEwsjwFigj4zaLU4CR6XietT3qfLyqFjhM4vvihNur9oHqnMiVZdxEMSzE2amGZimpXr59CxLROBlINBibpA7S6BSMOpbq8=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id SAA13068; Sat, 2 Apr 2005 18:00:19 +0400 Date: Sat, 2 Apr 2005 18:00:19 +0400 From: Alexey Kuznetsov To: jamal Cc: Herbert Xu , "David S. Miller" , Masahide NAKAMURA , psec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com, kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com Subject: Re: IPSEC: on behavior of acquire Message-ID: <20050402140019.GA13017@yakov.inr.ac.ru> References: <1112405144.1096.33.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112405144.1096.33.camel@jzny.localdomain> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > a) -ERESTART is the correct signal to return Right behaviour is to behave like ARP. A few of packets are queued, no errors (until timeout), no blocking. Alexey From Robert.Olsson@data.slu.se Sat Apr 2 06:04:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 06:04:30 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32E4PT9007106 for ; Sat, 2 Apr 2005 06:04:25 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j32E3gvg029545; Sat, 2 Apr 2005 16:03:43 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id C0F16EE2B2; Sat, 2 Apr 2005 16:03:42 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16974.42558.753736.846391@robur.slu.se> Date: Sat, 2 Apr 2005 16:03:42 +0200 To: Herbert Xu Cc: Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, hadi@cyberus.ca Subject: Get rid of rt_check_expire and rt_garbage_collect In-Reply-To: <20050402112304.GA11321@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <20050402112304.GA11321@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Herbert Xu writes: > Rather than changing the timer GC so that it runs more often to keep > up with the large routing cache, we should get out of this by reducing > the amount of work we have to do. Yeep. > Imagine an ideal balanced hash table with 2.6 million entries. That > is, all incoming/outgoing packets belong to flows that are already in > the hash table. Imagine also that there is no PMTU/link failure taking > place so all entries are valid forever. > > In this state there is absolutely no need to execute the timer GC. > Let's remove one of those assumptions and allow there to be entries > which need to expire after a set period. > > Instead of having the timer GC clean them up, we can move the expire > check to the place where the entries are used. That is, we make > ip_route_input/ip_route_output/ipv4_dst_check check whether the > entry has expired. > > On the face of it we're doing more work since every routing cache > hit will need to check the validity of the dst. However, because > it's a single subtraction it is actually pretty cheap. There is > also no additional cache miss compared to doing it in the timer > GC since we have to read the dst anyway. > > Let's go one step further and make the routing cache come to life. > Now there are new entries coming in and we need to remove old ones > in order to make room for them. > > That task is currently carried out by the timer GC in rt_check_expire > and on demand by rt_garbage_collect. Either way we have to walk the > entire routing cache looking for entries to get rid of. > > This is quite expensive when the routing cache is large. However, > there is a better way. > > The reason we keep a cap on the routing cache (for a given hash size) > is so that individual chains do not degenerate into long linked lists. > > In other words, we don't really care about how many entries there are > in the routing cache. But we do care about how long each hash chain > is. > > So instead of walking the entire routing cache to keep the number of > entries down, what we should do is keep each hash chain as short as > possible. > > Assuming that the hash function is good, this should achieve the > same end result. > > Here is how it can be done: Every time a routing entry is inserted into > a hash chain, we perform GC on that chain unconditionally. > > It might seem that we're doing more work again. However, as before > because we're traversing the chain anyway, it is very cheap to perform > the GC operations which mainly involve the checks in rt_may_expire. Agree... It's very interesting and worth to test something like this. also it could clean up the GC process and the need for tuning which would be very welcome. --ro From dada1@cosmosbay.com Sat Apr 2 06:10:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 06:10:55 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32EAnSm007751 for ; Sat, 2 Apr 2005 06:10:50 -0800 Received: from [192.168.0.3] ([84.5.129.64]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j32EACvQ012304; Sat, 2 Apr 2005 16:10:17 +0200 Message-ID: <424EA7C2.6060308@cosmosbay.com> Date: Sat, 02 Apr 2005 16:10:10 +0200 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Robert Olsson CC: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> In-Reply-To: <16974.41648.568927.54429@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Sat, 02 Apr 2005 16:10:18 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Robert Olsson a écrit : > Eric Dumazet writes: > Yes thats a pretty much load. Very short flows some reason? Well... yes. This is a real server, not a DOS simulation. 1 million TCP flows, and about 3 million peers using UDP frames. > What's your ip_rt_gc_min_interval? GC should be allowed to > run frequent to smoothen out the GC load. Also good idea > to decrease gc_thresh and you hash is really huge. No. As soon as I lower gc_thresh (and let gc running), the machine starts to drop connections and crash some seconds later. I found I had to make the hash table very large (but lowering elasticity, ie chain length) . It needs lot of ram, but at least CPU usage of net/ipv4/route.c is close to 0. # grep . /proc/sys/net/ipv4/route/* /proc/sys/net/ipv4/route/error_burst:5000 /proc/sys/net/ipv4/route/error_cost:1000 /proc/sys/net/ipv4/route/gc_elasticity:2 /proc/sys/net/ipv4/route/gc_interval:1 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:2900000 /proc/sys/net/ipv4/route/gc_timeout:155 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:16777216 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:20 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:20480 /proc/sys/net/ipv4/route/secret_interval:36000 From Robert.Olsson@data.slu.se Sat Apr 2 06:47:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 06:47:09 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32El4NW009228 for ; Sat, 2 Apr 2005 06:47:05 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j32EkV4m000845; Sat, 2 Apr 2005 16:46:31 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 63253EE2B1; Sat, 2 Apr 2005 16:46:31 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16974.45127.318022.377635@robur.slu.se> Date: Sat, 2 Apr 2005 16:46:31 +0200 To: Eric Dumazet Cc: Robert Olsson , Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <424EA7C2.6060308@cosmosbay.com> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <424EA7C2.6060308@cosmosbay.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Eric Dumazet writes: > Well... yes. This is a real server, not a DOS simulation. > 1 million TCP flows, and about 3 million peers using UDP frames. I see. > > What's your ip_rt_gc_min_interval? GC should be allowed to > > run frequent to smoothen out the GC load. Also good idea > > to decrease gc_thresh and you hash is really huge. > No. As soon as I lower gc_thresh (and let gc running), the machine starts to drop connections and crash some seconds later. > I found I had to make the hash table very large (but lowering elasticity, ie chain length) . > It needs lot of ram, but at least CPU usage of net/ipv4/route.c is close to 0. OK! Not so bad. Most of your GC likely happens in rt_intern_hash chain pruning. This way you keep hash-chains short and get "datadriven" GC. But there must be bugs causing the crash... Maybe there should be an explicit control hash lengths not via elasticity but adding even more tuning knobs hurts. :) --ro From andrea@suse.de Sat Apr 2 07:01:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 07:01:33 -0800 (PST) Received: from g5.random (ppp-217-133-42-200.cust-adsl.tiscali.it [217.133.42.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32F1RNf010182 for ; Sat, 2 Apr 2005 07:01:28 -0800 Received: by g5.random (Postfix, from userid 500) id 308A05753AA; Sat, 2 Apr 2005 17:01:17 +0200 (CEST) Date: Sat, 2 Apr 2005 17:01:17 +0200 From: Andrea Arcangeli To: Greg KH Cc: jaganav@us.ibm.com, Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050402150116.GU29492@g5.random> References: <20050401154348.553f3c46@dxpl.pdx.osdl.net> <1112405833.424df749e61b5@imap.linux.ibm.com> <20050402052738.GA17506@kroah.com> <20050402060216.GA17766@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402060216.GA17766@kroah.com> X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: netdev On Fri, Apr 01, 2005 at 10:02:16PM -0800, Greg KH wrote: > If you all wish to duplicate this stupidity, feel free, but do not > expect to get any help from the community... And just in case: do not expect to be allowed to use stuff like the rbtree.[ch] which is GPL'd (not LGPL). (ib patches from topspin originally relicensed rbtree.[ch] under BSD...) From jheffner@psc.edu Sat Apr 2 07:33:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 07:33:23 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32FXAWu011778 for ; Sat, 2 Apr 2005 07:33:11 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j32FbOUl023976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 10:37:25 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j32FWXP1021028; Sat, 2 Apr 2005 10:32:33 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j32FWWVo021025; Sat, 2 Apr 2005 10:32:33 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Sat, 2 Apr 2005 10:32:32 -0500 (EST) From: John Heffner To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] skb pcount with MTU discovery In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev On Sat, 2 Apr 2005, Herbert Xu wrote: > How about fixing tcp_snd_test directly like this? I tried that first, but it caused a panic. I assumed some other point in the code assumed that invariant that if TSO is disabled then tso_segs==1. I didn't investigate though. > Of course all this will be moot once Dave finishes his TSO rewrite :) That will make things much simpler. ;) -John From dmitry_yus@yahoo.com Sat Apr 2 10:08:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 10:08:48 -0800 (PST) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j32I8gNY020564 for ; Sat, 2 Apr 2005 10:08:42 -0800 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp014.mail.yahoo.com with SMTP; 2 Apr 2005 18:08:42 -0000 Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics From: Dmitry Yusupov To: "open-iscsi@googlegroups.com" Cc: "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <20050328223203.GC28983@kvack.org> References: <20050324215922.GT14202@opteron.random> <424346FE.20704@cs.wisc.edu> <20050324233921.GZ14202@opteron.random> <20050325034341.GV32638@waste.org> <20050327035149.GD4053@g5.random> <20050327054831.GA15453@waste.org> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@davemloft.net> <52vf7bwo4w.fsf@topspin.com> <1112042936.5088.22.camel@beastie> <20050328223203.GC28983@kvack.org> Content-Type: text/plain Date: Sat, 02 Apr 2005 10:08:37 -0800 Message-Id: <1112465317.24936.10.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev On Mon, 2005-03-28 at 17:32 -0500, Benjamin LaHaise wrote: > On Mon, Mar 28, 2005 at 12:48:56PM -0800, Dmitry Yusupov wrote: > > If you have plans to start new project such as SoftRDMA than yes. lets > > discuss it since set of problems will be similar to what we've got with > > software iSCSI Initiators. > > I'm somewhat interested in seeing a SoftRDMA project get off the ground. > At least the NatSemi 83820 gige MAC is able to provide early-rx interrupts > that allow one to get an rx interrupt before the full payload has arrived > making it possible to write out a new rx descriptor to place the payload > wherever it is ultimately desired. It would be fun to work on if not the > most performant RDMA implementation. I see a lot of skepticism around early-rx interrupt schema. It might work for gige, but i'm not sure if it will fit into 10g. What RDMA gives us is zero-copy on receive and new networking api which has a potential to be HW accelerated. SoftRDMA will never avoid copying on receive. But benefit for SoftRDMA would be its availability on client sides. It is free and it could be easily deployed. Soon Intel & Co will give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if one of those cores will do receive side copying? From willy@www.linux.org.uk Sat Apr 2 10:27:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 10:27:29 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32IRI3F021472 for ; Sat, 2 Apr 2005 10:27:19 -0800 Received: from willy by parcelfarce.linux.theplanet.co.uk with local (Exim 4.33) id 1DHnKy-000079-IH; Sat, 02 Apr 2005 19:27:12 +0100 Date: Sat, 2 Apr 2005 19:27:12 +0100 From: Matthew Wilcox To: jaganav@us.ibm.com Cc: Greg KH , Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050402182712.GA24234@parcelfarce.linux.theplanet.co.uk> References: <1112426991.424e49ef57e2b@imap.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112426991.424e49ef57e2b@imap.linux.ibm.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 02:29:51AM -0500, jaganav@us.ibm.com wrote: > If this dual license is a concern to other kernel developers as well from > contributing to OpenRDMA, we would seriously consider this and discuss with the > adapter vendors. Yes, it's a serious concern. Please release the code under the GPL only. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain From linux781@gmail.com Sat Apr 2 10:44:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 10:44:19 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32IiEuN022356 for ; Sat, 2 Apr 2005 10:44:15 -0800 Received: by zproxy.gmail.com with SMTP id 8so55531nzo for ; Sat, 02 Apr 2005 10:44:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aKGmZ4hpLJ7N6OferqIHuGfei+vozd7D7DoJc0CZObBsEX+Mu5qTTB2axEchIpMcZemzRqQPeQ3kqgriTNrooAzSnyHNVIfRqNKlktYZmVTUwbwciM5zfsmetes3V//dC4xOy547FvLkVteeFFTwsAJCOhvnu2XlwfTox/mL+Kw= Received: by 10.36.74.14 with SMTP id w14mr23466nza; Sat, 02 Apr 2005 10:44:07 -0800 (PST) Received: by 10.36.58.7 with HTTP; Sat, 2 Apr 2005 10:44:07 -0800 (PST) Message-ID: <72252ed0504021044e69d634@mail.gmail.com> Date: Sat, 2 Apr 2005 13:44:07 -0500 From: Akshay Kawale Reply-To: Akshay Kawale To: netdev@oss.sgi.com Subject: Re: Difference between skb_put() and skb_push() In-Reply-To: <72252ed05033021463a1f45b6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <72252ed05033021463a1f45b6@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux781@gmail.com Precedence: bulk X-list: netdev Hi, I am trying to access the tot_len field in the IP Header using a sk_buff structure inside a Netfilter hook. I do something like: (**skb).nh.iph->tot_len += 64 I have tried other variants of the same statement but none of them work. I want to increment the length by 64 bytes, but it gives me an error saying that I am trying to access an 'incomplete data type'. Can anyone shed some light on this problem? tot_len if of type __u16 (unsigned short int). Thanks. - Akshay From asgeir@chelsio.com Sat Apr 2 11:08:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:08:23 -0800 (PST) Received: from stargate.chelsio.com (stargate.chelsio.com [64.186.171.138] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32J8HZ2024757 for ; Sat, 2 Apr 2005 11:08:18 -0800 Received: from YOGI.asicdesigners.com (yogi.asicdesigners.com [10.192.160.7]) by stargate.chelsio.com (8.12.5/8.12.5) with SMTP id j32J7SfZ015126; Sat, 2 Apr 2005 11:07:28 -0800 Subject: RE: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit ProposedTopics Date: Sat, 2 Apr 2005 11:07:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit ProposedTopics content-class: urn:content-classes:message Thread-Index: AcU3rw1xnl0wdez6QdSv3xCWP+9qxgABjiog From: "Asgeir Eiriksson" To: "Dmitry Yusupov" , Cc: "David S. Miller" , , , , , , X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j32J8HZ2024757 X-archive-position: 1268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asgeir@chelsio.com Precedence: bulk X-list: netdev Dmitry The CPU cycles is only at most half of the story with the other half being the memory sub-system BW. So the validity of your observation depends on the BW we're talking about, i.e. if the client is using a fraction of 10Gbps for RDMA (or DDP, e.g. iSCSI DDP), yes then that fraction amounts to a fraction of the memory sub-system total BW so we don't much care about the extra copy. The situation is different if the client wants something close to 10Gbps (already have such client applications), because today 10Gbps is still a big chunk of the overall memory BW so you really care about eliminating that copy via DDP. 'Asgeir > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of Dmitry Yusupov > Sent: Saturday, April 02, 2005 10:09 AM > To: open-iscsi@googlegroups.com > Cc: David S. Miller; mpm@selenic.com; andrea@suse.de; > michaelc@cs.wisc.edu; James.Bottomley@HansenPartnership.com; ksummit-2005- > discuss@thunk.org; netdev@oss.sgi.com > Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit > ProposedTopics > > On Mon, 2005-03-28 at 17:32 -0500, Benjamin LaHaise wrote: > > On Mon, Mar 28, 2005 at 12:48:56PM -0800, Dmitry Yusupov wrote: > > > If you have plans to start new project such as SoftRDMA than yes. lets > > > discuss it since set of problems will be similar to what we've got > with > > > software iSCSI Initiators. > > > > I'm somewhat interested in seeing a SoftRDMA project get off the ground. > > At least the NatSemi 83820 gige MAC is able to provide early-rx > interrupts > > that allow one to get an rx interrupt before the full payload has > arrived > > making it possible to write out a new rx descriptor to place the payload > > wherever it is ultimately desired. It would be fun to work on if not > the > > most performant RDMA implementation. > > I see a lot of skepticism around early-rx interrupt schema. It might > work for gige, but i'm not sure if it will fit into 10g. > > What RDMA gives us is zero-copy on receive and new networking api which > has a potential to be HW accelerated. SoftRDMA will never avoid copying > on receive. But benefit for SoftRDMA would be its availability on client > sides. It is free and it could be easily deployed. Soon Intel & Co will > give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if > one of those cores will do receive side copying? > From laforge@gnumonks.org Sat Apr 2 11:11:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:11:49 -0800 (PST) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JBd6w025449 for ; Sat, 2 Apr 2005 11:11:40 -0800 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DHo1t-0000J3-L8 for netdev@oss.sgi.com; Sat, 02 Apr 2005 21:11:33 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DHo1s-0000mb-FR for netdev@oss.sgi.com; Sat, 02 Apr 2005 21:11:32 +0200 Date: Sat, 2 Apr 2005 21:11:32 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: pktgen problem (skb refcount) in 2.6.12-rc1 Message-ID: <20050402191132.GF1890@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hK8Uo4Yp55NZU70L" Content-Disposition: inline User-Agent: mutt-ng 1.5.8-r168i (Debian) X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --hK8Uo4Yp55NZU70L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've tried to get pktgen running on 2.6.12-rc1 (dual-opteron system, two dual e1000 boards). =20 It transmits the requested amount of packets, but the kernel thread(s) will continue to use 100% cpu even after that. I've tried to track the problem down, and I've confirmed that skb->users never goes down to 1 but instead stays at '2'. Therefore the while loop at line 2706 loops forever. Killing the kernel thread or configuring the interface down helps (as a kludge). However, the e1000 module will refuse to unload since apparently it's still referenced by that skb. The system is otherwise idle, and no fancy modules such as netfilter/iptables are loaded. The same system with the same pktgen script works fine with 2.6.11.6. I'm reporting this since it seems like it sounds like we have a skb usage count leak somewhere :( --=20 - Harald Welte http://gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --hK8Uo4Yp55NZU70L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCTu5kXaXGVTD0i/8RAnFTAJ0Zx+raxRpD3NBQYYp0vIh8uxK7lgCdFuqS cxrYExXXXuNnx4NAXVGfono= =9ULo -----END PGP SIGNATURE----- --hK8Uo4Yp55NZU70L-- From mingz@ele.uri.edu Sat Apr 2 11:13:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:13:35 -0800 (PST) Received: from leviathan.ele.uri.edu (leviathan.ele.uri.edu [131.128.51.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JDTJI025678 for ; Sat, 2 Apr 2005 11:13:30 -0800 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j32JDLCu013331; Sat, 2 Apr 2005 14:13:22 -0500 (EST) Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics From: Ming Zhang Reply-To: mingz@ele.uri.edu To: open-iscsi Cc: "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <1112465317.24936.10.camel@mylaptop> References: <20050324215922.GT14202@opteron.random> <424346FE.20704@cs.wisc.edu> <20050324233921.GZ14202@opteron.random> <20050325034341.GV32638@waste.org> <20050327035149.GD4053@g5.random> <20050327054831.GA15453@waste.org> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@davemloft.net> <52vf7bwo4w.fsf@topspin.com> <1112042936.5088.22.camel@beastie> <20050328223203.GC28983@kvack.org> <1112465317.24936.10.camel@mylaptop> Content-Type: text/plain Message-Id: <1112469200.4599.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 02 Apr 2005 14:13:21 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 13:08, Dmitry Yusupov wrote: > On Mon, 2005-03-28 at 17:32 -0500, Benjamin LaHaise wrote: > > On Mon, Mar 28, 2005 at 12:48:56PM -0800, Dmitry Yusupov wrote: > > > If you have plans to start new project such as SoftRDMA than yes. lets > > > discuss it since set of problems will be similar to what we've got with > > > software iSCSI Initiators. > > > > I'm somewhat interested in seeing a SoftRDMA project get off the ground. > > At least the NatSemi 83820 gige MAC is able to provide early-rx interrupts > > that allow one to get an rx interrupt before the full payload has arrived > > making it possible to write out a new rx descriptor to place the payload > > wherever it is ultimately desired. It would be fun to work on if not the > > most performant RDMA implementation. > > I see a lot of skepticism around early-rx interrupt schema. It might > work for gige, but i'm not sure if it will fit into 10g. > > What RDMA gives us is zero-copy on receive and new networking api which > has a potential to be HW accelerated. SoftRDMA will never avoid copying > on receive. But benefit for SoftRDMA would be its availability on client > sides. It is free and it could be easily deployed. Soon Intel & Co will > give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if > one of those cores will do receive side copying? > dedicated core to dealing with interrupt is fine. but the memory bandwidth is still over-used right? ming From mingz@ele.uri.edu Sat Apr 2 11:14:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:15:00 -0800 (PST) Received: from leviathan.ele.uri.edu (leviathan.ele.uri.edu [131.128.51.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JErRE026229 for ; Sat, 2 Apr 2005 11:14:54 -0800 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j32JElCu013372; Sat, 2 Apr 2005 14:14:47 -0500 (EST) Subject: RE: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit ProposedTopics From: Ming Zhang Reply-To: mingz@ele.uri.edu To: open-iscsi Cc: Dmitry Yusupov , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> Content-Type: text/plain Message-Id: <1112469286.4599.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 02 Apr 2005 14:14:47 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: netdev yes, thx for explaining this in more detail. copy avoidance is one main goal of rdma. the BW gap is the bottleneck. ming On Sat, 2005-04-02 at 14:07, Asgeir Eiriksson wrote: > Dmitry > > The CPU cycles is only at most half of the story with the other half > being the memory sub-system BW. > > So the validity of your observation depends on the BW we're talking > about, i.e. if the client is using a fraction of 10Gbps for RDMA (or > DDP, e.g. iSCSI DDP), yes then that fraction amounts to a fraction of > the memory sub-system total BW so we don't much care about the extra > copy. > > The situation is different if the client wants something close to 10Gbps > (already have such client applications), because today 10Gbps is still a > big chunk of the overall memory BW so you really care about eliminating > that copy via DDP. > > 'Asgeir > > > -----Original Message----- > > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > > Behalf Of Dmitry Yusupov > > Sent: Saturday, April 02, 2005 10:09 AM > > To: open-iscsi@googlegroups.com > > Cc: David S. Miller; mpm@selenic.com; andrea@suse.de; > > michaelc@cs.wisc.edu; James.Bottomley@HansenPartnership.com; > ksummit-2005- > > discuss@thunk.org; netdev@oss.sgi.com > > Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit > > ProposedTopics > > > > On Mon, 2005-03-28 at 17:32 -0500, Benjamin LaHaise wrote: > > > On Mon, Mar 28, 2005 at 12:48:56PM -0800, Dmitry Yusupov wrote: > > > > If you have plans to start new project such as SoftRDMA than yes. > lets > > > > discuss it since set of problems will be similar to what we've got > > with > > > > software iSCSI Initiators. > > > > > > I'm somewhat interested in seeing a SoftRDMA project get off the > ground. > > > At least the NatSemi 83820 gige MAC is able to provide early-rx > > interrupts > > > that allow one to get an rx interrupt before the full payload has > > arrived > > > making it possible to write out a new rx descriptor to place the > payload > > > wherever it is ultimately desired. It would be fun to work on if > not > > the > > > most performant RDMA implementation. > > > > I see a lot of skepticism around early-rx interrupt schema. It might > > work for gige, but i'm not sure if it will fit into 10g. > > > > What RDMA gives us is zero-copy on receive and new networking api > which > > has a potential to be HW accelerated. SoftRDMA will never avoid > copying > > on receive. But benefit for SoftRDMA would be its availability on > client > > sides. It is free and it could be easily deployed. Soon Intel & Co > will > > give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if > > one of those cores will do receive side copying? > > > > From hadi@cyberus.ca Sat Apr 2 11:20:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:20:26 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JKIHq027275 for ; Sat, 2 Apr 2005 11:20:18 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DHoAJ-00041A-W6 for netdev@oss.sgi.com; Sat, 02 Apr 2005 14:20:15 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHoAA-0004ZR-4O; Sat, 02 Apr 2005 14:20:06 -0500 Subject: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050402014619.GB24861@gondor.apana.org.au> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-g5r6p/Y+YZcaZoLnsgWz" Organization: jamalopolous Message-Id: <1112469601.1088.173.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 14:20:01 -0500 X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-g5r6p/Y+YZcaZoLnsgWz Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-04-01 at 20:46, Herbert Xu wrote: > On Fri, Apr 01, 2005 at 08:42:45PM -0500, jamal wrote: > > > > So always go v2? > > Yes since that's the only version that the kernel knows how to generate. Ok, heres a general patch first cut i think i got all that was discussed in there. ive done some basic 5 minutes tests on. Once we have agreement i will pass it on to Masahide-san to do more thorough testing. Look at the XXX comments in the patch. A couple of interesting things: 1) Weve discussed this before Herbert and i think you misspoke that pfkey delivers to all listerners. pfkey Add/del/upd now really do tell all processes about what happened. Before pfkey would skip the originating process. So far this doesnt seem to be an issue in the basic testing. 2) I ended adding a policy_notify to the pfkey manager to make the code generic. Interesting thing is i dont think pfkey knows what to do with policy expiration or i am misreading the code. I dont see any message type for policy expiration as i do for sa expiration. Ive put some hooks and a little noise. I could remove the printks - for now they are just place holders. cheers, jamal --=-g5r6p/Y+YZcaZoLnsgWz Content-Disposition: attachment; filename=ipsec-event-take2 Content-Type: text/plain; name=ipsec-event-take2; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 +++ b/include/net/xfrm.h 2005-04-02 11:59:17.000000000 -0500 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -802,7 +827,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-25 22:28:39.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-02 09:53:03.000000000 -0500 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-03-25 22:28:25.000000000 -0500 +++ b/net/xfrm/xfrm_state.c 2005-04-02 12:15:37.000000000 -0500 @@ -48,7 +48,7 @@ static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); static DEFINE_SPINLOCK(xfrm_state_gc_lock); -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); @@ -208,8 +208,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -236,14 +238,47 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +static DEFINE_RWLOCK(xfrm_km_lock); +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); + +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { + struct xfrm_mgr *km; + + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock(&xfrm_km_lock); +} + +void km_state_notify(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_mgr *km; + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + km->notify(x, c); + read_unlock(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +int xfrm_state_delete(struct xfrm_state *x) +{ + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -402,6 +437,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -764,37 +800,45 @@ } EXPORT_SYMBOL(xfrm_replay_advance); -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); -static DEFINE_RWLOCK(xfrm_km_lock); static void km_state_expired(struct xfrm_state *x, int hard) { - struct xfrm_mgr *km; + struct km_event c; if (hard) x->km.state = XFRM_STATE_EXPIRED; else x->km.dying = 1; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); - read_unlock(&xfrm_km_lock); + /* XXX: Do we wanna do this right at the top?? + * if the state is dead we dont want to announce + * the expire - a delete may already have announced + * it + */ + if (x->km.state == XFRM_STATE_DEAD) + return; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -819,13 +863,20 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + /* XXX: Do we still wanna wakeup km_waitq? + * if the policy is dead we dont want to announce + * the expire - a delete may already have announced + * it + */ + if (pol->dead) + return; + + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_policy.c 2005-03-25 22:28:21.000000000 -0500 +++ b/net/xfrm/xfrm_policy.c 2005-04-02 12:16:30.000000000 -0500 @@ -298,7 +298,7 @@ * entry dead. The rule must be unlinked from lists to the moment. */ -static void xfrm_policy_kill(struct xfrm_policy *policy) +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir) { write_lock_bh(&policy->lock); if (policy->dead) @@ -378,7 +378,7 @@ write_unlock_bh(&xfrm_policy_lock); if (delpol) { - xfrm_policy_kill(delpol); + xfrm_policy_kill(delpol, dir); } return 0; } @@ -402,7 +402,7 @@ if (pol && delete) { atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } return pol; } @@ -425,7 +425,7 @@ if (pol && delete) { atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } return pol; } @@ -442,7 +442,7 @@ xfrm_policy_list[dir] = xp->next; write_unlock_bh(&xfrm_policy_lock); - xfrm_policy_kill(xp); + xfrm_policy_kill(xp, dir); write_lock_bh(&xfrm_policy_lock); } @@ -558,7 +558,7 @@ if (pol) { if (dir < XFRM_POLICY_MAX) atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } } @@ -579,7 +579,7 @@ write_unlock_bh(&xfrm_policy_lock); if (old_pol) { - xfrm_policy_kill(old_pol); + xfrm_policy_kill(old_pol, dir); } return 0; } --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-02 12:21:32.000000000 -0500 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -285,14 +286,26 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +317,20 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -672,6 +695,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +707,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +718,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +845,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +874,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +888,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1111,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1128,94 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1349,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1361,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1369,90 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("Netlink Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-03-25 22:28:39.000000000 -0500 +++ b/net/key/af_key.c 2005-04-02 12:25:49.000000000 -0500 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1256,7 +1328,7 @@ if (hdr->sadb_msg_type == SADB_ADD) err = xfrm_state_add(x); - else + else err = xfrm_state_update(x); if (err < 0) { @@ -1265,27 +1337,22 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1368,20 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1519,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + // XXX:do we have to pass proto as well? + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_KERNEL, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1947,31 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1979,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2047,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2079,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,24 +2115,11 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); -out: xfrm_pol_put(xp); return err; } @@ -2037,8 +2129,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2141,19 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + /* + * XXX: previous get was doing a broadcast-all _always_ + * which didnt seem right for non-deletion case - JHS + * This is like the way netlink behaves .. + * Shall i restore original behavior? + */ + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2188,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2414,25 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + printk("pfkey doesnt deal with expired policies ..\n"); + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2451,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3004,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-g5r6p/Y+YZcaZoLnsgWz-- From liontooth@cogweb.net Sat Apr 2 11:25:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:25:57 -0800 (PST) Received: from weber.sscnet.ucla.edu (weber.sscnet.ucla.edu [128.97.42.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JPnCI027930 for ; Sat, 2 Apr 2005 11:25:49 -0800 Received: from localhost (localhost [127.0.0.1]) by weber.sscnet.ucla.edu (8.13.4/8.13.4) with ESMTP id j32JPj40013828; Sat, 2 Apr 2005 11:25:45 -0800 (PST) Received: from weber.sscnet.ucla.edu ([127.0.0.1]) by localhost (weber [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12686-02; Sat, 2 Apr 2005 11:25:45 -0800 (PST) Received: from [128.97.221.35] (clitunno.sscnet.ucla.edu [128.97.221.35]) by weber.sscnet.ucla.edu (8.13.4/8.13.4) with ESMTP id j32JPKtv013762; Sat, 2 Apr 2005 11:25:20 -0800 (PST) Message-ID: <424EF19B.7030105@cogweb.net> Date: Sat, 02 Apr 2005 11:25:15 -0800 From: David Liontooth User-Agent: Debian Thunderbird 1.0 (X11/20050118) X-Accept-Language: en-us, en MIME-Version: 1.0 To: venza@brownhat.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: ICS1883 LAN PHY not detected X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at weber.sscnet.ucla.edu X-Virus-Status: Clean X-archive-position: 1273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: liontooth@cogweb.net Precedence: bulk X-list: netdev Gigabyte's K8NS Ultra-939 mobo has a 100/10 LAN PHY chip, ICS1883, which isn't detected by the 2.6.12-rc1 kernel (and likely not previous kernels). http://www.giga-byte.com/MotherBoard/Products/Products_Spec_GA-K8NS%20Ultra-939.htm On the other hand, the ports light up when connected. The device may be similar to ICS1893, which is supported by the sis900 driver. However, I figure the device first has to be detected? Any advice appreciated. Dave # lspci 0000:00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1) 0000:00:01.0 ISA bridge: nVidia Corporation: Unknown device 00e0 (rev a2) 0000:00:01.1 SMBus: nVidia Corporation: Unknown device 00e4 (rev a1) 0000:00:02.0 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) 0000:00:02.1 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) 0000:00:02.2 USB Controller: nVidia Corporation: Unknown device 00e8 (rev a2) 0000:00:05.0 Bridge: nVidia Corporation: Unknown device 00df (rev a2) 0000:00:06.0 Multimedia audio controller: nVidia Corporation: Unknown device 00ea (rev a1) 0000:00:08.0 IDE interface: nVidia Corporation: Unknown device 00e5 (rev a2) 0000:00:0a.0 IDE interface: nVidia Corporation: Unknown device 00e3 (rev a2) 0000:00:0b.0 PCI bridge: nVidia Corporation: Unknown device 00e2 (rev a2) 0000:00:0e.0 PCI bridge: nVidia Corporation: Unknown device 00ed (rev a2) 0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 0000:02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) 0000:02:0d.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc)SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) 0000:02:0e.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) From herbert@gondor.apana.org.au Sat Apr 2 11:33:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:33:31 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JXLwe028654 for ; Sat, 2 Apr 2005 11:33:22 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHoMW-0006q1-00; Sun, 03 Apr 2005 05:32:52 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHoM5-0006YU-00; Sun, 03 Apr 2005 05:32:25 +1000 Date: Sun, 3 Apr 2005 05:32:24 +1000 To: Robert Olsson Cc: Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050402193224.GA25157@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16974.41648.568927.54429@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 03:48:32PM +0200, Robert Olsson wrote: > > > Crashes usually occurs when secret_interval interval is elapsed : rt_cache_flush(0); is called, and the whole machine begins to die. > > A good idea to increase the secret_interval interval but it should survive. Incidentally we should change the way the rehashing is triggered. Instead of doing it regularly, we can do it when we notice that a specific hash chain grows beyond a certain size. The idea is that if someone is attacking our hash then they can only do so by lengthening the chains. If they're not doing that then even if they knew how to attack us we don't really care. Of course when it does happen it'll still kill your machine unless we can find a way to amortise this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 2 11:36:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:36:34 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JaQoK029236 for ; Sat, 2 Apr 2005 11:36:27 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHoPX-0006qk-00; Sun, 03 Apr 2005 05:35:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHoPL-0006ZD-00; Sun, 03 Apr 2005 05:35:47 +1000 Date: Sun, 3 Apr 2005 05:35:47 +1000 To: John Heffner Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] skb pcount with MTU discovery Message-ID: <20050402193547.GB25157@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 10:32:32AM -0500, John Heffner wrote: > On Sat, 2 Apr 2005, Herbert Xu wrote: > > > How about fixing tcp_snd_test directly like this? > > I tried that first, but it caused a panic. I assumed some other point in > the code assumed that invariant that if TSO is disabled then tso_segs==1. > I didn't investigate though. Do you remember what the panic looked like? Perhaps it was because tso_segs wasn't set at all? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sat Apr 2 11:56:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 11:56:33 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32JuRLZ030268 for ; Sat, 2 Apr 2005 11:56:27 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DHoiO-0005Rw-00; Sat, 02 Apr 2005 11:55:28 -0800 Date: Sat, 2 Apr 2005 11:55:28 -0800 From: "David S. Miller" To: Herbert Xu Cc: Robert.Olsson@data.slu.se, dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050402115528.11f71a3c.davem@davemloft.net> In-Reply-To: <20050402193224.GA25157@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sun, 3 Apr 2005 05:32:24 +1000 Herbert Xu wrote: > On Sat, Apr 02, 2005 at 03:48:32PM +0200, Robert Olsson wrote: > > > > > Crashes usually occurs when secret_interval interval is elapsed : rt_cache_flush(0); is called, and the whole machine begins to die. > > > > A good idea to increase the secret_interval interval but it should survive. > > Incidentally we should change the way the rehashing is triggered. > Instead of doing it regularly, we can do it when we notice that a > specific hash chain grows beyond a certain size. > > The idea is that if someone is attacking our hash then they can > only do so by lengthening the chains. If they're not doing that > then even if they knew how to attack us we don't really care. Yes, the secret_interval is way too short. It is a very paranoid default value selected when initially fixing that DoS. I think we should, in the short term, increase the secret interval where it exists in the tree (netfilter conntrack is another instance for example). From hadi@cyberus.ca Sat Apr 2 12:47:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 12:47:49 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32KlhrM003188 for ; Sat, 2 Apr 2005 12:47:44 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DHpWx-000554-Hj for netdev@oss.sgi.com; Sat, 02 Apr 2005 15:47:43 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHpWt-00064y-PT; Sat, 02 Apr 2005 15:47:40 -0500 Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() From: jamal Reply-To: hadi@cyberus.ca To: Eric Dumazet Cc: Robert Olsson , Herbert Xu , "David S. Miller" , netdev In-Reply-To: <424EA7C2.6060308@cosmosbay.com> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <424EA7C2.6060308@cosmosbay.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: jamalopolous Message-Id: <1112474855.1096.274.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 15:47:36 -0500 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 09:10, Eric Dumazet wrote: > Robert Olsson a écrit : > > Eric Dumazet writes: > > > Yes thats a pretty much load. Very short flows some reason? > > Well... yes. This is a real server, not a DOS simulation. > 1 million TCP flows, and about 3 million peers using UDP frames. SMP? How many processors? cheers, jamal From hadi@cyberus.ca Sat Apr 2 13:06:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:06:09 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32L64CT004180 for ; Sat, 2 Apr 2005 13:06:04 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DHpog-0001SQ-QE for netdev@oss.sgi.com; Sat, 02 Apr 2005 16:06:02 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHpoe-00081M-08; Sat, 02 Apr 2005 16:06:00 -0500 Subject: Re: Get rid of rt_check_expire and rt_garbage_collect From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Eric Dumazet , "David S. Miller" , netdev , Robert Olsson In-Reply-To: <20050402112304.GA11321@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <20050402112304.GA11321@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112475955.1088.294.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 16:05:55 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 06:23, Herbert Xu wrote: > On Sat, Apr 02, 2005 at 11:21:30AM +0200, Eric Dumazet wrote: > > > > Well, I began my work because of the overflow bug in rt_check_expire()... > > Then I realize this function could not work as expected. On a loaded > > machine, one timer tick is 1 ms. > > During this time, number of chains that are scanned is ridiculous. > > With the standard timer of 60 second, fact is rt_check_expire() is useless. > > I see. What we've got here is a scalability problem with respect > to the number of hash buckets. As the number of buckets increases, > the amount of work the timer GC has to perform inreases proportionally. > Its classical incremental garbage collection algorithm thats being used i.e something along whats typically refered to as mark-and-sweep. Could the main issue be not the amount of routes in the cache but rather the locking when number of CPUs go up? Incrementing the timer frequency would certainly help but maybe have adverse effects if the frequency is too high because of the across system locking IMO. > Since the timer GC parameters are fixed, this will eventually break. > > Rather than changing the timer GC so that it runs more often to keep > up with the large routing cache, we should get out of this by reducing > the amount of work we have to do. > Refer to my hint above: perhaps per CPU caches? > Imagine an ideal balanced hash table with 2.6 million entries. That > is, all incoming/outgoing packets belong to flows that are already in > the hash table. Imagine also that there is no PMTU/link failure taking > place so all entries are valid forever. > > > In this state there is absolutely no need to execute the timer GC. > Yeah, but memory is finite friend. True, if you can imagine infinite memory we would not need gc ;-> > Let's remove one of those assumptions and allow there to be entries > which need to expire after a set period. > Instead of having the timer GC clean them up, we can move the expire > check to the place where the entries are used. That is, we make > ip_route_input/ip_route_output/ipv4_dst_check check whether the > entry has expired. > If you can show lock grabbing is the main contentious issue; i believe it is as CPUs go up. Then this is a valuable idea since you are already grabbing the locks anyways. > On the face of it we're doing more work since every routing cache > hit will need to check the validity of the dst. However, because > it's a single subtraction it is actually pretty cheap. There is > also no additional cache miss compared to doing it in the timer > GC since we have to read the dst anyway. > In the case of slower machine, the compute is also an issue. To be honest i feel like handwaving - experimenting and collecting profiles would help nail it. > Let's go one step further and make the routing cache come to life. > Now there are new entries coming in and we need to remove old ones > in order to make room for them. > > That task is currently carried out by the timer GC in rt_check_expire > and on demand by rt_garbage_collect. Either way we have to walk the > entire routing cache looking for entries to get rid of. > we dont really do the whole route cache everytime - I am sure you know that. > This is quite expensive when the routing cache is large. However, > there is a better way. > > The reason we keep a cap on the routing cache (for a given hash size) > is so that individual chains do not degenerate into long linked lists. > > In other words, we don't really care about how many entries there are > in the routing cache. But we do care about how long each hash chain > is. > > So instead of walking the entire routing cache to keep the number of > entries down, what we should do is keep each hash chain as short as > possible. > Thats certainly one solution .. reading on how you achive this .. > Assuming that the hash function is good, this should achieve the > same end result. > > Here is how it can be done: Every time a routing entry is inserted into > a hash chain, we perform GC on that chain unconditionally. > May not be a good idea to do it unconditionally - in particular on SMP where another CPU maybe spinning waiting for you to let go of bucket lock. In particular if a burst of packets accessing the same bucket show up on different processors, this would be aggravated. You may wanna kick in this algorithm only when things start going past a certain threshold. > It might seem that we're doing more work again. However, as before > because we're traversing the chain anyway, it is very cheap to perform > the GC operations which mainly involve the checks in rt_may_expire. > > OK that's enough thinking and it's time to write some code to see > whether this is all bullshit :) > I think there are some good ideas in there; the bottleneck could be perceived as one of either the locks are too expensive (clearly so in SMP as number of CPUs go up) or the compute is taking too long (clearly so in slower systems - but a general fact of life as well). For the first issue, amortizing the lock grabbing via compute as you suggest maybe of value or make per cpu caches. cheers, jamal From hadi@cyberus.ca Sat Apr 2 13:09:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:09:09 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32L93mq004713 for ; Sat, 2 Apr 2005 13:09:03 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DHprT-0005n7-Rj for netdev@oss.sgi.com; Sat, 02 Apr 2005 14:08:55 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHprX-0008HI-Mo; Sat, 02 Apr 2005 16:09:00 -0500 Subject: Re: RFC: Redirect-Device From: jamal Reply-To: hadi@cyberus.ca To: Meelis Roos Cc: netdev In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1112476135.1087.298.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 16:08:55 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Sat, 2005-04-02 at 03:41, Meelis Roos wrote: > j> I must be missing something: What is it that this device can do that the > j> mirred action cant do? > > I know what I am missing here: documentation. There is very basic > documentation about tc qdisc+class+filter level and almost nothing on the > newer features. Without good documentation only some developers > understand it. Have you tried looking at iproute2 doc/examples? Theres some new stuff in there. Over time more stuff will be added - and contributions welcome as well. cheers, jamal From hadi@cyberus.ca Sat Apr 2 13:28:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:29:01 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32LSu4O006074 for ; Sat, 2 Apr 2005 13:28:57 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DHqAo-0005rD-Nc for netdev@oss.sgi.com; Sat, 02 Apr 2005 16:28:54 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHqAm-0001r3-CC; Sat, 02 Apr 2005 16:28:52 -0500 Subject: Re: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Aidas Kasparas Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org In-Reply-To: <424E454D.4090402@gmc.lt> References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112477326.1088.321.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 16:28:46 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 02:10, Aidas Kasparas wrote: > > Re 1 try only. There is little sense to do more tries. If there is no > deamon listening to pfkey messages, then no connection will be made no > matter how many retries you'll do. If deamon/link/peer is slow and SA > was not established before timeout expired, then repeated acquire will > be simply ignored (deamon will find out that negotiation is already in > progress, there is no reason to start another negotiation and therefore > will drop that acquire request). And the only situation where repeated > acquires may help is when pfkey messages are lost. Exactly what i was trying to emulate - lost messages. I would expect it to be the rule to loose messages - but given theres no guarantee of delivery, messages could be lost. > But pfkey was not > designed to survive message loses, therefore you should not operate your > boxes in mode when lost pfkey messages are a rule, not an exception. And > on the other hand, occasional pfkey message loses can be worked around > by applications/user retry. > I think its more than just pfkey (or netlink) - rather the ipsec framework itself. One could look at the acquire as part of the "connection" setup (for lack of better description). Without the acquire succeeding, theres no connection..(assuming that to be a policy). Therefore if acquire is not supposed to be delivered with some certainty (read: retries) then theres some resiliciency issues IMO. Note: Sometimes theres no app. Example a packet coming into a gateway. > Re error code returned. Error codes returned by pfkey never were > perfect. But your experiment is not perfect too. You sent pings with no > KE deamon running. Note what my goals were. > pfkey code found that there is nothing receiving > acquire messages => there is no chance that any process will setup > required SAs and tried to inform about that (I agree, return code is not > very informative, at least until you learn about reasons why it is > such). If you would have racoon (or other pfkey based ISAKMP daemon) > running, you would get "resource temporarily unavailable" (don't know > which error code corresponds to that message), which IMHO is ok (if it > is not, please explain). > Havent tried that - the reason i said restart was the right signal was mainly that an app could translate that to mean "try again". In other words even in the case of ping -c1 the ping app could have reattempted. On Sat, 2005-04-02 at 07:25, Zilvinas Valinskas wrote: > EBUSY I think it is. > > I am not entirely sure it is ok to return such error, some applications are > not coping nicely with it. Perhaps ECONNREFUSED is more reasonable - as it > doesn't brake old apps assumption (connection cannot be established, > doesn't matter if that is due to routing or IPsec SPD or anything else). > What about ERESTART the way netlink does it right now? ECONNREFUSED is probably not a bad idea. ping was clearly dumb and didnt do anything with the info. Overall, I think the errors are unfortunately not descriptive at all. cheers, jamal From tgraf@suug.ch Sat Apr 2 13:36:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:36:35 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32LaPOw006809 for ; Sat, 2 Apr 2005 13:36:26 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 58E7BF; Sat, 2 Apr 2005 23:36:02 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 1FDD41C0EA; Sat, 2 Apr 2005 23:36:43 +0200 (CEST) Date: Sat, 2 Apr 2005 23:36:42 +0200 From: Thomas Graf To: Abhishek Gupta Cc: netdev@oss.sgi.com Subject: Re: Problem using HTB Message-ID: <20050402213642.GO3086@postel.suug.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Abhishek Gupta 2005-04-01 15:10 > tc class add dev $DEV0 parent 2: classid 2:1 htb rate 100kbit burst 100 \ > ceil 100kbit > [...] > I have configured for 100kbps, I am getting only 12kbps as the link speed. Before I look into this, are you aware of 1kbps=8kbit? From hadi@cyberus.ca Sat Apr 2 13:43:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:43:07 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32Lh2nq007527 for ; Sat, 2 Apr 2005 13:43:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DHqON-0007KX-5Z for netdev@oss.sgi.com; Sat, 02 Apr 2005 14:42:55 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DHqOM-00035F-Qn; Sat, 02 Apr 2005 16:42:55 -0500 Subject: Re: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Alexey Kuznetsov Cc: Herbert Xu , "David S. Miller" , Masahide NAKAMURA , ipsec-tools-devel@lists.sourceforge.net, netdev , kaber@trash.net, jmorris@redhat.com In-Reply-To: <20050402140019.GA13017@yakov.inr.ac.ru> References: <1112405144.1096.33.camel@jzny.localdomain> <20050402140019.GA13017@yakov.inr.ac.ru> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112478168.1088.337.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2005 16:42:48 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 09:00, Alexey Kuznetsov wrote: > Hello! > > > a) -ERESTART is the correct signal to return > > Right behaviour is to behave like ARP. A few of packets are queued, > no errors (until timeout), no blocking. Herbert also mentions something along the same lines in his email. This would make a lot of sense! Is the state machine going to look something along the same lines as ARP? i.e incomplete->reachable etc? What would be a good code to return when you queue the packet? cheers, jamal From tgraf@suug.ch Sat Apr 2 13:52:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 13:52:42 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32LqbVE008323 for ; Sat, 2 Apr 2005 13:52:38 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 93A0282; Sat, 2 Apr 2005 23:52:14 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9099E1C0EA; Sat, 2 Apr 2005 23:52:56 +0200 (CEST) Date: Sat, 2 Apr 2005 23:52:56 +0200 From: Thomas Graf To: jamal Cc: Alexey Kuznetsov , Herbert Xu , "David S. Miller" , Masahide NAKAMURA , ipsec-tools-devel@lists.sourceforge.net, netdev , kaber@trash.net, jmorris@redhat.com Subject: Re: IPSEC: on behavior of acquire Message-ID: <20050402215256.GP3086@postel.suug.ch> References: <1112405144.1096.33.camel@jzny.localdomain> <20050402140019.GA13017@yakov.inr.ac.ru> <1112478168.1088.337.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112478168.1088.337.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1112478168.1088.337.camel@jzny.localdomain> 2005-04-02 16:42 > Herbert also mentions something along the same lines in his email. > This would make a lot of sense! > Is the state machine going to look something along the same lines as > ARP? i.e incomplete->reachable etc? > > What would be a good code to return when you queue the packet? EINPROGRESS? From juhl-lkml@dif.dk Sat Apr 2 14:36:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 14:36:51 -0800 (PST) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j32MaiVo009757 for ; Sat, 2 Apr 2005 14:36:45 -0800 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 9219BFFD23 for ; Sun, 3 Apr 2005 00:46:20 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15976-02 for ; Sun, 3 Apr 2005 00:46:19 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id 445ACFFCA9 for ; Sun, 3 Apr 2005 00:46:19 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Sun, 03 Apr 2005 00:35:29 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HNMVRDHM; Sun, 3 Apr 2005 00:36:33 +0200 Date: Sun, 3 Apr 2005 00:38:54 +0200 (CEST) From: Jesper Juhl To: Maciej Soltysiak Cc: "James P. Ketrenos" , netdev@oss.sgi.com, "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: [2.6.12-rc1-mm4] swapped memset arguments In-Reply-To: <74334709.20050402233007@dns.toxicfilms.tv> Message-ID: References: <74334709.20050402233007@dns.toxicfilms.tv> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 1284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev On Sat, 2 Apr 2005, Maciej Soltysiak wrote: > Hi, > > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. > I found one: > > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * > net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); > And here's a patch : Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Signed-off-by: Jesper Juhl --- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c 2005-03-31 21:20:08.000000000 +0200 +++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c 2005-04-03 00:34:22.000000000 +0200 @@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx if (!txb) return NULL; - memset(txb, sizeof(struct ieee80211_txb), 0); + memset(txb, 0, sizeof(struct ieee80211_txb)); txb->nr_frags = nr_frags; txb->frag_size = txb_size; From jgarzik@pobox.com Sat Apr 2 17:25:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 17:25:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j331PShU018360 for ; Sat, 2 Apr 2005 17:25:28 -0800 Received: from cpe-024-025-022-197.nc.res.rr.com ([24.25.22.197] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DHtri-0006Jy-F3; Sun, 03 Apr 2005 02:25:26 +0100 Message-ID: <424F45F0.1000504@pobox.com> Date: Sat, 02 Apr 2005 20:25:04 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Liontooth CC: venza@brownhat.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ICS1883 LAN PHY not detected References: <424EF19B.7030105@cogweb.net> In-Reply-To: <424EF19B.7030105@cogweb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David Liontooth wrote: > 0000:02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon > Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) You want the sk98lin or skge drivers. Jeff From grundler@lackof.org Sat Apr 2 17:24:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 17:25:03 -0800 (PST) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j331OnPg018306 for ; Sat, 2 Apr 2005 17:24:49 -0800 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 4727429802F; Sat, 2 Apr 2005 18:26:37 -0700 (MST) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04205-03; Sat, 2 Apr 2005 18:26:35 -0700 (MST) Received: by colo.lackof.org (Postfix, from userid 27253) id C5BFF298010; Sat, 2 Apr 2005 18:26:35 -0700 (MST) Date: Sat, 2 Apr 2005 18:26:35 -0700 From: Grant Grundler To: jaganav@us.ibm.com Cc: Greg KH , Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050403012635.GA4218@colo.lackof.org> References: <1112426991.424e49ef57e2b@imap.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112426991.424e49ef57e2b@imap.linux.ibm.com> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 02:29:51AM -0500, jaganav@us.ibm.com wrote: > If this dual license is a concern to other kernel developers as well from > contributing to OpenRDMA, we would seriously consider this and discuss > with the adapter vendors. I'm not concerned with it. If *BSD can thrive with it's license, I don't see why it's a problem for linux. HP is going to pay me to work on the code regardless of the license. Projects I work on privately happen to be GPL though I'm not religous about it. If people choose NOT to volunteer time/effort on dual licensed code, I understand and respect that. There are enough worthy GPL only projects out there. I'm speaking for myself and NOT for HP. grant From liontooth@cogweb.net Sat Apr 2 21:28:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 21:28:41 -0800 (PST) Received: from weber.sscnet.ucla.edu (weber.sscnet.ucla.edu [128.97.42.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j335SZJl028429 for ; Sat, 2 Apr 2005 21:28:35 -0800 Received: from localhost (localhost [127.0.0.1]) by weber.sscnet.ucla.edu (8.13.4/8.13.4) with ESMTP id j335SZTF008913; Sat, 2 Apr 2005 21:28:35 -0800 (PST) Received: from weber.sscnet.ucla.edu ([127.0.0.1]) by localhost (weber [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08242-01; Sat, 2 Apr 2005 21:28:35 -0800 (PST) Received: from [128.97.221.35] (clitunno.sscnet.ucla.edu [128.97.221.35]) by weber.sscnet.ucla.edu (8.13.4/8.13.4) with ESMTP id j335RdWF008432; Sat, 2 Apr 2005 21:27:40 -0800 (PST) Message-ID: <424F7EC4.1000107@cogweb.net> Date: Sat, 02 Apr 2005 21:27:32 -0800 From: David Liontooth User-Agent: Debian Thunderbird 1.0 (X11/20050118) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: venza@brownhat.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: ICS1883 LAN PHY not detected References: <424EF19B.7030105@cogweb.net> <424F45F0.1000504@pobox.com> In-Reply-To: <424F45F0.1000504@pobox.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at weber.sscnet.ucla.edu X-Virus-Status: Clean X-archive-position: 1287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: liontooth@cogweb.net Precedence: bulk X-list: netdev Jeff Garzik wrote: > David Liontooth wrote: > >> 0000:02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon >> Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) > > You want the sk98lin or skge drivers. Correct -- that one worked already in Debian-Installer. What was confusing is that the Gigabyte K8NS Ultra-939 board has a second gigabyte NIC, identified in the motherboard manual as a 100/10 ICS1883 LAN PHY, that is in fact an nforce gigabyte controller, part of the nforce3 250 chipset (cf. http://cogweb.net/owens/Images/Gigabyte-K8NS-Ultra-939.jpg line 5). For some reason the PCI ID 00E6 doesn't show up in lspci, so I thought it was not detected by the kernel. However, the forcedeth driver brought it to life. Dave From herbert@gondor.apana.org.au Sat Apr 2 23:40:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 23:40:46 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j337eZm9031028 for ; Sat, 2 Apr 2005 23:40:36 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHziD-0001d3-00; Sun, 03 Apr 2005 17:40:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHzgu-00027R-00; Sun, 03 Apr 2005 17:38:40 +1000 Date: Sun, 3 Apr 2005 17:38:40 +1000 To: jamal Cc: Eric Dumazet , "David S. Miller" , netdev , Robert Olsson Subject: Re: Get rid of rt_check_expire and rt_garbage_collect Message-ID: <20050403073840.GA8105@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <20050402112304.GA11321@gondor.apana.org.au> <1112475955.1088.294.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112475955.1088.294.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 04:05:55PM -0500, jamal wrote: > > > In this state there is absolutely no need to execute the timer GC. > > Yeah, but memory is finite friend. True, if you can imagine infinite > memory we would not need gc ;-> True. However running the GC when you can't free most of the entries is a waste of time. On a busy system where the routing cache is near capacity and new entries are coming in all the time, we should arrange it so that the old entries are expired when entries are inserted. Assuming the hash function is good, then as long as there is a steady stream of entries coming in, the old entries will be expired automatically. Of course, we should not leave the systems that have experienced a burst of flows at a disadvantage. Indeed there is a rather simple way of doing GC for them without having to do work that's proportional to the number of hash chains in the routing cache. The key is that the GC is only useful when the routing cache contains enough entries that can be freed. Let's say that if we can free more than 1/3 of the entries then the GC should be run. Of course you can define this to be whatever you want. So now the problem is to quickly determine whether there are enough entries in the cache that can be freed. What we can do is take a leaf out of the politicians' book :) We take a poll on a small sample of the routing cache. That is, we run the GC on a fixed number of chains, e.g., 256 chains. After that we tally the total number of entries and the number of entries freed. Since the hash function should be spreading entries throughout the chains evenly, the ratio here can be extrapolated out to the entire cache. Therefore once the ratio exceeds the defined threshold, we perform GC over the entire cache, preferably in a kernel thread. If not then we'll simply let the GC roam along at the constant pace of 256 chains. The advantage of this is that the GC will free entries in the entire table as soon as that becomes possible without having to do work proportional to the number of chains in each GC interval. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 2 23:41:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 23:41:56 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j337foUj031138 for ; Sat, 2 Apr 2005 23:41:50 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHzjf-0001dk-00; Sun, 03 Apr 2005 17:41:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHzjZ-00027w-00; Sun, 03 Apr 2005 17:41:25 +1000 Date: Sun, 3 Apr 2005 17:41:25 +1000 To: jamal Cc: Eric Dumazet , "David S. Miller" , netdev , Robert Olsson Subject: Re: Get rid of rt_check_expire and rt_garbage_collect Message-ID: <20050403074125.GB8105@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <20050402112304.GA11321@gondor.apana.org.au> <1112475955.1088.294.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112475955.1088.294.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 04:05:55PM -0500, jamal wrote: > > > Here is how it can be done: Every time a routing entry is inserted into > > a hash chain, we perform GC on that chain unconditionally. > > May not be a good idea to do it unconditionally - in particular on SMP > where another CPU maybe spinning waiting for you to let go of bucket > lock. In particular if a burst of packets accessing the same bucket show > up on different processors, this would be aggravated. > You may wanna kick in this algorithm only when things start going past a > certain threshold. This isn't too bad because: 1. The fast path is lockless using RCU. 2. The number of locks exceeds the number of CPUs by some insane amount. 3. The cost of performing GC is really cheap, it's just a matter of calling rt_may_expire. Anyway, I agree that all of these ideas are simply fantasy until we have some code. So let me work on that and then we can let the benchmarks do the talking :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 2 23:44:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Apr 2005 23:44:09 -0800 (PST) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j337hxIh031843 for ; Sat, 2 Apr 2005 23:44:01 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DHzln-0001eh-00; Sun, 03 Apr 2005 17:43:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DHzlh-00028S-00; Sun, 03 Apr 2005 17:43:37 +1000 Date: Sun, 3 Apr 2005 17:43:37 +1000 To: "David S. Miller" Cc: Robert.Olsson@data.slu.se, dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050403074337.GA8083@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402115528.11f71a3c.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 11:55:28AM -0800, David S. Miller wrote: > > I think we should, in the short term, increase the secret interval > where it exists in the tree (netfilter conntrack is another instance > for example). We could also move rt_cache_flush into a kernel thread. When the number of chains is large this function is really expensive for a softirq handler. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From a.kasparas@gmc.lt Sun Apr 3 00:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 00:30:39 -0800 (PST) Received: from smtp02.omnitel.sun (smtp02-neptunas.omnitel.net [194.176.45.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j338UVJn004479 for ; Sun, 3 Apr 2005 00:30:32 -0800 Received: from smtp04-neptunas.omnitel.net ([194.176.45.42]) by smtp02.omnitel.sun (Sun Java System Messaging Server 6.1 HotFix 0.01 (built Jun 24 2004)) with ESMTP id <0IED004S43K8BK40@smtp02.omnitel.sun> for netdev@oss.sgi.com; Sun, 03 Apr 2005 11:28:57 +0300 (EEST) Received: from smtp04-neptunas.omnitel.net (localhost [127.0.0.1]) by smtp04-neptunas.omnitel.net (Postfix) with SMTP id 6928139804F; Sun, 03 Apr 2005 11:28:54 +0300 (EEST) Received: from [192.168.0.128] (unknown [62.212.195.62]) by smtp04-neptunas.omnitel.net (Postfix) with ESMTP id D1DD939804A; Sun, 03 Apr 2005 11:28:53 +0300 (EEST) Date: Sun, 03 Apr 2005 11:28:54 +0300 From: Aidas Kasparas Subject: Re: IPSEC: on behavior of acquire In-reply-to: <1112477326.1088.321.camel@jzny.localdomain> To: hadi@cyberus.ca Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org Message-id: <424FA946.70809@gmc.lt> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: lt, en, ru, fr X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev jamal wrote: > On Sat, 2005-04-02 at 02:10, Aidas Kasparas wrote: > > >>Re 1 try only. There is little sense to do more tries. If there is no >>deamon listening to pfkey messages, then no connection will be made no >>matter how many retries you'll do. If deamon/link/peer is slow and SA >>was not established before timeout expired, then repeated acquire will >>be simply ignored (deamon will find out that negotiation is already in >>progress, there is no reason to start another negotiation and therefore >>will drop that acquire request). And the only situation where repeated >>acquires may help is when pfkey messages are lost. > > > Exactly what i was trying to emulate - lost messages. Your emulation was not correct. More correct would have been to start KE daemon, let it fully initialize (open pfkey socket, inform kernel that it is interested in acquire messages), then stop it (via debugger or kill -STOP) and only then send pings or other traffic and see what will happen. This is because there are different paths in xfrm+pfkey for cases 1) when there is no KE daemon and 2) when daemon is, but for some reason it does not establish a SA and therefore reaction to traffic is different. In the first case it's xfrm_lookup() ->xfrm_tmpl_resolve() ->xfrm_state_find() ->xfrm_state.c:km_query() ->pfkey_send_acquire() ->pfkey_broadcast() ->return -ESRCH. This error code goes unchanged back to xfrm_state_find, where it is remaped into itself (other possible values are -EAGAIN and -ENOMEM). And then this error code goes back to application. In the second case it's xfrm_lookup() ->xfrm_tmpl_resolve() ->xfrm_state_find() ->xfrm_state.c:km_query() ->pfkey_send_acquire() ->pfkey_broadcast() ->pfkey_broadcast_one() -> return 0 also sent unchanged back to function xfrm_state_find, where SA is put into state XFRM_STATE_ACQ. xfrm_tmpl_resolve() returns -EAGAIN. xfrm_lookup then organizes timeout, and if the state was not changed after that timeout, returns -EAGAIN to the application. On the other hand, analysis above shows that return code is choosen by xfrm framework, therefore if error code has to be changed, it should be changed in xfrm, not in pfkey or netlink code. > I would expect it > to be the rule to loose messages - but given theres no guarantee of > delivery, messages could be lost. > > >>But pfkey was not >>designed to survive message loses, therefore you should not operate your >>boxes in mode when lost pfkey messages are a rule, not an exception. And >>on the other hand, occasional pfkey message loses can be worked around >>by applications/user retry. >> > > > I think its more than just pfkey (or netlink) - rather the ipsec > framework itself. > > One could look at the acquire as part of the "connection" setup > (for lack of better description). Without the acquire succeeding, theres > no connection..(assuming that to be a policy). > Therefore if acquire is not supposed to be delivered with some certainty > (read: retries) then theres some resiliciency issues IMO. OK, To avoid speaking about apples and oranges let's first find out where you see the problem. In the ipsec framework there are the following players (I'm speaking about pfkey case; netlink may be little different): xfrm <-> pfkey <-> KE daemon <-> remote peer xfrm-pfkey communication is based on function calls. For them to fail something really weird has to happen with your kernel. KE deamon - remote peer communications are done on UDP/500, UDP/4500 according to internet standards. Packet retransmissions are implemented the way standards require, therefore it is not a fatal condition if some packet will be lost on the way. And there is no 1:1 correspondence between packets sent over internet and those sent over pfkey socket. These communications are performed relatively independent. There is no need to receive extra acquire pfkey message to retransmit packet which initiates SA setup with remote peer. pfkey - KE daemon communication is performed over message socket. All the communication is performed within single box. More, only the kernel and userspace process are involved. Therefore I see only the following cases when message can be not delivered: 1) message is too big to fit into socket's buffer; 2) kernel decides to drop that socket buffer and reuse memory for something else; 3) KE daemon do not get [enough] CPU time to handle messages; 4) bug in KE daemon prevents it from reading messages. if you know other case, please, let me know. (1) do happens when there is big SPD/SAD and setkey/racoon request to dump it all. It is known pfkey architectural limitation. Acquire messages are small, therefore this can happen only when such call is made right after responce to big DUMP was generated. In racoon case SPD dump is performed only on daemon startup (and even then it is possible that it is not strictly necessary). Extra acquire message may make sense only if it is sent after some timeout. But again, KE daemon start is more exception than rule and applications can be started only after some delay after KE daemon has started. I'm not sure how realistic is (2). But it and (3) are clear resource shortage cases. Under no circumstances they should be allowed. And in (3) case extra acquire message definitely won't help situation. Inn (4) case it is KE daemon who is guilty, not pfkey. Extra message will not cure this case too. > > Note: Sometimes theres no app. Example a packet coming into a gateway. > What do you have in mind? If it is ISAKMP negotiation from remote peer, then it comes over UDP/500 or UDP/4500 over IP socket and not via acquire message via pfkey socket. If it is ESP/AH packet with unknown SPI, then kernel simply drops it and do not send any acquire messages. If it is something else, please explain. >> pfkey code found that there is nothing receiving >>acquire messages => there is no chance that any process will setup >>required SAs and tried to inform about that (I agree, return code is not >>very informative, at least until you learn about reasons why it is >>such). If you would have racoon (or other pfkey based ISAKMP daemon) >>running, you would get "resource temporarily unavailable" (don't know >>which error code corresponds to that message), which IMHO is ok (if it >>is not, please explain). >> > > > Havent tried that - the reason i said restart was the right signal was > mainly that an app could translate that to mean "try again". > In other words even in the case of ping -c1 the ping app could have > reattempted. If there is security policy which is not satisfied and there is nobody which could make it satisfied, then why should we give application false hope that on retry things will change? > > On Sat, 2005-04-02 at 07:25, Zilvinas Valinskas wrote: > >>EBUSY I think it is. >> >>I am not entirely sure it is ok to return such error, some applications are >>not coping nicely with it. Perhaps ECONNREFUSED is more reasonable - as it >>doesn't brake old apps assumption (connection cannot be established, >>doesn't matter if that is due to routing or IPsec SPD or anything else). >> > > > What about ERESTART the way netlink does it right now? I suspect that ERESTART is generated not by netlink, but by xfrm_lookup() function when signal_pending(current) is true. Why that function returns true in netlink case but not in pfkey case I don't know. IMHO, xfrm_lookup() returns correct error codes in that case. > ECONNREFUSED is probably not a bad idea. > ping was clearly dumb and didnt do anything with the info. > Overall, I think the errors are unfortunately not descriptive at all. I don't like ECONNREFUSED in this place. As a user if I would receive ECONNREFUSED message then I would address application server admin or remote host admin to resolve the problem. But the problem is in network setup and therefore person responsible for networks should be contacted. Therefore, I would like more ENETUNREACH or EHOSTUNREACH. P.S. for analysis kernel source from debian distribution was used (v.2.6.9) -- Aidas Kasparas IT administrator GM Consult Group, UAB From hadi@cyberus.ca Sun Apr 3 07:29:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 07:29:43 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33ETawn023082 for ; Sun, 3 Apr 2005 07:29:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DI66Y-00019y-FV for netdev@oss.sgi.com; Sun, 03 Apr 2005 10:29:34 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DI66U-00068f-JN; Sun, 03 Apr 2005 10:29:30 -0400 Subject: Re: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Aidas Kasparas Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org In-Reply-To: <424FA946.70809@gmc.lt> References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112538566.1096.391.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 10:29:27 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2005-04-03 at 04:28, Aidas Kasparas wrote: > jamal wrote: > > Exactly what i was trying to emulate - lost messages. > > Your emulation was not correct. More correct would have been to start KE > daemon, let it fully initialize (open pfkey socket, inform kernel that > it is interested in acquire messages), then stop it (via debugger or > kill -STOP) and only then send pings or other traffic and see what will > happen. This is because there are different paths in xfrm+pfkey for > cases 1) when there is no KE daemon and 2) when daemon is, but for some > reason it does not establish a SA and therefore reaction to traffic is > different. > I dont think that would work. To summarize what happens in the kernel: everything leads to km_query() as you have indicated in your text. If the kernel finds someone/thing has either a pfkey or netlink socket open it sends a acquire to them. In the code you are probably looking at (before i created the patch) - the first user/daemon the kernel sees (either pfkey or netlink based) that has a socket open will receive an acquire and the kernel will give up after that. As an example, if the first pfkey user was just doing "setkey -x" and the second was infact pluto, then pluto will never see the acquire. This is what got me looking at it to begin with. Look at the earlier postings on the subject. So in other words, just killing the ike server as you propose would mean the kernel has no open sockets and will therefore never bother to send an acquire. Still all this is moot and is distracting us from the main discussion. Lets define "lost" simply as the case where an acquire never got to the server (which may be sitting elsewhere on the network). In that case what i did is sufficient. i.e. The methods to create this are not the issue. The issue at stake is the behavior of the kernel in generating the acquires. [..] > On the other hand, analysis above shows that return code is choosen by > xfrm framework, therefore if error code has to be changed, it should be > changed in xfrm, not in pfkey or netlink code. The control for both is under generic code. The end return code - you are right, thats user behavior and should match. > > One could look at the acquire as part of the "connection" setup > > (for lack of better description). Without the acquire succeeding, theres > > no connection..(assuming that to be a policy). > > Therefore if acquire is not supposed to be delivered with some certainty > > (read: retries) then theres some resiliciency issues IMO. > > OK, To avoid speaking about apples and oranges let's first find out > where you see the problem. In the ipsec framework there are the > following players (I'm speaking about pfkey case; netlink may be little > different): > > xfrm <-> pfkey <-> KE daemon <-> remote peer > > xfrm-pfkey communication is based on function calls. For them to fail > something really weird has to happen with your kernel. > > KE deamon - remote peer communications are done on UDP/500, UDP/4500 > according to internet standards. Packet retransmissions are implemented > the way standards require, therefore it is not a fatal condition if some > packet will be lost on the way. Please refer to my earlier definition of what "lost" means. It doesnt matter where the breakage happens really. Think of everything to the right of "xfrm" in your diagram as a black box (i.e that second thing could be pfkey or netlink - thats not the issue). Think of some message that is supposed to reach the KE daemon (make it interesting and say it is remote KE) then think of that message never making it because something in the blackbox swallowed it. If that packet is the first one and it needs to do so for the sake of setup for subsequent packets - then the desire to have it reach its destination is very imprtant. There is no progress for it or subsequent packets if it doesnt make it. The solution being proposed for Linux to treat that xfrm piece in the same fashion as ARP is correct. Read the email from Alexey. Imagine if ARP was only issued once(as does pfkey) or forever(as does netlink). I believe this is an issue with ipsec architecture itself - someone needs to write an IETF draft on it. > > > > > Note: Sometimes theres no app. Example a packet coming into a gateway. > > > > What do you have in mind? > > If it is ISAKMP negotiation from remote peer, then it comes over UDP/500 > or UDP/4500 over IP socket and not via acquire message via pfkey socket. > > If it is ESP/AH packet with unknown SPI, then kernel simply drops it and > do not send any acquire messages. > I was thinking more of this second scenario with incoming from clear text domain and gateway encrypting assuming proper policy setup. I would have to go and reread the "opportunistic" encryption draft closely to make sense. > > Havent tried that - the reason i said restart was the right signal was > > mainly that an app could translate that to mean "try again". > > In other words even in the case of ping -c1 the ping app could have > > reattempted. > > If there is security policy which is not satisfied and there is nobody > which could make it satisfied, then why should we give application false > hope that on retry things will change? > In the case of knowing it is the policy that is not satisfied i think it would make sense to not to tell the app to retry. > > > > What about ERESTART the way netlink does it right now? > > I suspect that ERESTART is generated not by netlink, but by > xfrm_lookup() function when signal_pending(current) is true. Why that > function returns true in netlink case but not in pfkey case I don't > know. IMHO, xfrm_lookup() returns correct error codes in that case. > yes, you are correct. > > ECONNREFUSED is probably not a bad idea. > > ping was clearly dumb and didnt do anything with the info. > > Overall, I think the errors are unfortunately not descriptive at all. > > I don't like ECONNREFUSED in this place. As a user if I would receive > ECONNREFUSED message then I would address application server admin or > remote host admin to resolve the problem. But the problem is in network > setup and therefore person responsible for networks should be contacted. > Therefore, I would like more ENETUNREACH or EHOSTUNREACH. > Agreed to this as well. I think this is what would happen in the case of ARP failure as well. ECONNREFUSED would make sense in the case where the policy rejected progress. cheers, jamal From hadi@cyberus.ca Sun Apr 3 07:32:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 07:32:18 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33EW93e023317 for ; Sun, 3 Apr 2005 07:32:10 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DI68x-0001Jp-W1 for netdev@oss.sgi.com; Sun, 03 Apr 2005 08:32:03 -0600 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DI68v-0006MV-VK; Sun, 03 Apr 2005 10:32:02 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <1112469601.1088.173.camel@jzny.localdomain> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-CbZvGNdJ/zGTATpkMExl" Organization: jamalopolous Message-Id: <1112538718.1096.394.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 10:31:58 -0400 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-CbZvGNdJ/zGTATpkMExl Content-Type: text/plain Content-Transfer-Encoding: 7bit Small change after some testing. Herbert havent heard back from you - this looks very palatable in my opinion with comments below still in effect. cheers, jamal On Sat, 2005-04-02 at 14:20, jamal wrote: > Ok, heres a general patch first cut i think i got all that was discussed > in there. ive done some basic 5 minutes tests on. > Once we have agreement i will pass it on to Masahide-san to do more > thorough testing. > Look at the XXX comments in the patch. > > A couple of interesting things: > > 1) Weve discussed this before Herbert and i think you misspoke that > pfkey delivers to all listerners. > > pfkey Add/del/upd now really do tell all processes about what happened. > Before pfkey would skip the originating process. So far this doesnt seem > to be an issue in the basic testing. > > 2) I ended adding a policy_notify to the pfkey manager to make the code > generic. Interesting thing is i dont think pfkey knows what to do with > policy expiration or i am misreading the code. > I dont see any message type for policy expiration as i do for sa > expiration. Ive put some hooks and a little noise. I could remove the > printks - for now they are just place holders. > > cheers, > jamal --=-CbZvGNdJ/zGTATpkMExl Content-Disposition: attachment; filename=ipsec-event-take2-1 Content-Type: text/plain; name=ipsec-event-take2-1; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 +++ b/include/net/xfrm.h 2005-04-02 11:59:17.000000000 -0500 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -802,7 +827,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-25 22:28:39.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-02 09:53:03.000000000 -0500 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-03-25 22:28:25.000000000 -0500 +++ b/net/xfrm/xfrm_state.c 2005-04-02 12:15:37.000000000 -0500 @@ -48,7 +48,7 @@ static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); static DEFINE_SPINLOCK(xfrm_state_gc_lock); -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); @@ -208,8 +208,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -236,14 +238,47 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +static DEFINE_RWLOCK(xfrm_km_lock); +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); + +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { + struct xfrm_mgr *km; + + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock(&xfrm_km_lock); +} + +void km_state_notify(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_mgr *km; + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + km->notify(x, c); + read_unlock(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +int xfrm_state_delete(struct xfrm_state *x) +{ + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -402,6 +437,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -764,37 +800,45 @@ } EXPORT_SYMBOL(xfrm_replay_advance); -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); -static DEFINE_RWLOCK(xfrm_km_lock); static void km_state_expired(struct xfrm_state *x, int hard) { - struct xfrm_mgr *km; + struct km_event c; if (hard) x->km.state = XFRM_STATE_EXPIRED; else x->km.dying = 1; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); - read_unlock(&xfrm_km_lock); + /* XXX: Do we wanna do this right at the top?? + * if the state is dead we dont want to announce + * the expire - a delete may already have announced + * it + */ + if (x->km.state == XFRM_STATE_DEAD) + return; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -819,13 +863,20 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + /* XXX: Do we still wanna wakeup km_waitq? + * if the policy is dead we dont want to announce + * the expire - a delete may already have announced + * it + */ + if (pol->dead) + return; + + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_policy.c 2005-03-25 22:28:21.000000000 -0500 +++ b/net/xfrm/xfrm_policy.c 2005-04-02 12:16:30.000000000 -0500 @@ -298,7 +298,7 @@ * entry dead. The rule must be unlinked from lists to the moment. */ -static void xfrm_policy_kill(struct xfrm_policy *policy) +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir) { write_lock_bh(&policy->lock); if (policy->dead) @@ -378,7 +378,7 @@ write_unlock_bh(&xfrm_policy_lock); if (delpol) { - xfrm_policy_kill(delpol); + xfrm_policy_kill(delpol, dir); } return 0; } @@ -402,7 +402,7 @@ if (pol && delete) { atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } return pol; } @@ -425,7 +425,7 @@ if (pol && delete) { atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } return pol; } @@ -442,7 +442,7 @@ xfrm_policy_list[dir] = xp->next; write_unlock_bh(&xfrm_policy_lock); - xfrm_policy_kill(xp); + xfrm_policy_kill(xp, dir); write_lock_bh(&xfrm_policy_lock); } @@ -558,7 +558,7 @@ if (pol) { if (dir < XFRM_POLICY_MAX) atomic_inc(&flow_cache_genid); - xfrm_policy_kill(pol); + xfrm_policy_kill(pol, dir); } } @@ -579,7 +579,7 @@ write_unlock_bh(&xfrm_policy_lock); if (old_pol) { - xfrm_policy_kill(old_pol); + xfrm_policy_kill(old_pol, dir); } return 0; } --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-02 12:21:32.000000000 -0500 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -285,14 +286,26 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +317,20 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -672,6 +695,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +707,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +718,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +845,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +874,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +888,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1111,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1128,94 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1349,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1361,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1369,90 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("Netlink Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-03-25 22:28:39.000000000 -0500 +++ b/net/key/af_key.c 2005-04-02 18:05:24.000000000 -0500 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1256,7 +1328,7 @@ if (hdr->sadb_msg_type == SADB_ADD) err = xfrm_state_add(x); - else + else err = xfrm_state_update(x); if (err < 0) { @@ -1265,27 +1337,22 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1368,20 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + x->km.state = XFRM_STATE_DEAD; + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1519,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + // XXX:do we have to pass proto as well? + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1947,31 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1979,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2047,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2079,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,24 +2115,11 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); -out: xfrm_pol_put(xp); return err; } @@ -2037,8 +2129,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2141,19 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + /* + * XXX: previous get was doing a broadcast-all _always_ + * which didnt seem right for non-deletion case - JHS + * This is like the way netlink behaves .. + * Shall i restore original behavior? + */ + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2188,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2414,25 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + printk("pfkey doesnt deal with expired policies ..\n"); + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2451,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3004,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-CbZvGNdJ/zGTATpkMExl-- From abhishek@pal.ece.iisc.ernet.in Sun Apr 3 08:00:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 08:01:00 -0700 (PDT) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33F0o2B024756 for ; Sun, 3 Apr 2005 08:00:52 -0700 Received: from pal.ece.iisc.ernet.in (pal.ece.iisc.ernet.in [144.16.64.149]) by ece.iisc.ernet.in (8.12.6/8.12.6) with ESMTP id j33Ew58V086581; Sun, 3 Apr 2005 20:28:10 +0530 (IST) (envelope-from abhishek@pal.ece.iisc.ernet.in) Received: by pal.ece.iisc.ernet.in (Postfix, from userid 1047) id CB30F31E59; Sun, 3 Apr 2005 20:30:19 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by pal.ece.iisc.ernet.in (Postfix) with ESMTP id C73C631E57; Sun, 3 Apr 2005 20:30:19 +0530 (IST) Date: Sun, 3 Apr 2005 20:30:19 +0530 (IST) From: Abhishek Gupta To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: Problem using HTB In-Reply-To: <20050402213642.GO3086@postel.suug.ch> Message-ID: References: <20050402213642.GO3086@postel.suug.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abhishek@pal.ece.iisc.ernet.in Precedence: bulk X-list: netdev hello Thanks Mr. Graf for replying. Ya, I do was making mistake by assuming KBps as Kbit per second. Actually, I got confused with notations used in the Linux's RH monitor which I used for the speed measurements. But the problem is still not yet solved as I tried with 1Mbit speed as the setting for link speed in the htb configuration and got about 30KBps which amounts to about 240Kbitps even though my UDP source is sending at speed of about 1MBps(8Mbps), according to RH monitor readings. Is it possible that the problem is due to the source that I am using for UDP packets? abhishek ========================================================================= ABHISHEK GUPTA E-mail:abhishek_it_bhu@yahoo.co.in ========================================================================= On Sat, 2 Apr 2005, Thomas Graf wrote: > * Abhishek Gupta 2005-04-01 15:10 > > tc class add dev $DEV0 parent 2: classid 2:1 htb rate 100kbit burst 100 \ > > ceil 100kbit > > [...] > > I have configured for 100kbps, I am getting only 12kbps as the link speed. > > Before I look into this, are you aware of 1kbps=8kbit? > From kaber@trash.net Sun Apr 3 08:49:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 08:49:16 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33FnBfm030687 for ; Sun, 3 Apr 2005 08:49:12 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DI7KJ-0008Pn-Od; Sun, 03 Apr 2005 17:47:51 +0200 Message-ID: <42501027.6010609@trash.net> Date: Sun, 03 Apr 2005 17:47:51 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> In-Reply-To: <1112538718.1096.394.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: >>+void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) >> { >>+ struct xfrm_mgr *km; >>+ >>+ read_lock(&xfrm_km_lock); >>+ list_for_each_entry(km, &xfrm_km_list, list) >>+ if (km->notify_policy) >>+ km->notify_policy(xp, dir, c); >>+ read_unlock(&xfrm_km_lock); >>+} >>+ >>+void km_state_notify(struct xfrm_state *x, struct km_event *c) >>+{ >>+ struct xfrm_mgr *km; >>+ read_lock(&xfrm_km_lock); >>+ list_for_each_entry(km, &xfrm_km_list, list) >>+ km->notify(x, c); >>+ read_unlock(&xfrm_km_lock); >>+} You call these functions from both softirq- and user-context, so you need to protect against BHs. Regards Patrick From kaber@trash.net Sun Apr 3 08:53:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 08:53:38 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33FrXtl031326 for ; Sun, 3 Apr 2005 08:53:34 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DI7Ok-0008QN-9f; Sun, 03 Apr 2005 17:52:26 +0200 Message-ID: <4250113A.4080202@trash.net> Date: Sun, 03 Apr 2005 17:52:26 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Alexey Kuznetsov , Herbert Xu , "David S. Miller" , Masahide NAKAMURA , ipsec-tools-devel@lists.sourceforge.net, netdev , jmorris@redhat.com Subject: Re: IPSEC: on behavior of acquire References: <1112405144.1096.33.camel@jzny.localdomain> <20050402140019.GA13017@yakov.inr.ac.ru> <1112478168.1088.337.camel@jzny.localdomain> In-Reply-To: <1112478168.1088.337.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: > Herbert also mentions something along the same lines in his email. > This would make a lot of sense! > Is the state machine going to look something along the same lines as > ARP? i.e incomplete->reachable etc? Yes, from a bundle POV. In my current approach a single state is resolved at a time and resolution is driven by XFRM_STATE_ACQ->* state transitions. > What would be a good code to return when you queue the packet? It should be transparent, so 0. Regards Patrick From kaber@trash.net Sun Apr 3 09:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 09:13:44 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33GDbAA032335 for ; Sun, 3 Apr 2005 09:13:38 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DI7if-0008Tj-3S; Sun, 03 Apr 2005 18:13:01 +0200 Message-ID: <4250160D.2040405@trash.net> Date: Sun, 03 Apr 2005 18:13:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , netdev Subject: [IPSEC]: Protect against BHs in xfrm_user_policy() Content-Type: multipart/mixed; boundary="------------040106090202000803080206" X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040106090202000803080206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit xfrm_user_policy() is called from ip_setsockopt with enabled BHs, so it needs to protect against them when grabbing xfrm_km_lock. --------------040106090202000803080206 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/03 17:36:10+02:00 kaber@coreworks.de # [IPSEC]: Protect against BHs in xfrm_user_policy() # # Signed-off-by: Patrick McHardy # # net/xfrm/xfrm_state.c # 2005/04/03 17:36:00+02:00 kaber@coreworks.de +2 -2 # [IPSEC]: Protect against BHs in xfrm_user_policy() # # Signed-off-by: Patrick McHardy # diff -Nru a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c --- a/net/xfrm/xfrm_state.c 2005-04-03 18:04:38 +02:00 +++ b/net/xfrm/xfrm_state.c 2005-04-03 18:04:38 +02:00 @@ -878,14 +878,14 @@ goto out; err = -EINVAL; - read_lock(&xfrm_km_lock); + read_lock_bh(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { pol = km->compile_policy(sk->sk_family, optname, data, optlen, &err); if (err >= 0) break; } - read_unlock(&xfrm_km_lock); + read_unlock_bh(&xfrm_km_lock); if (err >= 0) { xfrm_sk_policy_insert(sk, err, pol); --------------040106090202000803080206-- From hadi@cyberus.ca Sun Apr 3 09:29:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 09:29:19 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33GTFs6000902 for ; Sun, 3 Apr 2005 09:29:15 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DI7yM-0005vy-Au for netdev@oss.sgi.com; Sun, 03 Apr 2005 12:29:14 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DI7yI-00089r-7W; Sun, 03 Apr 2005 12:29:10 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Herbert Xu , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <42501027.6010609@trash.net> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <42501027.6010609@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112545744.1087.397.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 12:29:05 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2005-04-03 at 11:47, Patrick McHardy wrote: > >>+void km_state_notify(struct xfrm_state *x, struct km_event *c) > >>+{ > >>+ struct xfrm_mgr *km; > >>+ read_lock(&xfrm_km_lock); > >>+ list_for_each_entry(km, &xfrm_km_list, list) > >>+ km->notify(x, c); > >>+ read_unlock(&xfrm_km_lock); > >>+} > > You call these functions from both softirq- and user-context, so you > need to protect against BHs. > You are absolutely correct. Thanks for catching this. cheers, jamal From hadi@cyberus.ca Sun Apr 3 09:36:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 09:36:48 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Gaiv4001707 for ; Sun, 3 Apr 2005 09:36:44 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DI85b-00083D-L5 for netdev@oss.sgi.com; Sun, 03 Apr 2005 12:36:43 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DI85Y-0000LD-Dg; Sun, 03 Apr 2005 12:36:40 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Herbert Xu , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <42501027.6010609@trash.net> References: <1112319441.1089.83.camel@jzny.localdomain> <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <42501027.6010609@trash.net> Content-Type: multipart/mixed; boundary="=-HzY6ovv3o1agHd1AZ7ya" Organization: jamalopolous Message-Id: <1112546194.1096.401.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 12:36:35 -0400 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-HzY6ovv3o1agHd1AZ7ya Content-Type: text/plain Content-Transfer-Encoding: 7bit Masahide, Attached is incremental patch on top of the one posted earlier. Looks ok from my basic testing. Please run it against your tests and see if it stands. cheers, jamal On Sun, 2005-04-03 at 11:47, Patrick McHardy wrote: > You call these functions from both softirq- and user-context, so you > need to protect against BHs. > > Regards > Patrick > --=-HzY6ovv3o1agHd1AZ7ya Content-Disposition: attachment; filename=ipsec-event-take2-1-1 Content-Type: text/plain; name=ipsec-event-take2-1-1; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/net/xfrm/xfrm_state.c 2005/04/03 16:30:31 1.2 +++ b/net/xfrm/xfrm_state.c 2005/04/03 16:31:27 @@ -251,20 +251,20 @@ { struct xfrm_mgr *km; - read_lock(&xfrm_km_lock); + read_lock_bh(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) if (km->notify_policy) km->notify_policy(xp, dir, c); - read_unlock(&xfrm_km_lock); + read_unlock_bh(&xfrm_km_lock); } void km_state_notify(struct xfrm_state *x, struct km_event *c) { struct xfrm_mgr *km; - read_lock(&xfrm_km_lock); + read_lock_bh(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) km->notify(x, c); - read_unlock(&xfrm_km_lock); + read_unlock_bh(&xfrm_km_lock); } EXPORT_SYMBOL(km_policy_notify); --=-HzY6ovv3o1agHd1AZ7ya-- From kaber@trash.net Sun Apr 3 09:49:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 09:49:15 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Gn9Fr002547 for ; Sun, 3 Apr 2005 09:49:10 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DI8Go-0003lv-39; Sun, 03 Apr 2005 18:48:18 +0200 Message-ID: <42501E51.3000401@trash.net> Date: Sun, 03 Apr 2005 18:48:17 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> In-Reply-To: <20050402020947.GA24998@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070809070105060803010504" X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------070809070105060803010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > It's still a valid clean-up patch though. Agreed. There is also a bug in my patch, tmpl->daddr can be 0 in which case the daddr passed as an argument to xfrm_state_find() will be used. My patch only checked tmpl->daddr, this patch fixes it. It also uses afinfo->init_tempsel directly, but I didn't kill xfrm_init_tempsel() yet because I need it for xfrm resolution. > There is another reason why it won't dead lock. We don't actually > ever hold the write lock on afinfo :) Is there any reason why we > dont't just use xfrm_state_afinfo_lock instead of afinfo->lock? I don't think so. I also don't see a reason why the lock needs to be held between xfrm_state_get_afinfo() and xfrm_state_put_afinfo(), a reference count should be enough. Regards Patrick --------------070809070105060803010504 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/03 18:41:22+02:00 kaber@coreworks.de # [IPSEC]: Use correct daddr for duplicate state check # # Signed-off-by: Patrick McHardy # # net/xfrm/xfrm_state.c # 2005/04/03 18:41:14+02:00 kaber@coreworks.de +9 -9 # [IPSEC]: Use correct daddr for duplicate state check # # Signed-off-by: Patrick McHardy # diff -Nru a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c --- a/net/xfrm/xfrm_state.c 2005-04-03 18:41:41 +02:00 +++ b/net/xfrm/xfrm_state.c 2005-04-03 18:41:41 +02:00 @@ -357,12 +357,6 @@ x = best; if (!x && !error && !acquire_in_progress) { - x0 = afinfo->state_lookup(&tmpl->id.daddr, tmpl->id.spi, tmpl->id.proto); - if (x0 != NULL) { - xfrm_state_put(x0); - error = -EEXIST; - goto out; - } x = xfrm_state_alloc(); if (x == NULL) { error = -ENOMEM; @@ -370,9 +364,11 @@ } /* Initialize temporary selector matching only * to current session. */ - xfrm_init_tempsel(x, fl, tmpl, daddr, saddr, family); + afinfo->init_tempsel(x, fl, tmpl, daddr, saddr); + + x0 = afinfo->state_lookup(&x->id.daddr, x->id.spi, x->id.proto); - if (km_query(x, tmpl, pol) == 0) { + if (!x0 && km_query(x, tmpl, pol) == 0) { x->km.state = XFRM_STATE_ACQ; list_add_tail(&x->bydst, xfrm_state_bydst+h); xfrm_state_hold(x); @@ -386,10 +382,14 @@ x->timer.expires = jiffies + XFRM_ACQ_EXPIRES*HZ; add_timer(&x->timer); } else { + error = -ESRCH; + if (x0) { + xfrm_state_put(x0); + error = -EEXIST; + } x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); x = NULL; - error = -ESRCH; } } out: --------------070809070105060803010504-- From kaber@trash.net Sun Apr 3 10:01:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 10:01:31 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33H1QKT003360 for ; Sun, 3 Apr 2005 10:01:27 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DI8Si-0003mQ-Hy; Sun, 03 Apr 2005 19:00:36 +0200 Message-ID: <42502134.8030003@trash.net> Date: Sun, 03 Apr 2005 19:00:36 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: Checking SPI in xfrm_state_find References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> In-Reply-To: <20050331004658.GA26395@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Herbert Xu wrote: > It just occured to me that it would be much simpler if you did the > existence check in the first loop. > > So something like > > if (x->props.family != family || > !xfrm_state_addr_check(x, daddr, saddr, family) || > tmpl->id.proto == x->id.proto) > continue; > if (tmpl->id.spi) { > if (tmpl->id.spi != x->id.spi) > continue; > error = -EEXIST; > } > if (x->props.reqid == tmpl->reqid && > tmpl->mode == x->props.mode) { > } You're right, sorry for getting back to you so late. But since its already in now and not very important, I'm going to leave it until I have a better reason to touch that code, if you're ok with that. Regards Patrick From Robert.Olsson@data.slu.se Sun Apr 3 12:18:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 12:18:39 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33JIXn4008610 for ; Sun, 3 Apr 2005 12:18:34 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j33JIUWk016276 for ; Sun, 3 Apr 2005 21:18:31 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id C5C56EE2B1; Sun, 3 Apr 2005 21:18:30 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16976.16774.728707.368646@robur.slu.se> Date: Sun, 3 Apr 2005 21:18:30 +0200 To: Harald Welte Cc: netdev@oss.sgi.com Subject: pktgen problem (skb refcount) in 2.6.12-rc1 In-Reply-To: <20050402191132.GF1890@sunbeam.de.gnumonks.org> References: <20050402191132.GF1890@sunbeam.de.gnumonks.org> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Harald Welte writes: > I've tried to get pktgen running on 2.6.12-rc1 (dual-opteron system, two > dual e1000 boards). > I've tried to track the problem down, and I've confirmed that skb->users > never goes down to 1 but instead stays at '2'. > The same system with the same pktgen script works fine with 2.6.11.6. > > I'm reporting this since it seems like it sounds like we have a skb > usage count leak somewhere :( Hello! Sounds like a diff could give some clues. pktgen, e1000 and TX-path should be interesting as ev. changes in kernel config. --ro From Robert.Olsson@data.slu.se Sun Apr 3 12:37:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 12:37:45 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33JbdJf013946 for ; Sun, 3 Apr 2005 12:37:39 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j33JaqWB018224; Sun, 3 Apr 2005 21:36:53 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id D38DEEE2B2; Sun, 3 Apr 2005 21:36:52 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16976.17876.832677.945878@robur.slu.se> Date: Sun, 3 Apr 2005 21:36:52 +0200 To: Herbert Xu Cc: Robert Olsson , Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050402193224.GA25157@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Herbert Xu writes: > Incidentally we should change the way the rehashing is triggered. > Instead of doing it regularly, we can do it when we notice that a > specific hash chain grows beyond a certain size. > The idea is that if someone is attacking our hash then they can > only do so by lengthening the chains. If they're not doing that > then even if they knew how to attack us we don't really care. Well I don't see how we detect the need for rehash just be looking at the hash chains. How does the the "lengthening" look like that are allowed to trigger a rehash? Agree with Dave that we can increase the interval to start with. --ro From tgraf@suug.ch Sun Apr 3 12:47:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 12:47:34 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33JlM94014678 for ; Sun, 3 Apr 2005 12:47:22 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 55CD682; Sun, 3 Apr 2005 21:46:57 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 781091C0EA; Sun, 3 Apr 2005 21:47:39 +0200 (CEST) Date: Sun, 3 Apr 2005 21:47:39 +0200 From: Thomas Graf To: Abhishek Gupta Cc: netdev@oss.sgi.com Subject: Re: Problem using HTB Message-ID: <20050403194739.GR3086@postel.suug.ch> References: <20050402213642.GO3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Abhishek Gupta 2005-04-03 20:30 > But the problem is still > not yet solved as I tried with 1Mbit speed as the setting for link speed > in the htb configuration and got about 30KBps which amounts to about > 240Kbitps even though my UDP source is sending at speed of about > 1MBps(8Mbps), according to RH monitor readings. I do not know about that "RH monitor" you are referring to, maybe it does not display rates correctly. (I found 3 out of 5 rate estimators outputing with a variance of over 10%) I can recommend you bmon [0] which states the variance and can be used to a resolution up to 1/100s given the input source provides an equal or better resolution. > Is it possible that the problem is due to the source that I am using for > UDP packets? Very likely, especially due to the huge difference in requested and achieved rate you have mentioned above. I hardly think this is a problem related to HTB but rather some misconfiguration in your testing process. [0] http://people.suug.ch/~tgr/bmon/ From Robert.Olsson@data.slu.se Sun Apr 3 12:57:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 12:57:51 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Jvkb1015443 for ; Sun, 3 Apr 2005 12:57:46 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j33Jv8ZD020427; Sun, 3 Apr 2005 21:57:08 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 9116BEE2B1; Sun, 3 Apr 2005 21:57:08 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16976.19092.562006.246545@robur.slu.se> Date: Sun, 3 Apr 2005 21:57:08 +0200 To: Herbert Xu Cc: "David S. Miller" , Robert.Olsson@data.slu.se, dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050403074337.GA8083@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> <20050403074337.GA8083@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Herbert Xu writes: > We could also move rt_cache_flush into a kernel thread. When the > number of chains is large this function is really expensive for a > softirq handler. It can also be done via /proc and left to administrators to find suitable policy. Kernel just provides the mechanism to rehash. --ro From herbert@gondor.apana.org.au Sun Apr 3 14:45:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 14:45:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Lj1Xs018984 for ; Sun, 3 Apr 2005 14:45:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DICtO-00073M-00; Mon, 04 Apr 2005 07:44:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DICsw-00049E-00; Mon, 04 Apr 2005 07:43:58 +1000 Date: Mon, 4 Apr 2005 07:43:58 +1000 To: Robert Olsson Cc: Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050403214358.GA15901@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <16976.17876.832677.945878@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16976.17876.832677.945878@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 09:36:52PM +0200, Robert Olsson wrote: > > Well I don't see how we detect the need for rehash just be looking > at the hash chains. How does the the "lengthening" look like that > are allowed to trigger a rehash? The only way to attack a hash is by exploiting collisions and create one or more excessively long chains. This can be detected as follows at each rt hash insertion. If (total number of entries in cache >> (hash length - user defined length)) < current bucket length is true, then we schedule a rehash/flush. Hash length is the number of bits in the hash, i.e., 1 << hash length == number of buckets I'd suggest a default shift length of 3. That is, if any individual chain is growing beyond 8 times the average chain length then we've got a problem. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 3 14:45:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 14:45:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Ljjdx019058 for ; Sun, 3 Apr 2005 14:45:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DICuN-00073c-00; Mon, 04 Apr 2005 07:45:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DICuH-00049k-00; Mon, 04 Apr 2005 07:45:21 +1000 Date: Mon, 4 Apr 2005 07:45:21 +1000 To: Robert Olsson Cc: "David S. Miller" , dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050403214521.GB15901@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> <20050403074337.GA8083@gondor.apana.org.au> <16976.19092.562006.246545@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16976.19092.562006.246545@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 09:57:08PM +0200, Robert Olsson wrote: > > Herbert Xu writes: > > > We could also move rt_cache_flush into a kernel thread. When the > > number of chains is large this function is really expensive for a > > softirq handler. > > It can also be done via /proc and left to administrators to find > suitable policy. Kernel just provides the mechanism to rehash. The reason I'm suggesting the move to a kernel thread is because softirq context is not preemptible. So doing a large amount of work in it when your table is big means that a UP machine will freeze for a while. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From a.kasparas@gmc.lt Sun Apr 3 15:02:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 15:02:18 -0700 (PDT) Received: from smtp02.omnitel.sun (smtp02-neptunas.omnitel.net [194.176.45.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33M29ro020932 for ; Sun, 3 Apr 2005 15:02:12 -0700 Received: from smtp04-neptunas.omnitel.net ([194.176.45.42]) by smtp02.omnitel.sun (Sun Java System Messaging Server 6.1 HotFix 0.01 (built Jun 24 2004)) with ESMTP id <0IEE006C357G3Y00@smtp02.omnitel.sun> for netdev@oss.sgi.com; Mon, 04 Apr 2005 01:02:04 +0300 (EEST) Received: from smtp04-neptunas.omnitel.net (localhost [127.0.0.1]) by smtp04-neptunas.omnitel.net (Postfix) with SMTP id C5B95398007; Mon, 04 Apr 2005 01:02:03 +0300 (EEST) Received: from [192.168.0.128] (unknown [62.212.195.62]) by smtp04-neptunas.omnitel.net (Postfix) with ESMTP id 5144A39800D; Mon, 04 Apr 2005 01:02:03 +0300 (EEST) Date: Mon, 04 Apr 2005 01:02:01 +0300 From: Aidas Kasparas Subject: Re: IPSEC: on behavior of acquire In-reply-to: <1112538566.1096.391.camel@jzny.localdomain> To: hadi@cyberus.ca Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org Message-id: <425067D9.9050603@gmc.lt> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: lt, en, ru, fr X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> <1112538566.1096.391.camel@jzny.localdomain> User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev jamal wrote: > On Sun, 2005-04-03 at 04:28, Aidas Kasparas wrote: > >>jamal wrote: > > >>>Exactly what i was trying to emulate - lost messages. >> >>Your emulation was not correct. More correct would have been to start KE >>daemon, let it fully initialize (open pfkey socket, inform kernel that >>it is interested in acquire messages), then stop it (via debugger or >>kill -STOP) and only then send pings or other traffic and see what will >>happen. This is because there are different paths in xfrm+pfkey for >>cases 1) when there is no KE daemon and 2) when daemon is, but for some >>reason it does not establish a SA and therefore reaction to traffic is >>different. >> > > > I dont think that would work. > To summarize what happens in the kernel: everything leads to km_query() > as you have indicated in your text. > If the kernel finds someone/thing has either a pfkey or netlink socket > open it sends a acquire to them. In the code you are probably looking at > (before i created the patch) - the first user/daemon the kernel sees > (either pfkey or netlink based) that has a socket open > will receive an acquire and the kernel will give up after that. > > As an example, if the first pfkey user was just doing "setkey -x" and > the second was infact pluto, then pluto will never see the > acquire. This is what got me looking at it to begin with. Look at the > earlier postings on the subject. While I agree that code before your patch would not allow to cooperate tools using different ways to manage SAD/SPD (pfkey vs netlink), I have one setup in production where two instances of racoon runs simultaneously and both gets required pfkey-messages. > So in other words, just killing the ike server as you propose would mean > the kernel has no open sockets and will therefore never bother to send > an acquire. I proposed to stop KE server, not to kill it. > > Still all this is moot and is distracting us from the main discussion. > Lets define "lost" simply as the case where an acquire never got to the > server (which may be sitting elsewhere on the network). ACQUIREs _never_ _leaves_ _the box_ they are generated. It is allways kernel-to-userspace_process communication. It could be made reliable. And present situation IS sufficiently reliable. In that case > what i did is sufficient. i.e. The methods to create this are not the > issue. The issue at stake is the behavior of the kernel in generating > the acquires. > See below. > > Please refer to my earlier definition of what "lost" means. It doesnt > matter where the breakage happens really. > Think of everything to the right of "xfrm" in your diagram as a black > box (i.e that second thing could be pfkey or netlink - thats not the > issue). > Think of some message that is supposed to reach the KE daemon > (make it interesting and say it is remote KE) then think of that message > never making it because something in the blackbox swallowed it. > If that packet is the first one and it needs to do so for the sake of > setup for subsequent packets - then the desire to have it reach its > destination is very imprtant. There is no progress for it or subsequent > packets if it doesnt make it. OK, let's talk about architecture xfrm <-> blackbox. In this architecture communication between these two elements (I do not speak about any comms in the blackbox) can be of two types: 1) reliable (messages always reach blackbox or error is reported); 2) unreliable (messages may fail even to reach blackbox). With good blackboxes good ipsec system can be built using any of comm types. But: a) (1) will be more reliable; b) (1) will be more simple (at least xfrm side, as it will not require retransmisions); c) (1) is implemented now (as a function call). What I want to say is xfrm-to-blackbox interface is good as it is. The problem may only be in how good the blackbox is. And here we have to look inside blackbox and start talk about particular implementations of that blackbox. Retransmitions, if they needed, needs to be inside that blackbox. > > The solution being proposed for Linux to treat that xfrm piece in the > same fashion as ARP is correct. Read the email from Alexey. Imagine if > ARP was only issued once(as does pfkey) or forever(as does netlink). > I have read email from Alexey. I think that xfrm_lookup() function implements functionality very similar to functionality which Alexey described. And I think that direct comparison of ARP messages and pfkey messages is not fair, because pfkey acquire messages goes over reliable traffic and are used only to _initiate_ the process of SA negotiation. ARP has to receive information from other boxes which send it only as a direct responce to some packet. More, ARP is designed to be used [amogst others] on networks which loose some traffic by design. > I believe this is an issue with ipsec architecture itself - someone > needs to write an IETF draft on it. > I still do not see the topic for such draft. > >>> >>>Note: Sometimes theres no app. Example a packet coming into a gateway. >>> >> >>What do you have in mind? >> >>If it is ISAKMP negotiation from remote peer, then it comes over UDP/500 >>or UDP/4500 over IP socket and not via acquire message via pfkey socket. >> >>If it is ESP/AH packet with unknown SPI, then kernel simply drops it and >>do not send any acquire messages. >> > > > I was thinking more of this second scenario with incoming from clear > text domain and gateway encrypting assuming proper policy setup. If you're talking about network behind security gateway communicating to host or network for which there is security policy configured on gateway, then acquire message will be generated on that security gateway, when that packet will be considered for forwarding. Again, that acquire messages never will leave security gateway. > I would have to go and reread the "opportunistic" encryption draft > closely to make sense. > Speaking of "opportunistic" encryption. I never understood it. Ipsec-tools do not implement it. And in the year or so when I'm involved with it, I don't remember anybody even asking or mentioning about this feature. Therefore, I don't care about it -- users do not need it. -- Aidas Kasparas IT administrator GM Consult Group, UAB From dmitry_yus@yahoo.com Sun Apr 3 17:56:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 17:56:32 -0700 (PDT) Received: from smtp111.mail.sc5.yahoo.com (smtp111.mail.sc5.yahoo.com [66.163.170.9]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j340uQ4U030035 for ; Sun, 3 Apr 2005 17:56:26 -0700 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp111.mail.sc5.yahoo.com with SMTP; 4 Apr 2005 00:56:25 -0000 Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) From: Dmitry Yusupov To: "open-iscsi@googlegroups.com" Cc: "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> Content-Type: text/plain Date: Sun, 03 Apr 2005 17:56:11 -0700 Message-Id: <1112576171.4227.5.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev On Sat, 2005-04-02 at 11:07 -0800, Asgeir Eiriksson wrote: > Dmitry > The CPU cycles is only at most half of the story with the other half > being the memory sub-system BW. > > So the validity of your observation depends on the BW we're talking > about, i.e. if the client is using a fraction of 10Gbps for RDMA (or > DDP, e.g. iSCSI DDP), yes then that fraction amounts to a fraction of > the memory sub-system total BW so we don't much care about the extra > copy. > > The situation is different if the client wants something close to 10Gbps > (already have such client applications), because today 10Gbps is still a > big chunk of the overall memory BW so you really care about eliminating > that copy via DDP. I do not get your concern with memory BW. With good AMD box V40Z(SUN) you can get 5.3GBytes/sec. Even with 10Gbps full speed you have 80% left. PCI-X BUS BW is bigger concern... > 'Asgeir > > > -----Original Message----- > > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > > Behalf Of Dmitry Yusupov > > Sent: Saturday, April 02, 2005 10:09 AM > > To: open-iscsi@googlegroups.com > > Cc: David S. Miller; mpm@selenic.com; andrea@suse.de; > > michaelc@cs.wisc.edu; James.Bottomley@HansenPartnership.com; > ksummit-2005- > > discuss@thunk.org; netdev@oss.sgi.com > > Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit > > ProposedTopics > > > > On Mon, 2005-03-28 at 17:32 -0500, Benjamin LaHaise wrote: > > > On Mon, Mar 28, 2005 at 12:48:56PM -0800, Dmitry Yusupov wrote: > > > > If you have plans to start new project such as SoftRDMA than yes. > lets > > > > discuss it since set of problems will be similar to what we've got > > with > > > > software iSCSI Initiators. > > > > > > I'm somewhat interested in seeing a SoftRDMA project get off the > ground. > > > At least the NatSemi 83820 gige MAC is able to provide early-rx > > interrupts > > > that allow one to get an rx interrupt before the full payload has > > arrived > > > making it possible to write out a new rx descriptor to place the > payload > > > wherever it is ultimately desired. It would be fun to work on if > not > > the > > > most performant RDMA implementation. > > > > I see a lot of skepticism around early-rx interrupt schema. It might > > work for gige, but i'm not sure if it will fit into 10g. > > > > What RDMA gives us is zero-copy on receive and new networking api > which > > has a potential to be HW accelerated. SoftRDMA will never avoid > copying > > on receive. But benefit for SoftRDMA would be its availability on > client > > sides. It is free and it could be easily deployed. Soon Intel & Co > will > > give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if > > one of those cores will do receive side copying? > > > > From herbert@gondor.apana.org.au Sun Apr 3 18:00:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 18:00:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3410Dar030521 for ; Sun, 3 Apr 2005 18:00:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIFw6-0007tf-00; Mon, 04 Apr 2005 10:59:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIFun-0004NB-00; Mon, 04 Apr 2005 10:58:05 +1000 Date: Mon, 4 Apr 2005 10:58:05 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404005805.GA16543@gondor.apana.org.au> References: <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112538718.1096.394.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Hi Jamal: On Sun, Apr 03, 2005 at 10:31:58AM -0400, jamal wrote: > > Small change after some testing. > Herbert havent heard back from you - this looks very palatable in my > opinion with comments below still in effect. It's definitely looking better all the time. > -void xfrm_state_delete(struct xfrm_state *x) > +static DEFINE_RWLOCK(xfrm_km_lock); > +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > + > +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) > { > + struct xfrm_mgr *km; > + > + read_lock(&xfrm_km_lock); > + list_for_each_entry(km, &xfrm_km_list, list) > + if (km->notify_policy) > + km->notify_policy(xp, dir, c); > + read_unlock(&xfrm_km_lock); > +} > + > +void km_state_notify(struct xfrm_state *x, struct km_event *c) > +{ > + struct xfrm_mgr *km; > + read_lock(&xfrm_km_lock); > + list_for_each_entry(km, &xfrm_km_list, list) > + km->notify(x, c); > + read_unlock(&xfrm_km_lock); > +} > + > +EXPORT_SYMBOL(km_policy_notify); > +EXPORT_SYMBOL(km_state_notify); Can we perhaps move these lines next to the other km functions further down? They look rather lonely here. > + /* XXX: Do we wanna do this right at the top?? > + * if the state is dead we dont want to announce > + * the expire - a delete may already have announced > + * it > + */ Please code this check differently so that it isn't racy. One way to do it is to change xfrm_timer_handler to do: if (__xfrm_state_delete(x) && x->id.spi) km_state_expired(x, 1); > + /* XXX: Do we still wanna wakeup km_waitq? > + * if the policy is dead we dont want to announce > + * the expire - a delete may already have announced > + * it > + */ Ditto. > --- a/net/xfrm/xfrm_policy.c 2005-03-25 22:28:21.000000000 -0500 > +++ b/net/xfrm/xfrm_policy.c 2005-04-02 12:16:30.000000000 -0500 > @@ -298,7 +298,7 @@ > * entry dead. The rule must be unlinked from lists to the moment. > */ > > -static void xfrm_policy_kill(struct xfrm_policy *policy) > +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir) What's this for? > + c.seq = nlh->nlmsg_seq; > + c.pid = nlh->nlmsg_pid; > + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) > + c.event = XFRM_SAP_ADDED; > + else > + c.event = XFRM_SAP_UPDATED; > + > + km_state_notify(x, &c); You need to hold onto x here. So do a hold before you call xfrm_state_* and then drop the reference after km_state_notify. > static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) > - xfrm_state_delete(x); > + err = xfrm_state_delete(x); > + if (err < 0) { > + x->km.state = XFRM_STATE_DEAD; > + xfrm_state_put(x); > + return err; If the xfrm_state_delete fails then it's already dead. So kill the line that modifies its state. > +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c) Extra space after the paren. > + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); Please add the additional payloads for NAT-T and the keys. > +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) > +{ > + struct xfrm_userpolicy_info *p; > + struct nlmsghdr *nlh; > + struct sk_buff *skb; > + u32 nlt = 0 ; > + unsigned char *b; > + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); Please attach the templates. > @@ -1256,7 +1328,7 @@ > > if (hdr->sadb_msg_type == SADB_ADD) > err = xfrm_state_add(x); > - else > + else A better editor that doesn't leave trailing spaces is needed here :) > - xfrm_state_delete(x); > - xfrm_state_put(x); > + err = xfrm_state_delete(x); > + if (err < 0) { > + x->km.state = XFRM_STATE_DEAD; Please remove this line as it's already dead if the delete fails. > +static int key_notify_sa_flush(struct km_event *c) > +{ > + struct sk_buff *skb; > + struct sadb_msg *hdr; > + > + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); > + if (!skb) > + return -ENOBUFS; > + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); > + // XXX:do we have to pass proto as well? I think so. A flush of all IPCOMP states is certainly quite different from a flush of all states. It's just a matter of calling satype2proto. > + /* > + * XXX: previous get was doing a broadcast-all _always_ > + * which didnt seem right for non-deletion case - JHS > + * This is like the way netlink behaves .. > + * Shall i restore original behavior? > + */ You're right. The original behaviour was broken. > - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); > - > - out_hdr = (struct sadb_msg *) out_skb->data; > - out_hdr->sadb_msg_version = hdr->sadb_msg_version; > - out_hdr->sadb_msg_type = hdr->sadb_msg_type; > - out_hdr->sadb_msg_satype = 0; > - out_hdr->sadb_msg_errno = 0; > - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; > - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; > - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); > - err = 0; However, you do need to keep this code for the real GET case. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 3 18:01:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 18:01:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3411ZoF030968 for ; Sun, 3 Apr 2005 18:01:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIFxw-0007uK-00; Mon, 04 Apr 2005 11:01:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIFxq-0004Nw-00; Mon, 04 Apr 2005 11:01:14 +1000 Date: Mon, 4 Apr 2005 11:01:14 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404010114.GA16839@gondor.apana.org.au> References: <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112469601.1088.173.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 02:20:01PM -0500, jamal wrote: > > 1) Weve discussed this before Herbert and i think you misspoke that > pfkey delivers to all listerners. > > pfkey Add/del/upd now really do tell all processes about what happened. > Before pfkey would skip the originating process. So far this doesnt seem > to be an issue in the basic testing. Are you sure? Previously they did BROADCAST_ALL which goes to everyone including the sender. > 2) I ended adding a policy_notify to the pfkey manager to make the code > generic. Interesting thing is i dont think pfkey knows what to do with > policy expiration or i am misreading the code. That's right, pfkey never had policy expire messages. In general, anything to do with policies cannot be done portably in pfkey since the RFC only specified the SA operations. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 3 18:21:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 18:21:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j341LRI0032620 for ; Sun, 3 Apr 2005 18:21:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIGH5-00081d-00; Mon, 04 Apr 2005 11:21:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIGGe-0004RN-00; Mon, 04 Apr 2005 11:20:40 +1000 Date: Mon, 4 Apr 2005 11:20:40 +1000 To: Patrick McHardy Cc: "David S. Miller" , netdev Subject: Re: [IPSEC]: Protect against BHs in xfrm_user_policy() Message-ID: <20050404012040.GA16960@gondor.apana.org.au> References: <4250160D.2040405@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4250160D.2040405@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 06:13:01PM +0200, Patrick McHardy wrote: > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2005/04/03 17:36:10+02:00 kaber@coreworks.de > # [IPSEC]: Protect against BHs in xfrm_user_policy() > # > # Signed-off-by: Patrick McHardy Looks good. Signed-off-by: Herbert Xu We want the same thing for km_query, no? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Apr 3 18:56:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 18:56:18 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j341uBfD001738 for ; Sun, 3 Apr 2005 18:56:12 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DIGp4-0003Fv-6P for netdev@oss.sgi.com; Sun, 03 Apr 2005 21:56:14 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIGow-00044s-OZ; Sun, 03 Apr 2005 21:56:07 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404005805.GA16543@gondor.apana.org.au> References: <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112579761.1096.412.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 21:56:01 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Herbert, Now that you are picking on whitespaces i think we are almost there ;-> Comments below On Sun, 2005-04-03 at 20:58, Herbert Xu wrote: > On Sun, Apr 03, 2005 at 10:31:58AM -0400, jamal wrote: [.. ..] > > + > > +EXPORT_SYMBOL(km_policy_notify); > > +EXPORT_SYMBOL(km_state_notify); > > Can we perhaps move these lines next to the other km functions > further down? They look rather lonely here. > Sure. > > + /* XXX: Do we wanna do this right at the top?? > > + * if the state is dead we dont want to announce > > + * the expire - a delete may already have announced > > + * it > > + */ > > Please code this check differently so that it isn't racy. > > One way to do it is to change xfrm_timer_handler to do: > > if (__xfrm_state_delete(x) && x->id.spi) > km_state_expired(x, 1); > > > + /* XXX: Do we still wanna wakeup km_waitq? > > + * if the policy is dead we dont want to announce > > + * the expire - a delete may already have announced > > + * it > > + */ > > Ditto. > I think i am gonna take out any attempts to address this race above. It's a bug thats there already - a separate patch after this will be better. > > --- a/net/xfrm/xfrm_policy.c 2005-03-25 22:28:21.000000000 -0500 > > +++ b/net/xfrm/xfrm_policy.c 2005-04-02 12:16:30.000000000 -0500 > > @@ -298,7 +298,7 @@ > > * entry dead. The rule must be unlinked from lists to the moment. > > */ > > > > -static void xfrm_policy_kill(struct xfrm_policy *policy) > > +static void xfrm_policy_kill(struct xfrm_policy *policy, int dir) > > What's this for? > Good catch - gunk from previous patch. > > + c.seq = nlh->nlmsg_seq; > > + c.pid = nlh->nlmsg_pid; > > + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) > > + c.event = XFRM_SAP_ADDED; > > + else > > + c.event = XFRM_SAP_UPDATED; > > + > > + km_state_notify(x, &c); > > You need to hold onto x here. So do a hold before you call xfrm_state_* > and then drop the reference after km_state_notify. Good point. > > > static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) > > > - xfrm_state_delete(x); > > + err = xfrm_state_delete(x); > > + if (err < 0) { > > + x->km.state = XFRM_STATE_DEAD; > > + xfrm_state_put(x); > > + return err; > > If the xfrm_state_delete fails then it's already dead. So kill > the line that modifies its state. > Good point. > > +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c) > > Extra space after the paren. > > > + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); > > Please add the additional payloads for NAT-T and the keys. > I dont think we should broadcast out keys. NAT-T - where do i look at to see what to send? > > +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) > > +{ > > + struct xfrm_userpolicy_info *p; > > + struct nlmsghdr *nlh; > > + struct sk_buff *skb; > > + u32 nlt = 0 ; > > + unsigned char *b; > > + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); > > Please attach the templates. > What is not being attached right now? > > @@ -1256,7 +1328,7 @@ > > > > if (hdr->sadb_msg_type == SADB_ADD) > > err = xfrm_state_add(x); > > - else > > + else > > A better editor that doesn't leave trailing spaces is needed here :) you insulting vi? ;-> > > > - xfrm_state_delete(x); > > - xfrm_state_put(x); > > + err = xfrm_state_delete(x); > > + if (err < 0) { > > + x->km.state = XFRM_STATE_DEAD; > > Please remove this line as it's already dead if the delete fails. > > > +static int key_notify_sa_flush(struct km_event *c) > > +{ > > + struct sk_buff *skb; > > + struct sadb_msg *hdr; > > + > > + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); > > + if (!skb) > > + return -ENOBUFS; > > + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); > > + // XXX:do we have to pass proto as well? > > I think so. A flush of all IPCOMP states is certainly quite different > from a flush of all states. It's just a matter of calling satype2proto. > Looks doable. > > - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); > > - > > - out_hdr = (struct sadb_msg *) out_skb->data; > > - out_hdr->sadb_msg_version = hdr->sadb_msg_version; > > - out_hdr->sadb_msg_type = hdr->sadb_msg_type; > > - out_hdr->sadb_msg_satype = 0; > > - out_hdr->sadb_msg_errno = 0; > > - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; > > - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; > > - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); > > - err = 0; > > However, you do need to keep this code for the real GET case. > Get seems to a separate entry point - pfkey_get() which i didnt touch. cheers, jamal From hadi@cyberus.ca Sun Apr 3 18:58:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 18:58:44 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j341wdtn002139 for ; Sun, 3 Apr 2005 18:58:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DIGrO-0001ng-NF for netdev@oss.sgi.com; Sun, 03 Apr 2005 21:58:38 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIGrN-0004J2-0l; Sun, 03 Apr 2005 21:58:37 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404010114.GA16839@gondor.apana.org.au> References: <20050401042106.GA27762@gondor.apana.org.au> <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <20050404010114.GA16839@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112579911.1088.416.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 21:58:31 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2005-04-03 at 21:01, Herbert Xu wrote: > On Sat, Apr 02, 2005 at 02:20:01PM -0500, jamal wrote: > > > > 1) Weve discussed this before Herbert and i think you misspoke that > > pfkey delivers to all listerners. > > > > pfkey Add/del/upd now really do tell all processes about what happened. > > Before pfkey would skip the originating process. So far this doesnt seem > > to be an issue in the basic testing. > > Are you sure? Previously they did BROADCAST_ALL which goes to everyone > including the sender. > Yes, he key is in the sk parameter to the broadcast. if a NULL is passed then all listeners are told. Else the passed sk is excluded. > > 2) I ended adding a policy_notify to the pfkey manager to make the code > > generic. Interesting thing is i dont think pfkey knows what to do with > > policy expiration or i am misreading the code. > > That's right, pfkey never had policy expire messages. In general, > anything to do with policies cannot be done portably in pfkey since > the RFC only specified the SA operations. > Well, hopefully whoever defined that pfkey carries policies as well will have to worry about this in the future. I will just leave teh hook but remove the printk. cheers, jamal From herbert@gondor.apana.org.au Sun Apr 3 19:27:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:28:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342RqqX003988 for ; Sun, 3 Apr 2005 19:27:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIHJ6-0008Gg-00; Mon, 04 Apr 2005 12:27:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIHHt-0004WT-00; Mon, 04 Apr 2005 12:26:01 +1000 Date: Mon, 4 Apr 2005 12:26:01 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404022601.GA17293@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112579761.1096.412.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112579761.1096.412.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 09:56:01PM -0400, jamal wrote: > Now that you are picking on whitespaces i think we are almost there ;-> Yes I think we're getting really close now :) > I think i am gonna take out any attempts to address this race above. > It's a bug thats there already - a separate patch after this will be > better. OK. > > > +static int xfrm_notify_sa( struct xfrm_state *x, struct km_event *c) > > > > Extra space after the paren. > > > > > + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); > > > > Please add the additional payloads for NAT-T and the keys. > > I dont think we should broadcast out keys. I think that decision should be made by the KM. So you wouldn't do it for PFKEY, but netlink should definitely do it. For netlink we require root privileges to listen for these events. > NAT-T - where do i look at to see what to send? Check out dump_one_state. > What is not being attached right now? copy_to_user_tmpl > you insulting vi? ;-> Yes unless you're using elvis :) > > > - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); > > > - > > > - out_hdr = (struct sadb_msg *) out_skb->data; > > > - out_hdr->sadb_msg_version = hdr->sadb_msg_version; > > > - out_hdr->sadb_msg_type = hdr->sadb_msg_type; > > > - out_hdr->sadb_msg_satype = 0; > > > - out_hdr->sadb_msg_errno = 0; > > > - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; > > > - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; > > > - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); > > > - err = 0; > > > > However, you do need to keep this code for the real GET case. > > Get seems to a separate entry point - pfkey_get() which i didnt touch. pfkey_get() only does states. The code above is in pfkey_spdget(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 3 19:28:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:28:09 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342S3RH004003 for ; Sun, 3 Apr 2005 19:28:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIHJR-0008H9-00; Mon, 04 Apr 2005 12:27:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIHJG-0004Wu-00; Mon, 04 Apr 2005 12:27:26 +1000 Date: Mon, 4 Apr 2005 12:27:26 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404022726.GB17293@gondor.apana.org.au> References: <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <20050404010114.GA16839@gondor.apana.org.au> <1112579911.1088.416.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112579911.1088.416.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 09:58:31PM -0400, jamal wrote: > > > Are you sure? Previously they did BROADCAST_ALL which goes to everyone > > including the sender. > > Yes, he key is in the sk parameter to the broadcast. if a NULL is passed > then all listeners are told. Else the passed sk is excluded. Actually pfkey_broadcast is playing tricks on you :) It always does one_sk at the end of the function. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Apr 3 19:34:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:34:19 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342YEsN005276 for ; Sun, 3 Apr 2005 19:34:14 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DIHPj-0003aN-7X for netdev@oss.sgi.com; Sun, 03 Apr 2005 20:34:07 -0600 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIHPl-0008SS-Kr; Sun, 03 Apr 2005 22:34:09 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404005805.GA16543@gondor.apana.org.au> References: <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112582044.1087.421.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 22:34:04 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2005-04-03 at 20:58, Herbert Xu wrote: > ; > > + // XXX:do we have to pass proto as well? > > I think so. A flush of all IPCOMP states is certainly quite different > from a flush of all states. It's just a matter of calling satype2proto. I think you meant pfkey_proto2satype(). i.e hdr->sadb_msg_satype = pfkey_proto2satype(c->data); BTW, slightly different from the way netlink does bussiness. cheers, jamal From hadi@cyberus.ca Sun Apr 3 19:40:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:40:09 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342e42X006001 for ; Sun, 3 Apr 2005 19:40:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIHVT-0005hE-IV for netdev@oss.sgi.com; Sun, 03 Apr 2005 22:40:03 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIHVS-0000ZI-9x; Sun, 03 Apr 2005 22:40:02 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404022601.GA17293@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112579761.1096.412.camel@jzny.localdomain> <20050404022601.GA17293@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112582396.1096.427.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 22:39:56 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2005-04-03 at 22:26, Herbert Xu wrote: > On Sun, Apr 03, 2005 at 09:56:01PM -0400, jamal wrote: > > I dont think we should broadcast out keys. > > I think that decision should be made by the KM. So you wouldn't do it > for PFKEY, but netlink should definitely do it. > Is it possible to have non-root privileged pfkey sockets. If yes, then it makes sense. > Yes unless you're using elvis :) Elvis left the building a while back ;-> But sightings of him in some doughnought shops in a small town not far from here are rampant ;-> > The code above is in pfkey_spdget(). > How did i miss that? ;-> cheers, jamal From herbert@gondor.apana.org.au Sun Apr 3 19:46:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:46:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342ki4S006756 for ; Sun, 3 Apr 2005 19:46:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIHba-0008Nh-00; Mon, 04 Apr 2005 12:46:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIHbE-0004Yk-00; Mon, 04 Apr 2005 12:46:00 +1000 Date: Mon, 4 Apr 2005 12:46:00 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404024600.GA17507@gondor.apana.org.au> References: <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112579761.1096.412.camel@jzny.localdomain> <20050404022601.GA17293@gondor.apana.org.au> <1112582396.1096.427.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112582396.1096.427.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 10:39:56PM -0400, jamal wrote: > On Sun, 2005-04-03 at 22:26, Herbert Xu wrote: > > > I think that decision should be made by the KM. So you wouldn't do it > > for PFKEY, but netlink should definitely do it. > > Is it possible to have non-root privileged pfkey sockets. If yes, > then it makes sense. Currently Linux requires CAP_NET_ADMIN for PFKEY. However, this may not be the case on other systems. That's the reason why the RFC requires that the keys not be sent via PFKEY. However for netlink there is no such issue. Even if we do eventually open up netlink for non-root listeners (this will actually require structural changes to netlink itself), we can create a new multicast group for non-privileged users that don't get the keys. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 3 19:53:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 19:54:08 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j342rv2D007479 for ; Sun, 3 Apr 2005 19:53:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIHiG-0008R0-00; Mon, 04 Apr 2005 12:53:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIHhK-0004Zi-00; Mon, 04 Apr 2005 12:52:18 +1000 Date: Mon, 4 Apr 2005 12:52:18 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404025218.GA17571@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112582044.1087.421.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112582044.1087.421.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 10:34:04PM -0400, jamal wrote: > > I think you meant pfkey_proto2satype(). i.e > hdr->sadb_msg_satype = pfkey_proto2satype(c->data); Yes I was being dyslexic :) > BTW, slightly different from the way netlink does bussiness. You mean how netlink just passes the proto through verbatim? Yes netlink uses the natural representation wherever possible. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Apr 3 20:05:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 20:05:34 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3435S3d008376 for ; Sun, 3 Apr 2005 20:05:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIHu4-0005ko-43 for netdev@oss.sgi.com; Sun, 03 Apr 2005 23:05:28 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIHtz-0003Ka-4w; Sun, 03 Apr 2005 23:05:23 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404024600.GA17507@gondor.apana.org.au> References: <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112579761.1096.412.camel@jzny.localdomain> <20050404022601.GA17293@gondor.apana.org.au> <1112582396.1096.427.camel@jzny.localdomain> <20050404024600.GA17507@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112583912.1096.429.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 23:05:12 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1321 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, 2005-04-03 at 22:46, Herbert Xu wrote: > Even if we do eventually open up netlink for non-root listeners > (this will actually require structural changes to netlink itself), > we can create a new multicast group for non-privileged users that > don't get the keys. > Ok, I will add the keys in the case of the netlink announce. cheers, jamal From hadi@cyberus.ca Sun Apr 3 20:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 20:07:37 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3437W7f008613 for ; Sun, 3 Apr 2005 20:07:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIHw4-0006g6-7v for netdev@oss.sgi.com; Sun, 03 Apr 2005 23:07:32 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIHw3-0003XB-1G; Sun, 03 Apr 2005 23:07:31 -0400 Subject: Re: take 2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404025218.GA17571@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112582044.1087.421.camel@jzny.localdomain> <20050404025218.GA17571@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112584046.1088.432.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2005 23:07:26 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1322 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, 2005-04-03 at 22:52, Herbert Xu wrote: > You mean how netlink just passes the proto through verbatim? > Yes netlink uses the natural representation wherever possible. > The one thing that needs discussing at some point is how to break down the policy and state structural entities into TLVs in netlink. Not now, future topic ;-> cheers, jamal From rddunlap@osdl.org Sun Apr 3 20:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 20:31:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j343VCoE013586 for ; Sun, 3 Apr 2005 20:31:12 -0700 Received: from [192.168.1.103] (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j343UIs3017661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 3 Apr 2005 20:30:19 -0700 Message-ID: <4250B4C5.2000200@osdl.org> Date: Sun, 03 Apr 2005 20:30:13 -0700 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg CC: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: [PATCH] network configs: disconnect network options from drivers References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> In-Reply-To: <20050331203010.GA8034@mars.ravnborg.org> Content-Type: multipart/mixed; boundary="------------000906010009010506010105" X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------000906010009010506010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sam Ravnborg wrote: > On Thu, Mar 31, 2005 at 12:02:13PM -0800, Randy.Dunlap wrote: > >>Other than "sounds good," are there some comments on: >> >>a. leaving IrDA and Bluetooth subsystem (with drivers) where they >> are, which is under "Network options and protocols" >> (I really don't want to split their drivers away from their >> subsystem, just to put them under Network driver support.) > > > Agreed. All IrDA / Bluetooth stuff belongs together. > Leave them where they are for now. > > >>b. leaving SLIP, PPP, and PLIP where they are under Network driver >> support, even though they say that they are "protocols" ? > > SLIP and PLIP is no that common. PPP is more common for cable-modem/ADSL > I suppose. But still it would make sense to create an Misc protocols > menu, like we have a misc filesystems menu. While looking into this suggestion, I see that SLIP, PLIP, and PPP depend on NETDEVICES, and they use some netdev interfaces, so they appear to be more like net devices than protocols even though they are called protocols in Kconfig text, so I am leaving them alone for now. Don't hesitate to correct me.... Any comments on this new version? Thanks, -- ~Randy --------------000906010009010506010105 Content-Type: text/x-patch; name="netconfigs_v4.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netconfigs_v4.diff" A few people dislike that the Networking Options menu is inside the Device Drivers/Networking menu. This patch moves the Networking Options menu to immediately before the Device Drivers menu, renames it to "Networking options and protocols", & moves most protocols to more logical places. Notes: - IrDA & Bluetooth subsystems include protocols & drivers, yet they are displayed under Networking protocols. I don't see much good reason to split them up. (See, this is an example of why the Networking Options and Network Drivers were close together....) - SLIP, PLIP, and PPP option names say that they are protocols, but they are sort of a hybrid device and protocol, and they use network device interfaces, so they remain listed under Network devices. drivers/Kconfig | 4 drivers/net/Kconfig | 5 net/Kconfig | 450 ++++++++++++++++++++++--------------------- net/bridge/netfilter/Kconfig | 1 4 files changed, 241 insertions(+), 219 deletions(-) Signed-off-by: Randy Dunlap diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-2612-rc1-bk5-pv/drivers/Kconfig linux-2612-rc1-bk5-netconfigs/drivers/Kconfig --- linux-2612-rc1-bk5-pv/drivers/Kconfig 2005-03-01 23:38:26.000000000 -0800 +++ linux-2612-rc1-bk5-netconfigs/drivers/Kconfig 2005-04-03 19:45:18.330102257 -0700 @@ -1,5 +1,7 @@ # drivers/Kconfig +source "net/Kconfig" + menu "Device Drivers" source "drivers/base/Kconfig" @@ -28,7 +30,7 @@ source "drivers/message/i2o/Kconfig" source "drivers/macintosh/Kconfig" -source "net/Kconfig" +source "drivers/net/Kconfig" source "drivers/isdn/Kconfig" diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-2612-rc1-bk5-pv/drivers/net/Kconfig linux-2612-rc1-bk5-netconfigs/drivers/net/Kconfig --- linux-2612-rc1-bk5-pv/drivers/net/Kconfig 2005-04-03 19:42:32.000000000 -0700 +++ linux-2612-rc1-bk5-netconfigs/drivers/net/Kconfig 2005-04-03 19:45:18.335101815 -0700 @@ -1,8 +1,9 @@ - # # Network device configuration # +menu "Network device support" + config NETDEVICES depends on NET bool "Network device support" @@ -2536,3 +2537,5 @@ config NETCONSOLE If you want to log kernel messages over the network, enable this. See for details. +endmenu + diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-2612-rc1-bk5-pv/net/bridge/netfilter/Kconfig linux-2612-rc1-bk5-netconfigs/net/bridge/netfilter/Kconfig --- linux-2612-rc1-bk5-pv/net/bridge/netfilter/Kconfig 2005-03-01 23:37:50.000000000 -0800 +++ linux-2612-rc1-bk5-netconfigs/net/bridge/netfilter/Kconfig 2005-04-03 19:45:18.000000000 -0700 @@ -139,6 +139,7 @@ config BRIDGE_EBT_VLAN config BRIDGE_EBT_ARPREPLY tristate "ebt: arp reply target support" depends on BRIDGE_NF_EBTABLES + depends on INET help This option adds the arp reply target, which allows automatically sending arp replies to arp requests. diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-2612-rc1-bk5-pv/net/Kconfig linux-2612-rc1-bk5-netconfigs/net/Kconfig --- linux-2612-rc1-bk5-pv/net/Kconfig 2005-04-03 19:42:35.000000000 -0700 +++ linux-2612-rc1-bk5-netconfigs/net/Kconfig 2005-04-03 19:45:18.000000000 -0700 @@ -2,7 +2,7 @@ # Network configuration # -menu "Networking support" +menu "Networking options and protocols" config NET bool "Networking support" @@ -10,7 +10,9 @@ config NET Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even when running on a stand-alone machine that isn't connected to any - other computer. If you are upgrading from an older kernel, you + other computer. + + If you are upgrading from an older kernel, you should consider updating your networking tools too because changes in the kernel and the tools often go hand in hand. The tools are contained in the package net-tools, the location and version number @@ -20,11 +22,9 @@ config NET recommended to read the NET-HOWTO, available from . -menu "Networking options" - depends on NET - config PACKET tristate "Packet socket" + depends on NET ---help--- The Packet protocol is used by applications which communicate directly with network devices without an intermediate network @@ -47,6 +47,7 @@ config PACKET_MMAP config UNIX tristate "Unix domain sockets" + depends on NET ---help--- If you say Y here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and @@ -64,6 +65,7 @@ config UNIX config NET_KEY tristate "PF_KEY sockets" + depends on NET select XFRM ---help--- PF_KEYv2 socket family, compatible to KAME ones. @@ -72,8 +74,127 @@ config NET_KEY Say Y unless you know what you are doing. +config NETPOLL + depends on NET + def_bool NETCONSOLE + +config NETPOLL_RX + bool "Netpoll support for trapping incoming packets" + default n + depends on NETPOLL + +config NETPOLL_TRAP + bool "Netpoll traffic trapping" + default n + depends on NETPOLL + +config NET_POLL_CONTROLLER + def_bool NETPOLL + depends on NET + +config BRIDGE + tristate "802.1d Ethernet Bridging" + depends on NET + ---help--- + If you say Y here, then your Linux box will be able to act as an + Ethernet bridge, which means that the different Ethernet segments it + is connected to will appear as one Ethernet to the participants. + Several such bridges can work together to create even larger + networks of Ethernets using the IEEE 802.1 spanning tree algorithm. + As this is a standard, Linux bridges will cooperate properly with + other third party bridge products. + + In order to use the Ethernet bridge, you'll need the bridge + configuration tools; see + for location. Please read the Bridge mini-HOWTO for more + information. + + If you enable iptables support along with the bridge support then you + turn your bridge into a bridging IP firewall. + iptables will then see the IP packets being bridged, so you need to + take this into account when setting up your firewall rules. + Enabling arptables support when bridging will let arptables see + bridged ARP traffic in the arptables FORWARD chain. + + To compile this code as a module, choose M here: the module + will be called bridge. + + If unsure, say N. + +config VLAN_8021Q + tristate "802.1Q VLAN Support" + depends on NET + ---help--- + Select this and you will be able to create 802.1Q VLAN interfaces + on your ethernet interfaces. 802.1Q VLAN supports almost + everything a regular ethernet interface does, including + firewalling, bridging, and of course IP traffic. You will need + the 'vconfig' tool from the VLAN project in order to effectively + use VLANs. See the VLAN web page for more information: + + + To compile this code as a module, choose M here: the module + will be called 8021q. + + If unsure, say N. + +config NET_DIVERT + bool "Frame Diverter (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + The Frame Diverter allows you to divert packets from the + network, that are not aimed at the interface receiving it (in + promisc. mode). Typically, a Linux box setup as an Ethernet bridge + with the Frames Diverter on, can do some *really* transparent www + caching using a Squid proxy for example. + + This is very useful when you don't want to change your router's + config (or if you simply don't have access to it). + + The other possible usages of diverting Ethernet Frames are + numberous: + - reroute smtp traffic to another interface + - traffic-shape certain network streams + - transparently proxy smtp connections + - etc... + + For more informations, please refer to: + + + + If unsure, say N. + +config WAN_ROUTER + tristate "WAN router" + depends on NET && EXPERIMENTAL + ---help--- + Wide Area Networks (WANs), such as X.25, frame relay and leased + lines, are used to interconnect Local Area Networks (LANs) over vast + distances with data transfer rates significantly higher than those + achievable with commonly used asynchronous modem connections. + Usually, a quite expensive external device called a `WAN router' is + needed to connect to a WAN. + + As an alternative, WAN routing can be built into the Linux kernel. + With relatively inexpensive WAN interface cards available on the + market, a perfectly usable router can be built for less than half + the price of an external router. If you have one of those cards and + wish to use your Linux box as a WAN router, say Y here and also to + the WAN driver for your card, below. You will then need the + wan-tools package which is available from . + Read for more + information. + + To compile WAN routing support as a module, choose M here: the + module will be called wanrouter. + + If unsure, say N. + +menu "Networking protocols" + config INET bool "TCP/IP networking" + depends on NET ---help--- These are the protocols used on the Internet and on most local Ethernets. It is highly recommended to say Y here (this will enlarge @@ -118,105 +239,12 @@ config IPV6 source "net/ipv6/Kconfig" -menuconfig NETFILTER - bool "Network packet filtering (replaces ipchains)" - ---help--- - Netfilter is a framework for filtering and mangling network packets - that pass through your Linux box. - - The most common use of packet filtering is to run your Linux box as - a firewall protecting a local network from the Internet. The type of - firewall provided by this kernel support is called a "packet - filter", which means that it can reject individual network packets - based on type, source, destination etc. The other kind of firewall, - a "proxy-based" one, is more secure but more intrusive and more - bothersome to set up; it inspects the network traffic much more - closely, modifies it and has knowledge about the higher level - protocols, which a packet filter lacks. Moreover, proxy-based - firewalls often require changes to the programs running on the local - clients. Proxy-based firewalls don't need support by the kernel, but - they are often combined with a packet filter, which only works if - you say Y here. - - You should also say Y here if you intend to use your Linux box as - the gateway to the Internet for a local network of machines without - globally valid IP addresses. This is called "masquerading": if one - of the computers on your local network wants to send something to - the outside, your box can "masquerade" as that computer, i.e. it - forwards the traffic to the intended outside destination, but - modifies the packets to make it look like they came from the - firewall box itself. It works both ways: if the outside host - replies, the Linux box will silently forward the traffic to the - correct local computer. This way, the computers on your local net - are completely invisible to the outside world, even though they can - reach the outside and can receive replies. It is even possible to - run globally visible servers from within a masqueraded local network - using a mechanism called portforwarding. Masquerading is also often - called NAT (Network Address Translation). - - Another use of Netfilter is in transparent proxying: if a machine on - the local network tries to connect to an outside host, your Linux - box can transparently forward the traffic to a local server, - typically a caching proxy server. - - Yet another use of Netfilter is building a bridging firewall. Using - a bridge with Network packet filtering enabled makes iptables "see" - the bridged traffic. For filtering on the lower network and Ethernet - protocols over the bridge, use ebtables (under bridge netfilter - configuration). - - Various modules exist for netfilter which replace the previous - masquerading (ipmasqadm), packet filtering (ipchains), transparent - proxying, and portforwarding mechanisms. Please see - under "iptables" for the location of - these packages. - - Make sure to say N to "Fast switching" below if you intend to say Y - here, as Fast switching currently bypasses netfilter. - - Chances are that you should say Y here if you compile a kernel which - will run as a router and N for regular hosts. If unsure, say N. - -if NETFILTER - -config NETFILTER_DEBUG - bool "Network packet filtering debugging" - depends on NETFILTER - help - You can say Y here if you want to get additional messages useful in - debugging the netfilter code. - -config BRIDGE_NETFILTER - bool "Bridged IP/ARP packets filtering" - depends on BRIDGE && NETFILTER && INET - default y - ---help--- - Enabling this option will let arptables resp. iptables see bridged - ARP resp. IP traffic. If you want a bridging firewall, you probably - want this option enabled. - Enabling or disabling this option doesn't enable or disable - ebtables. - - If unsure, say N. - -source "net/ipv4/netfilter/Kconfig" -source "net/ipv6/netfilter/Kconfig" -source "net/decnet/netfilter/Kconfig" -source "net/bridge/netfilter/Kconfig" - -endif - -config XFRM - bool - depends on NET - -source "net/xfrm/Kconfig" - source "net/sctp/Kconfig" config ATM tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" depends on EXPERIMENTAL + depends on NET ---help--- ATM is a high-speed networking technology for Local Area Networks and Wide Area Networks. It uses a fixed packet size and is @@ -285,52 +313,9 @@ config ATM_BR2684_IPFILTER large number of IP-only vcc's. Do not enable this unless you are sure you know what you are doing. -config BRIDGE - tristate "802.1d Ethernet Bridging" - ---help--- - If you say Y here, then your Linux box will be able to act as an - Ethernet bridge, which means that the different Ethernet segments it - is connected to will appear as one Ethernet to the participants. - Several such bridges can work together to create even larger - networks of Ethernets using the IEEE 802.1 spanning tree algorithm. - As this is a standard, Linux bridges will cooperate properly with - other third party bridge products. - - In order to use the Ethernet bridge, you'll need the bridge - configuration tools; see - for location. Please read the Bridge mini-HOWTO for more - information. - - If you enable iptables support along with the bridge support then you - turn your bridge into a bridging IP firewall. - iptables will then see the IP packets being bridged, so you need to - take this into account when setting up your firewall rules. - Enabling arptables support when bridging will let arptables see - bridged ARP traffic in the arptables FORWARD chain. - - To compile this code as a module, choose M here: the module - will be called bridge. - - If unsure, say N. - -config VLAN_8021Q - tristate "802.1Q VLAN Support" - ---help--- - Select this and you will be able to create 802.1Q VLAN interfaces - on your ethernet interfaces. 802.1Q VLAN supports almost - everything a regular ethernet interface does, including - firewalling, bridging, and of course IP traffic. You will need - the 'vconfig' tool from the VLAN project in order to effectively - use VLANs. See the VLAN web page for more information: - - - To compile this code as a module, choose M here: the module - will be called 8021q. - - If unsure, say N. - config DECNET tristate "DECnet Support" + depends on NET ---help--- The DECnet networking protocol was used in many products made by Digital (now Compaq). It provides reliable stream and sequenced @@ -358,6 +343,7 @@ source "net/llc/Kconfig" config IPX tristate "The IPX protocol" + depends on NET select LLC ---help--- This is support for the Novell networking protocol, IPX, commonly @@ -393,6 +379,7 @@ source "net/ipx/Kconfig" config ATALK tristate "Appletalk protocol support" + depends on NET select LLC ---help--- AppleTalk is the protocol that Apple computers can use to communicate @@ -422,7 +409,7 @@ source "drivers/net/appletalk/Kconfig" config X25 tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" - depends on EXPERIMENTAL + depends on NET && EXPERIMENTAL ---help--- X.25 is a set of standardized network protocols, similar in scope to frame relay; the one physical line from your box to the X.25 network @@ -453,7 +440,7 @@ config X25 config LAPB tristate "LAPB Data Link Driver (EXPERIMENTAL)" - depends on EXPERIMENTAL + depends on NET && EXPERIMENTAL ---help--- Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. the lower) part of the X.25 protocol. It offers a reliable @@ -470,32 +457,6 @@ config LAPB To compile this driver as a module, choose M here: the module will be called lapb. If unsure, say N. -config NET_DIVERT - bool "Frame Diverter (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - The Frame Diverter allows you to divert packets from the - network, that are not aimed at the interface receiving it (in - promisc. mode). Typically, a Linux box setup as an Ethernet bridge - with the Frames Diverter on, can do some *really* transparent www - caching using a Squid proxy for example. - - This is very useful when you don't want to change your router's - config (or if you simply don't have access to it). - - The other possible usages of diverting Ethernet Frames are - numberous: - - reroute smtp traffic to another interface - - traffic-shape certain network streams - - transparently proxy smtp connections - - etc... - - For more informations, please refer to: - - - - If unsure, say N. - config ECONET tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" depends on EXPERIMENTAL && INET @@ -529,32 +490,109 @@ config ECONET_NATIVE Say Y here if you have a native Econet network card installed in your computer. -config WAN_ROUTER - tristate "WAN router" - depends on EXPERIMENTAL +source "net/ax25/Kconfig" + +source "net/irda/Kconfig" + +source "net/bluetooth/Kconfig" + +endmenu +# end options and protocols + +menuconfig NETFILTER + bool "Network packet filtering (replaces ipchains)" ---help--- - Wide Area Networks (WANs), such as X.25, frame relay and leased - lines, are used to interconnect Local Area Networks (LANs) over vast - distances with data transfer rates significantly higher than those - achievable with commonly used asynchronous modem connections. - Usually, a quite expensive external device called a `WAN router' is - needed to connect to a WAN. + Netfilter is a framework for filtering and mangling network packets + that pass through your Linux box. - As an alternative, WAN routing can be built into the Linux kernel. - With relatively inexpensive WAN interface cards available on the - market, a perfectly usable router can be built for less than half - the price of an external router. If you have one of those cards and - wish to use your Linux box as a WAN router, say Y here and also to - the WAN driver for your card, below. You will then need the - wan-tools package which is available from . - Read for more - information. + The most common use of packet filtering is to run your Linux box as + a firewall protecting a local network from the Internet. The type of + firewall provided by this kernel support is called a "packet + filter", which means that it can reject individual network packets + based on type, source, destination etc. The other kind of firewall, + a "proxy-based" one, is more secure but more intrusive and more + bothersome to set up; it inspects the network traffic much more + closely, modifies it and has knowledge about the higher level + protocols, which a packet filter lacks. Moreover, proxy-based + firewalls often require changes to the programs running on the local + clients. Proxy-based firewalls don't need support by the kernel, but + they are often combined with a packet filter, which only works if + you say Y here. - To compile WAN routing support as a module, choose M here: the - module will be called wanrouter. + You should also say Y here if you intend to use your Linux box as + the gateway to the Internet for a local network of machines without + globally valid IP addresses. This is called "masquerading": if one + of the computers on your local network wants to send something to + the outside, your box can "masquerade" as that computer, i.e. it + forwards the traffic to the intended outside destination, but + modifies the packets to make it look like they came from the + firewall box itself. It works both ways: if the outside host + replies, the Linux box will silently forward the traffic to the + correct local computer. This way, the computers on your local net + are completely invisible to the outside world, even though they can + reach the outside and can receive replies. It is even possible to + run globally visible servers from within a masqueraded local network + using a mechanism called portforwarding. Masquerading is also often + called NAT (Network Address Translation). + + Another use of Netfilter is in transparent proxying: if a machine on + the local network tries to connect to an outside host, your Linux + box can transparently forward the traffic to a local server, + typically a caching proxy server. + + Yet another use of Netfilter is building a bridging firewall. Using + a bridge with Network packet filtering enabled makes iptables "see" + the bridged traffic. For filtering on the lower network and Ethernet + protocols over the bridge, use ebtables (under bridge netfilter + configuration). + + Various modules exist for netfilter which replace the previous + masquerading (ipmasqadm), packet filtering (ipchains), transparent + proxying, and portforwarding mechanisms. Please see + under "iptables" for the location of + these packages. + + Make sure to say N to "Fast switching" below if you intend to say Y + here, as Fast switching currently bypasses netfilter. + + Chances are that you should say Y here if you compile a kernel which + will run as a router and N for regular hosts. If unsure, say N. + +if NETFILTER + +config NETFILTER_DEBUG + bool "Network packet filtering debugging" + depends on NETFILTER + help + You can say Y here if you want to get additional messages useful in + debugging the netfilter code. + +config BRIDGE_NETFILTER + bool "Bridged IP/ARP packets filtering" + depends on BRIDGE && NETFILTER && INET + default y + ---help--- + Enabling this option will let arptables resp. iptables see bridged + ARP resp. IP traffic. If you want a bridging firewall, you probably + want this option enabled. + Enabling or disabling this option doesn't enable or disable + ebtables. If unsure, say N. +source "net/ipv4/netfilter/Kconfig" +source "net/ipv6/netfilter/Kconfig" +source "net/decnet/netfilter/Kconfig" +source "net/bridge/netfilter/Kconfig" + +endif +# NETFILTER + +config XFRM + bool + +source "net/xfrm/Kconfig" + menu "QoS and/or fair queueing" config NET_SCHED @@ -596,12 +634,14 @@ config NET_SCHED source "net/sched/Kconfig" endmenu +# end SCHED menu "Network testing" config NET_PKTGEN tristate "Packet Generator (USE WITH CAUTION)" depends on PROC_FS + depends on INET ---help--- This module will inject preconfigured packets, at a configurable rate, out of a given interface. It is used for network interface @@ -615,32 +655,8 @@ config NET_PKTGEN module will be called pktgen. endmenu +# end PKTGEN endmenu - -config NETPOLL - def_bool NETCONSOLE - -config NETPOLL_RX - bool "Netpoll support for trapping incoming packets" - default n - depends on NETPOLL - -config NETPOLL_TRAP - bool "Netpoll traffic trapping" - default n - depends on NETPOLL - -config NET_POLL_CONTROLLER - def_bool NETPOLL - -source "net/ax25/Kconfig" - -source "net/irda/Kconfig" - -source "net/bluetooth/Kconfig" - -source "drivers/net/Kconfig" - -endmenu +# end top support: options and protocols --------------000906010009010506010105-- From kaber@trash.net Sun Apr 3 20:48:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 20:48:24 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j343mKUl014581 for ; Sun, 3 Apr 2005 20:48:20 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DIIYy-0005CP-Iw; Mon, 04 Apr 2005 05:47:44 +0200 Date: Mon, 4 Apr 2005 05:47:44 +0200 (CEST) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: Herbert Xu cc: "David S. Miller" , netdev Subject: Re: [IPSEC]: Protect against BHs in xfrm_user_policy() In-Reply-To: <20050404012040.GA16960@gondor.apana.org.au> Message-ID: References: <4250160D.2040405@trash.net> <20050404012040.GA16960@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev On Mon, 4 Apr 2005, Herbert Xu wrote: > We want the same thing for km_query, no? In all other places were BHs are not explicitly disabled but need to be they are already disabled by the caller, so I left them as they are. Regards Patrick From herbert@gondor.apana.org.au Sun Apr 3 21:06:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 21:07:04 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3446tgB015823 for ; Sun, 3 Apr 2005 21:06:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIIr8-0000HZ-00; Mon, 04 Apr 2005 14:06:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIIqh-0004h8-00; Mon, 04 Apr 2005 14:06:03 +1000 Date: Mon, 4 Apr 2005 14:06:03 +1000 To: Patrick McHardy Cc: "David S. Miller" , netdev Subject: Re: [IPSEC]: Protect against BHs in xfrm_user_policy() Message-ID: <20050404040603.GA18025@gondor.apana.org.au> References: <4250160D.2040405@trash.net> <20050404012040.GA16960@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 05:47:44AM +0200, Patrick McHardy wrote: > On Mon, 4 Apr 2005, Herbert Xu wrote: > >We want the same thing for km_query, no? > > In all other places were BHs are not explicitly disabled > but need to be they are already disabled by the caller, > so I left them as they are. Yes you're right. I missed the spin_lock_bh in xfrm_state_find. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From abhishek@pal.ece.iisc.ernet.in Sun Apr 3 21:27:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 21:27:25 -0700 (PDT) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j344REcR017115 for ; Sun, 3 Apr 2005 21:27:17 -0700 Received: from pal.ece.iisc.ernet.in (pal.ece.iisc.ernet.in [144.16.64.149]) by ece.iisc.ernet.in (8.12.6/8.12.6) with ESMTP id j344OY8V092139; Mon, 4 Apr 2005 09:54:39 +0530 (IST) (envelope-from abhishek@pal.ece.iisc.ernet.in) Received: by pal.ece.iisc.ernet.in (Postfix, from userid 1047) id 46E2031E59; Mon, 4 Apr 2005 09:56:49 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by pal.ece.iisc.ernet.in (Postfix) with ESMTP id 337DA31E57; Mon, 4 Apr 2005 09:56:49 +0530 (IST) Date: Mon, 4 Apr 2005 09:56:49 +0530 (IST) From: Abhishek Gupta To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Multiple REDs per Queue In-Reply-To: <20050403194739.GR3086@postel.suug.ch> Message-ID: References: <20050402213642.GO3086@postel.suug.ch> <20050403194739.GR3086@postel.suug.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abhishek@pal.ece.iisc.ernet.in Precedence: bulk X-list: netdev Hello Once again thanks Mr. Graf. I have changed my UDP packet generator to Linux's pktgen which generates UDP packets at very high speed and also at constant rate. Things are now working quite well. Thanks for letting me know about the bmon software. Its a great software and is helping me a lot in my work. I have something more to ask. The problem goes as follows: In my project I want to use multiple REDs per queue i.e, in a queue, various tcps(persistent, non-persistent etc) will be operated with different RED parameters(min and max threshold, beta, pmax etc) but operate on same queue length and not on individual queue lengths(including average queue length). Is it possible with linux's tc option to have multiple REDs per queue. As far as I could able to understand, linux tc option provides only one RED per queue. If it is not possible with tc option, then where I need to make changes in source code to achieve the forementioned set-up. Thanks. abhishek ========================================================================= ABHISHEK GUPTA E-mail:abhishek_it_bhu@yahoo.co.in ========================================================================= On Sun, 3 Apr 2005, Thomas Graf wrote: > * Abhishek Gupta 2005-04-03 20:30 > > But the problem is still > > not yet solved as I tried with 1Mbit speed as the setting for link speed > > in the htb configuration and got about 30KBps which amounts to about > > 240Kbitps even though my UDP source is sending at speed of about > > 1MBps(8Mbps), according to RH monitor readings. > > I do not know about that "RH monitor" you are referring to, maybe it > does not display rates correctly. (I found 3 out of 5 rate estimators > outputing with a variance of over 10%) I can recommend you bmon [0] > which states the variance and can be used to a resolution up to > 1/100s given the input source provides an equal or better resolution. > > > Is it possible that the problem is due to the source that I am using for > > UDP packets? > > Very likely, especially due to the huge difference in requested and > achieved rate you have mentioned above. I hardly think this is a > problem related to HTB but rather some misconfiguration in your testing > process. > > [0] http://people.suug.ch/~tgr/bmon/ > From laforge@gnumonks.org Sun Apr 3 22:26:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 22:26:53 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j345QloE020353 for ; Sun, 3 Apr 2005 22:26:48 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DIK6l-0004in-Ey; Mon, 04 Apr 2005 07:26:43 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DIK6k-0003oz-JB; Mon, 04 Apr 2005 07:26:42 +0200 Date: Mon, 4 Apr 2005 07:26:42 +0200 From: Harald Welte To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: pktgen problem (skb refcount) in 2.6.12-rc1 Message-ID: <20050404052642.GE9155@sunbeam.de.gnumonks.org> References: <20050402191132.GF1890@sunbeam.de.gnumonks.org> <16976.16774.728707.368646@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <16976.16774.728707.368646@robur.slu.se> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 03, 2005 at 09:18:30PM +0200, Robert Olsson wrote: > > I've tried to track the problem down, and I've confirmed that skb->use= rs > > never goes down to 1 but instead stays at '2'. >=20 > > The same system with the same pktgen script works fine with 2.6.11.6. > >=20 > > I'm reporting this since it seems like it sounds like we have a skb > > usage count leak somewhere :( >=20 > Sounds like a diff could give some clues. pktgen, e1000 and TX-path shou= ld=20 > be interesting as ev. changes in kernel config. no changes in kernel config. I've reviewed pktgen changes and couldn't find something that would cause the problem. It always only atomic_inc'ed the ussage cound (and decrements only in error path) which is perfectly fine. As for e1000 and or generic TX path changes, I don't have the time to review them now, sorry :( That's why I posted it to netdev, to let people who have an idea about the committed changes know that there is an issue. Cheers, Harald --=20 - Harald Welte http://gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCUNASXaXGVTD0i/8RAmJlAJ0am9/hoqAXladQcKHHELjDXiSCAwCgk6KQ p4zfJVUew9dckCSBh1Fg84g= =3nOl -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From grundler@lackof.org Sun Apr 3 23:29:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 23:29:24 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j346TJHK023049 for ; Sun, 3 Apr 2005 23:29:19 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 1D7D229802F; Mon, 4 Apr 2005 00:31:11 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30848-01; Mon, 4 Apr 2005 00:31:09 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 9F704298010; Mon, 4 Apr 2005 00:31:09 -0600 (MDT) Date: Mon, 4 Apr 2005 00:31:09 -0600 From: Grant Grundler To: Dmitry Yusupov Cc: "open-iscsi@googlegroups.com" , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Message-ID: <20050404063109.GA30855@colo.lackof.org> References: <20050324233921.GZ14202@opteron.random> <20050325034341.GV32638@waste.org> <20050327035149.GD4053@g5.random> <20050327054831.GA15453@waste.org> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@davemloft.net> <52vf7bwo4w.fsf@topspin.com> <1112042936.5088.22.camel@beastie> <20050328223203.GC28983@kvack.org> <1112465317.24936.10.camel@mylaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112465317.24936.10.camel@mylaptop> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev On Sat, Apr 02, 2005 at 10:08:37AM -0800, Dmitry Yusupov wrote: > So, who cares if one of those cores will do receive side copying? It burns backplane bandwidth that could be used for other things. The problem isn't the CPU cycles. It's the number of times the data has to cross the memory bus. grant From grundler@lackof.org Sun Apr 3 23:33:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Apr 2005 23:33:10 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j346X5v0023682 for ; Sun, 3 Apr 2005 23:33:05 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id F40F629802F; Mon, 4 Apr 2005 00:34:57 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30514-10; Mon, 4 Apr 2005 00:34:57 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id 8C3CA298010; Mon, 4 Apr 2005 00:34:56 -0600 (MDT) Date: Mon, 4 Apr 2005 00:34:56 -0600 From: Grant Grundler To: Dmitry Yusupov Cc: "open-iscsi@googlegroups.com" , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050404063456.GB30855@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112576171.4227.5.camel@mylaptop> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 05:56:11PM -0700, Dmitry Yusupov wrote: > I do not get your concern with memory BW. With good AMD box V40Z(SUN) > you can get 5.3GBytes/sec. Even with 10Gbps full speed you have 80% > left. PCI-X BUS BW is bigger concern... Yes and No. PCI-X isn't fast enough but the data only crosses the PCI-X bus once. Think about the data flow: 1) DMA to RAM 2) load into CPU cache 3) store back into RAM We are down to 40% left...graphics folks won't like you. grant From davem@davemloft.net Mon Apr 4 00:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 00:11:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j347B8Ld026309 for ; Mon, 4 Apr 2005 00:11:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DILii-0000Pi-00; Mon, 04 Apr 2005 00:10:00 -0700 Date: Mon, 4 Apr 2005 00:10:00 -0700 From: "David S. Miller" To: Grant Grundler Cc: dmitry_yus@yahoo.com, open-iscsi@googlegroups.com, mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-Id: <20050404001000.5fa8f206.davem@davemloft.net> In-Reply-To: <20050404063456.GB30855@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 4 Apr 2005 00:34:56 -0600 Grant Grundler wrote: > Yes and No. PCI-X isn't fast enough but the data only crosses > the PCI-X bus once. Think about the data flow: > 1) DMA to RAM > 2) load into CPU cache > 3) store back into RAM > > We are down to 40% left...graphics folks won't like you. But you're missing the point, which is that the memory system always catches up to the networking technology. We'll have that %60 back before you know it when we have PCI-Z and DDR8 or whatever even in $500.00USD desktop machines. And those systems will be present by the time we put together this complicated infrastructure for RDMA. RDMA is like cache coloring page allocators, it's for yesterday's technology that we won't be using tomorrow. :-) Those steps #2 and #3 in your data flow are powerful, it is what gives us flexibility. And in a general purpose OS that is important. From Robert.Olsson@data.slu.se Mon Apr 4 03:28:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 03:28:22 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34ASGSS015432 for ; Mon, 4 Apr 2005 03:28:17 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j34ARhdR021531; Mon, 4 Apr 2005 12:27:43 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 63C1EEE2B1; Mon, 4 Apr 2005 12:27:43 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.5791.367581.655483@robur.slu.se> Date: Mon, 4 Apr 2005 12:27:43 +0200 To: Herbert Xu Cc: Robert Olsson , "David S. Miller" , dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050403214521.GB15901@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> <20050403074337.GA8083@gondor.apana.org.au> <16976.19092.562006.246545@robur.slu.se> <20050403214521.GB15901@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1331 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 Herbert Xu writes: > The reason I'm suggesting the move to a kernel thread is because > softirq context is not preemptible. > > So doing a large amount of work in it when your table is big means > that a UP machine will freeze for a while. The flush transient will happen also on UP... as I understand this When we have changed the rt_hash_rnd and therefore invalidated all current entries it would be best to blackhole *all* traffic until all old entries are deleted this to avoid transients. --ro From Robert.Olsson@data.slu.se Mon Apr 4 03:38:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 03:38:42 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34AcWoY016376 for ; Mon, 4 Apr 2005 03:38:33 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j34Ac3Ng023049; Mon, 4 Apr 2005 12:38:03 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6E27EEE2B1; Mon, 4 Apr 2005 12:38:03 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.6411.415326.988754@robur.slu.se> Date: Mon, 4 Apr 2005 12:38:03 +0200 To: Herbert Xu Cc: Robert Olsson , Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050403214358.GA15901@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <16976.17876.832677.945878@robur.slu.se> <20050403214358.GA15901@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1332 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 Herbert Xu writes: > The only way to attack a hash is by exploiting collisions and > create one or more excessively long chains. > > This can be detected as follows at each rt hash insertion. If > > (total number of entries in cache >> (hash length - user defined length)) < > current bucket length > > is true, then we schedule a rehash/flush. > > Hash length is the number of bits in the hash, i.e., > > 1 << hash length == number of buckets > > I'd suggest a default shift length of 3. That is, if any individual > chain is growing beyond 8 times the average chain length then we've > got a problem. This is likely to happen in rt_intern_hash? I don't see how this can get along with chain-pruning there? IMO the thoughts of extending in-flow GC etc are interesting and can hopefully give us more robust performance. --ro From herbert@gondor.apana.org.au Mon Apr 4 03:39:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 03:39:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34AdNef016627 for ; Mon, 4 Apr 2005 03:39:24 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIOyp-0002Cm-00; Mon, 04 Apr 2005 20:38:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIOyE-0008PA-00; Mon, 04 Apr 2005 20:38:14 +1000 Date: Mon, 4 Apr 2005 20:38:14 +1000 To: Robert Olsson Cc: "David S. Miller" , dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050404103814.GA32269@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> <20050403074337.GA8083@gondor.apana.org.au> <16976.19092.562006.246545@robur.slu.se> <20050403214521.GB15901@gondor.apana.org.au> <16977.5791.367581.655483@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16977.5791.367581.655483@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 12:27:43PM +0200, Robert Olsson wrote: > > The flush transient will happen also on UP... as I understand this > When we have changed the rt_hash_rnd and therefore invalidated all current > entries it would be best to blackhole *all* traffic until all old entries > are deleted this to avoid transients. That's nasty because if you have a large cache like Eric, then you'll be dropping packets for quite a while :) Actually, what's so bad about seeing transients? One cost that I can see is that you'll be walking a chain only to conclude that none of the entries might match. But this is pretty cheap as long as we keep the chain lengths short. The other cost is that we might be creating an entry that gets flushed straight away. However, that's no worse than not using the cache at all since in that case we'll be creating one entry for each packet anyway. Both of these can be avoided too if we really cared. All we need is one bit per chain that indicated whether it's been flushed. So when ip_route_* hits a chain that hasn't been flushed, it could 1) Skip the lookup step. 2) Create the rt entry as usual. 3) Flush the chain while we insert the entry and set the bit. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Apr 4 03:49:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 03:49:55 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34AngJH017952 for ; Mon, 4 Apr 2005 03:49:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIP8r-0002Fr-00; Mon, 04 Apr 2005 20:49:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIP8b-0008Qf-00; Mon, 04 Apr 2005 20:48:57 +1000 Date: Mon, 4 Apr 2005 20:48:57 +1000 To: Robert Olsson Cc: Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-ID: <20050404104857.GA32359@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <16976.17876.832677.945878@robur.slu.se> <20050403214358.GA15901@gondor.apana.org.au> <16977.6411.415326.988754@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16977.6411.415326.988754@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 12:38:03PM +0200, Robert Olsson wrote: > > This is likely to happen in rt_intern_hash? I don't see how this can > get along with chain-pruning there? What I'm trying to catch is the case when you've got x number of entries in the table and a large fraction of them are all in one chain. This does not conflict with the goal of keeping the chains short. Even if you strictly allow only 8 entries per chain, it's trivial to exceed 8 times the average chain length. Remember the average chain length can be fractions like 0.1. Of course we need to set a minimum value that the chain needs to grow beyond before this check kicks in. > IMO the thoughts of extending in-flow GC etc are interesting and can > hopefully give us more robust performance. Indeed, it looks like Alexey has already put the code there. It just needs to be made more strict :) It needs to free entries even if they are in use. After all, freeing an entry in use can't be much worse than not having a cache at all. OTOH, having a very long chain is definitely much worse than not having a cache :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mike@codeweavers.com Mon Apr 4 03:52:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 03:52:51 -0700 (PDT) Received: from mail.codeweavers.com (Debian-exim@mail.codeweavers.com [216.251.189.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34AqhYX018579 for ; Mon, 4 Apr 2005 03:52:44 -0700 Received: from foghorn.codeweavers.com ([216.251.189.130] helo=[127.0.0.1]) by mail.codeweavers.com with esmtp (Exim 4.34) id 1DIPC8-0004jR-Cg for netdev@oss.sgi.com; Mon, 04 Apr 2005 05:52:42 -0500 Message-ID: <42511C31.3090801@codeweavers.com> Date: Mon, 04 Apr 2005 19:51:29 +0900 From: Mike McCormack Organization: Codeweavers User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041221 X-Accept-Language: en, en-us MIME-Version: 1.0 To: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="------------040700050107080907080805" X-SA-Exim-Connect-IP: 216.251.189.130 X-SA-Exim-Mail-From: mike@codeweavers.com Subject: Patch to count the number of datagrams in a unix domain socket X-SA-Exim-Version: 4.2 (built Tue, 25 Jan 2005 19:36:50 +0100) X-SA-Exim-Scanned: Yes (on mail.codeweavers.com) X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mike@codeweavers.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040700050107080907080805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I trying to implement mailslot support in Wine, and have come across a small problem that isn't easy to solve. My implementation [1] uses a unix domain socket in dgram mode. The Win32 function GetMailslotInfo [2] allows a program to fetch the number of messages waiting in the mailslot. In my implementation, that is the number of datagrams waiting in the socket. In Linux 2.6.11 there is no way to count the the number of datagrams in a socket without reading them all out, one by one. I have attached a small patch that lets me read the number of datagrams in a socket, and makes GetMailslotInfo work in my test case [3]. Questions: Do people thing this is something useful to add to the kernel? What's the right way to assign a value for SIOCINCOUNT, and in which header? Is SIOCDGRAMCOUNT or something else a better name? Should the return value of SIOCINCOUNT for a non-dgram socket be different? If I add this ioctl() for unix domain sockets, should other sockets be made to work the same way? thanks, Mike [1] http://cvs.winehq.org/cvsweb/wine/server/mailslot.c [2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/getmailslotinfo.asp [3] http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/mailslot.c --------------040700050107080907080805 Content-Type: text/x-patch; name="siocincount.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="siocincount.diff" --- linux-2.6.11-orig/net/unix/af_unix.c 2005-03-02 16:38:12.000000000 +0900 +++ linux-2.6.11/net/unix/af_unix.c 2005-04-03 16:36:52.000000000 +0900 @@ -1838,6 +1838,7 @@ static int unix_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) { struct sock *sk = sock->sk; + struct sk_buff *skb; long amount=0; int err; @@ -1848,8 +1849,6 @@ err = put_user(amount, (int __user *)arg); break; case SIOCINQ: - { - struct sk_buff *skb; if (sk->sk_state == TCP_LISTEN) { err = -EINVAL; @@ -1869,8 +1868,21 @@ spin_unlock(&sk->sk_receive_queue.lock); err = put_user(amount, (int __user *)arg); break; - } +#define SIOCINCOUNT 0x8907 + case SIOCINCOUNT: + /* count the number of packets waiting */ + if (sk->sk_state == TCP_LISTEN) { + err = -EINVAL; + break; + } + + spin_lock(&sk->sk_receive_queue.lock); + skb_queue_walk(&sk->sk_receive_queue, skb) + amount++; + spin_unlock(&sk->sk_receive_queue.lock); + err = put_user(amount, (int __user *)arg); + break; default: err = dev_ioctl(cmd, (void __user *)arg); break; --------------040700050107080907080805-- From akpm@osdl.org Mon Apr 4 04:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 04:18:55 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34BIk8m020289 for ; Mon, 4 Apr 2005 04:18:46 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j34BIcs4019225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Apr 2005 04:18:39 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j34BIbvl007759; Mon, 4 Apr 2005 04:18:38 -0700 Date: Mon, 4 Apr 2005 04:18:22 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: dcmwai@pl.jaring.my Subject: Fw: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan Message-Id: <20050404041822.2ea0c16a.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j34BIk8m020289 X-archive-position: 1336 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 Begin forwarded message: Date: Mon, 4 Apr 2005 04:15:25 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan http://bugme.osdl.org/show_bug.cgi?id=4441 Summary: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan Kernel Version: 2.6.11-gentoo-r4 i686 Status: NEW Severity: high Owner: acme@conectiva.com.br Submitter: dcmwai@pl.jaring.my Distribution: Gentoo, FC2, FC3 Hardware Environment: Pentium 4 3.0E, Intel SE7210TP1-E Server Entry Board 512 MB DDR Ram 2x Intel® PRO/1000 Dual Port Adapters Software Environment: Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1) Fc2 and Fc2 original kernel. Problem Description: When Shutdown a Vlan using this command vconfig rem eth4.1001 The interface will be down (using ifconfig) However the following error will be prompt on the screen and the log leaving the shell to be not responding. Even if "ifconfig eth4.1001 down" is run before "vconfig rem" sill the problem will be there. The only way I tested on solve this problem is to shutdown the interface totally. ifconfig eth4 down Then the vlan can be removed correctly. This problem don't happen on the following "special Condition" 1) On another motherboard (Gigabyte GA-81PE1000-G) same NIC on Fc3 1) On eth0 Steps to reproduce: 1. get a vlan supported NIC, emerge vconfig 2. ifconfig ethx 0.0.0.0 3. create a vlan using "vconfig add ethx nnnn" 4. ifconfig ethx.nnnn aaa.bbb.ccc.ddd 5. remove the vlan using "vconfig rem ethx.nnnn" 6. Wait for the error like the below. * Motherboard and NIC seem to be a Problem in my case. unregister_netdevice: waiting for ethx.nnnn to become free. Usage count = 6 I've also open a bug in Gentoo http://bugs.gentoo.org/show_bug.cgi?id=87495 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From hadi@cyberus.ca Mon Apr 4 04:38:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 04:38:56 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34BceGb024867 for ; Mon, 4 Apr 2005 04:38:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DIPuc-0007dK-Gw for netdev@oss.sgi.com; Mon, 04 Apr 2005 05:38:34 -0600 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIPuX-00042B-BN; Mon, 04 Apr 2005 07:38:29 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404005805.GA16543@gondor.apana.org.au> References: <1112353398.1096.116.camel@jzny.localdomain> <20050401114258.GA2932@gondor.apana.org.au> <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-udwTmEebwhkzoeZTJYHN" Organization: jamalopolous Message-Id: <1112614706.1096.439.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 07:38:26 -0400 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1337 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 --=-udwTmEebwhkzoeZTJYHN Content-Type: text/plain Content-Transfer-Encoding: 7bit Herbert! Ok, heres an update. cheers, jamal --=-udwTmEebwhkzoeZTJYHN Content-Disposition: attachment; filename=ipsec-event-take2-2 Content-Type: text/plain; name=ipsec-event-take2-2; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 +++ b/include/net/xfrm.h 2005-04-02 11:59:17.000000000 -0500 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -802,7 +827,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-25 22:28:39.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-02 09:53:03.000000000 -0500 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-03-25 22:28:25.000000000 -0500 +++ b/net/xfrm/xfrm_state.c 2005-04-04 07:35:03.000000000 -0400 @@ -40,6 +40,8 @@ DECLARE_WAIT_QUEUE_HEAD(km_waitq); EXPORT_SYMBOL(km_waitq); +static DEFINE_RWLOCK(xfrm_km_lock); +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); static DEFINE_RWLOCK(xfrm_state_afinfo_lock); static struct xfrm_state_afinfo *xfrm_state_afinfo[NPROTO]; @@ -48,13 +50,15 @@ static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); static DEFINE_SPINLOCK(xfrm_state_gc_lock); -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol); static void km_state_expired(struct xfrm_state *x, int hard); +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +void km_state_notify(struct xfrm_state *x, struct km_event *c); static void xfrm_state_gc_destroy(struct xfrm_state *x) { @@ -208,8 +212,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -236,14 +242,21 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +int xfrm_state_delete(struct xfrm_state *x) { + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -402,6 +415,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -764,37 +778,60 @@ } EXPORT_SYMBOL(xfrm_replay_advance); -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); -static DEFINE_RWLOCK(xfrm_km_lock); -static void km_state_expired(struct xfrm_state *x, int hard) +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_mgr *km; + + read_lock_bh(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock_bh(&xfrm_km_lock); +} + +void km_state_notify(struct xfrm_state *x, struct km_event *c) { struct xfrm_mgr *km; + read_lock_bh(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + km->notify(x, c); + read_unlock_bh(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +static void km_state_expired(struct xfrm_state *x, int hard) +{ + struct km_event c; if (hard) x->km.state = XFRM_STATE_EXPIRED; else x->km.dying = 1; - - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -819,13 +856,12 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-04 07:23:31.000000000 -0400 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -285,14 +286,28 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + xfrm_state_hold(x); + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + xfrm_state_put(x); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +319,19 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -672,6 +696,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +708,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +719,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +846,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +875,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +889,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1112,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1129,107 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + if (x->aalg) + RTA_PUT(skb, XFRMA_ALG_AUTH, + sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8, x->aalg); + if (x->ealg) + RTA_PUT(skb, XFRMA_ALG_CRYPT, + sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8, x->ealg); + if (x->calg) + RTA_PUT(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg); + + if (x->encap) + RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: +rtattr_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1363,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1375,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1383,92 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + if (copy_to_user_tmpl(xp, skb) < 0) + goto nlmsg_failure; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("Netlink Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-03-25 22:28:39.000000000 -0500 +++ b/net/key/af_key.c 2005-04-04 07:20:12.000000000 -0400 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1265,27 +1337,24 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + xfrm_state_hold(x); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1370,19 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1520,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + hdr->sadb_msg_satype = pfkey_proto2satype(c->data); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1948,35 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + + if (c->data && c->event == XFRM_SAP_DELETED) + out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; + else + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1984,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2052,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2084,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,25 +2120,41 @@ err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + + xfrm_pol_put(xp); + return err; +} + + +static int key_pol_get_resp(struct sock *sk, struct xfrm_policy *xp, struct sadb_msg *hdr, int dir) +{ + int err; + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + err = 0; + out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); goto out; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + pfkey_xfrm_policy2msg(out_skb, xp, dir); out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; + out_hdr->sadb_msg_type = hdr->sadb_msg_type; out_hdr->sadb_msg_satype = 0; out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ONE, sk); err = 0; out: - xfrm_pol_put(xp); return err; } @@ -2037,8 +2163,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2175,16 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.data = 1; // to signal pfkey of SADB_X_SPDDELETE2 + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + } else { + err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2219,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2445,25 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + printk("pfkey doesnt deal with expired policies ..\n"); + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2482,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3035,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-udwTmEebwhkzoeZTJYHN-- From Robert.Olsson@data.slu.se Mon Apr 4 04:41:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 04:41:36 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34BfUkF025381 for ; Mon, 4 Apr 2005 04:41:31 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j34BfRUL001667; Mon, 4 Apr 2005 13:41:28 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id C0252EE2B1; Mon, 4 Apr 2005 13:41:27 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.10215.725020.64329@robur.slu.se> Date: Mon, 4 Apr 2005 13:41:27 +0200 To: Harald Welte Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: pktgen problem (skb refcount) in 2.6.12-rc1 In-Reply-To: <20050404052642.GE9155@sunbeam.de.gnumonks.org> References: <20050402191132.GF1890@sunbeam.de.gnumonks.org> <16976.16774.728707.368646@robur.slu.se> <20050404052642.GE9155@sunbeam.de.gnumonks.org> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1338 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 Harald Welte writes: Hello! >>> I've tried to track the problem down, and I've confirmed that skb->users >>> never goes down to 1 but instead stays at '2'. > no changes in kernel config. I've reviewed pktgen changes and couldn't > find something that would cause the problem. It always only > atomic_inc'ed the ussage cound (and decrements only in error path) which > is perfectly fine. OK! Thanks. > As for e1000 and or generic TX path changes, I don't have the time to > review them now, sorry :( That's why I posted it to netdev, to let > people who have an idea about the committed changes know that there is > an issue. Well if it's skb leak it will be seen. --ro From herbert@gondor.apana.org.au Mon Apr 4 04:56:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 04:56:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Bu16S026414 for ; Mon, 4 Apr 2005 04:56:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIQB5-0002ha-00; Mon, 04 Apr 2005 21:55:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIQAe-0003Am-00; Mon, 04 Apr 2005 21:55:08 +1000 Date: Mon, 4 Apr 2005 21:55:08 +1000 To: Patrick McHardy Cc: "David S. Miller" , netdev Subject: Re: [IPSEC]: Protect against BHs in xfrm_user_policy() Message-ID: <20050404115508.GA12171@gondor.apana.org.au> References: <4250160D.2040405@trash.net> <20050404012040.GA16960@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050404012040.GA16960@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 11:20:40AM +1000, herbert wrote: > On Sun, Apr 03, 2005 at 06:13:01PM +0200, Patrick McHardy wrote: > > > > # This is a BitKeeper generated diff -Nru style patch. > > # > > # ChangeSet > > # 2005/04/03 17:36:10+02:00 kaber@coreworks.de > > # [IPSEC]: Protect against BHs in xfrm_user_policy() > > # > > # Signed-off-by: Patrick McHardy > > Looks good. > > Signed-off-by: Herbert Xu Actually, I now think this patch is unnecessary for mainline. The read_lock()'s only need to be protected from the write_lock()'s. Since all the write_lock()'s are made in process context, we don't need to disable BH on the read_lock()'s. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Apr 4 05:18:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:18:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CIVUP032473 for ; Mon, 4 Apr 2005 05:18:32 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIQWj-0002qA-00; Mon, 04 Apr 2005 22:17:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIQVV-0003Cn-00; Mon, 04 Apr 2005 22:16:41 +1000 Date: Mon, 4 Apr 2005 22:16:41 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404121641.GA12103@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112614706.1096.439.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Hi Jamal: On Mon, Apr 04, 2005 at 07:38:26AM -0400, jamal wrote: > Ok, heres an update. Great! White space comments only this time, almost :) > @@ -48,13 +50,15 @@ > static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); > static DEFINE_SPINLOCK(xfrm_state_gc_lock); > > -static void __xfrm_state_delete(struct xfrm_state *x); > +static int __xfrm_state_delete(struct xfrm_state *x); > > static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); > static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); > > static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol); > static void km_state_expired(struct xfrm_state *x, int hard); > +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); > +void km_state_notify(struct xfrm_state *x, struct km_event *c); No need for these prototypes since they're already in xfrm.h. > @@ -764,37 +778,60 @@ > } > EXPORT_SYMBOL(xfrm_replay_advance); > > -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > -static DEFINE_RWLOCK(xfrm_km_lock); How about letting these guys stay where they are? The move was necessary before because the km_*_notify functions had to be called in this file but that's no longer the case. > --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 > +++ b/net/xfrm/xfrm_user.c 2005-04-04 07:23:31.000000000 -0400 > @@ -268,6 +268,7 @@ > struct xfrm_usersa_info *p = NLMSG_DATA(nlh); > struct xfrm_state *x; > int err; > + struct km_event c; > > err = verify_newsa_info(p, (struct rtattr **) xfrma); > if (err) > @@ -285,14 +286,28 @@ > if (err < 0) { > x->km.state = XFRM_STATE_DEAD; > xfrm_state_put(x); > + return err; > } > > + xfrm_state_hold(x); Sorry, you need to hold x before the call to xfrm_state_add/xfrm_state_update as otherwise they can cause x to be freed. In general hold/put is only useful if 1) When you call hold you already have a reference to the object. 2) In between the hold/put you may free the object. > static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) > { > - struct sk_buff *out_skb; > - struct sadb_msg *out_hdr; > struct xfrm_state *x; > int err; > + struct km_event c; > > xfrm_probe_algs(); ... > - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); > + xfrm_state_hold(x); Same problem as xfrm_user. We need the hold to occur before the add/update for it to be effective. In fact the original code was buggy too since it didn't hold a reference at all. Of course this is very unlikely to crash since it requires a small life time and some bad luck in getting preempted. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Robert.Olsson@data.slu.se Mon Apr 4 05:30:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:30:12 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CU6WN006631 for ; Mon, 4 Apr 2005 05:30:07 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j34CTXkU009764; Mon, 4 Apr 2005 14:29:33 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6D233EE2B1; Mon, 4 Apr 2005 14:29:33 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.13101.410241.382741@robur.slu.se> Date: Mon, 4 Apr 2005 14:29:33 +0200 To: Herbert Xu Cc: Robert Olsson , "David S. Miller" , dada1@cosmosbay.com, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050404103814.GA32269@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <20050402115528.11f71a3c.davem@davemloft.net> <20050403074337.GA8083@gondor.apana.org.au> <16976.19092.562006.246545@robur.slu.se> <20050403214521.GB15901@gondor.apana.org.au> <16977.5791.367581.655483@robur.slu.se> <20050404103814.GA32269@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1341 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 Herbert Xu writes: > That's nasty because if you have a large cache like Eric, then you'll > be dropping packets for quite a while :) > > Actually, what's so bad about seeing transients? One cost that > I can see is that you'll be walking a chain only to conclude that > none of the entries might match. But this is pretty cheap as long as > we keep the chain lengths short. > > The other cost is that we might be creating an entry that gets flushed > straight away. However, that's no worse than not using the cache at > all since in that case we'll be creating one entry for each packet > anyway. Maybe you're right and systems seems to survive. But the transit period should be as short as possible. > Both of these can be avoided too if we really cared. All we need > is one bit per chain that indicated whether it's been flushed. So > when ip_route_* hits a chain that hasn't been flushed, it could > > 1) Skip the lookup step. > 2) Create the rt entry as usual. > 3) Flush the chain while we insert the entry and set the bit. Yes better was thinking of something like this too. --ro From hadi@cyberus.ca Mon Apr 4 05:33:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:33:40 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CXZUv007318 for ; Mon, 4 Apr 2005 05:33:35 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DIQll-0005Fw-Fc for netdev@oss.sgi.com; Mon, 04 Apr 2005 06:33:29 -0600 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIQlm-0001Lo-Mc; Mon, 04 Apr 2005 08:33:30 -0400 Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Aidas Kasparas Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org In-Reply-To: <425067D9.9050603@gmc.lt> References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> <1112538566.1096.391.camel@jzny.localdomain> <425067D9.9050603@gmc.lt> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112618007.1096.465.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 08:33:27 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1342 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, 2005-04-03 at 18:02, Aidas Kasparas wrote: > jamal wrote: [..] > > As an example, if the first pfkey user was just doing "setkey -x" and > > the second was infact pluto, then pluto will never see the > > acquire. This is what got me looking at it to begin with. Look at the > > earlier postings on the subject. > > While I agree that code before your patch would not allow to cooperate > tools using different ways to manage SAD/SPD (pfkey vs netlink), I have > one setup in production where two instances of racoon runs > simultaneously and both gets required pfkey-messages. > yes, multiple instances of the same socket type would work. Try running "ip xfrm mon" and your two racoon instances and see what happens;-> Anyways this will be fixed in upcoming kernels. > > So in other words, just killing the ike server as you propose would mean > > the kernel has no open sockets and will therefore never bother to send > > an acquire. > > I proposed to stop KE server, not to kill it. > The goal is: An acquire that the kernel thinks it sent successfuly in order to update a SA larval state never made it. To simulate this, it doesnt matter whether it happened in kernel-user space boundary or afterwards. The simple observation to make is: the kernel thinks the desired objective has been reached when it was not and from the little investigation conclude the kernel did not try to reliably deliver the message. > > > > Still all this is moot and is distracting us from the main discussion. > > Lets define "lost" simply as the case where an acquire never got to the > > server (which may be sitting elsewhere on the network). > > ACQUIREs _never_ _leaves_ _the box_ they are generated. It is allways > kernel-to-userspace_process communication. It could be made reliable. > And present situation IS sufficiently reliable. > I think i have made a bad case of explaining. Yes, I know where acquires terminate. However this is not about where acquires terminate. It is insufficient to assume that a succesful acquire to user space equates to successful interaction to the KE server which will do an update. Does that make more sense? If you issue an acquire from the kernel it will result in a domino effect in the blocks to the right of xfrm in your diagram and the end result is the larval SA gets an update (as a result of the acquire). So ignore where/how the acquire gets there and imagine that kernel sent an acquire so you could get an SA update then it will become clear. > OK, let's talk about architecture xfrm <-> blackbox. In this > architecture communication between these two elements (I do not speak > about any comms in the blackbox) can be of two types: > 1) reliable (messages always reach blackbox or error is reported); > 2) unreliable (messages may fail even to reach blackbox). > > With good blackboxes good ipsec system can be built using any of comm > types. But: > a) (1) will be more reliable; > b) (1) will be more simple (at least xfrm side, as it will not require > retransmisions); > c) (1) is implemented now (as a function call). > > What I want to say is xfrm-to-blackbox interface is good as it is. The > problem may only be in how good the blackbox is. And here we have to > look inside blackbox and start talk about particular implementations of > that blackbox. Retransmitions, if they needed, needs to be inside that > blackbox. > I am not sure i followed what you are actually trying to say above. Lets discuss basics of how reliability is achieved. If you want to have something reliably delivered after you transmit you do several basic things: a) you wait for an end acknowledgement, in this case an update to the acquire b) you timeout within reasonable time (30 seconds seems to be the default in acquire) and c) you retransmit upto a maximum number of times. This is the part that is missing > > > > The solution being proposed for Linux to treat that xfrm piece in the > > same fashion as ARP is correct. Read the email from Alexey. Imagine if > > ARP was only issued once(as does pfkey) or forever(as does netlink). > > > > I have read email from Alexey. I think that xfrm_lookup() function > implements functionality very similar to functionality which Alexey > described. Absolutely not. But this is a good sign - i.e you see the desire to do this, you just think its already there. > And I think that direct comparison of ARP messages and pfkey messages is > not fair, because pfkey acquire messages goes over reliable traffic and > are used only to _initiate_ the process of SA negotiation. ARP has to > receive information from other boxes which send it only as a direct > responce to some packet. More, ARP is designed to be used [amogst > others] on networks which loose some traffic by design. > Please refer to my above statements as to what is missing to complete the equation. > > I believe this is an issue with ipsec architecture itself - someone > > needs to write an IETF draft on it. > > > > I still do not see the topic for such draft. > Read again what i said above. cheers, jamal From hadi@cyberus.ca Mon Apr 4 05:51:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:51:55 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CplWa008325 for ; Mon, 4 Apr 2005 05:51:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DIR3Q-0001th-3s for netdev@oss.sgi.com; Mon, 04 Apr 2005 08:51:44 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIR3M-0003ty-Dw; Mon, 04 Apr 2005 08:51:40 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404121641.GA12103@gondor.apana.org.au> References: <1112358278.1096.160.camel@jzny.localdomain> <20050401123554.GA3468@gondor.apana.org.au> <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-Fpr/1RgxOBG3EaxqfHd0" Organization: jamalopolous Message-Id: <1112619096.1088.473.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 08:51:37 -0400 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1343 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 --=-Fpr/1RgxOBG3EaxqfHd0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Herbert, On Mon, 2005-04-04 at 08:16, Herbert Xu wrote: > Hi Jamal: > > On Mon, Apr 04, 2005 at 07:38:26AM -0400, jamal wrote: > > Ok, heres an update. > > +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); > > +void km_state_notify(struct xfrm_state *x, struct km_event *c); > > No need for these prototypes since they're already in xfrm.h. Good catch. > > > @@ -764,37 +778,60 @@ > > } > > EXPORT_SYMBOL(xfrm_replay_advance); > > > > -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > > -static DEFINE_RWLOCK(xfrm_km_lock); > > How about letting these guys stay where they are? The move was > necessary before because the km_*_notify functions had to be called > in this file but that's no longer the case. > Changed - dont see what the harm was as they were in that patch though. [..] > Sorry, you need to hold x before the call to > xfrm_state_add/xfrm_state_update as otherwise > they can cause x to be freed. > > In general hold/put is only useful if > > 1) When you call hold you already have a reference to the object. > 2) In between the hold/put you may free the object. > [..] > Same problem as xfrm_user. We need the hold to occur before the > add/update for it to be effective. In fact the original code was > buggy too since it didn't hold a reference at all. > > Of course this is very unlikely to crash since it requires a > small life time and some bad luck in getting preempted. > ;-> Yes, indeed. I think its time for you to throw in the towel ;-> There was really not even a need for that hold given the likelihood of anything like this happening. Anyways ive made this fix and heres the updated patch. cheers, jamal --=-Fpr/1RgxOBG3EaxqfHd0 Content-Disposition: attachment; filename=ipsec-event-take2-3 Content-Type: text/plain; name=ipsec-event-take2-3; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 +++ b/include/net/xfrm.h 2005-04-02 11:59:17.000000000 -0500 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -802,7 +827,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-25 22:28:39.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-02 09:53:03.000000000 -0500 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-03-25 22:28:25.000000000 -0500 +++ b/net/xfrm/xfrm_state.c 2005-04-04 08:41:52.000000000 -0400 @@ -48,7 +48,7 @@ static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); static DEFINE_SPINLOCK(xfrm_state_gc_lock); -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); @@ -208,8 +208,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -236,14 +238,21 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +int xfrm_state_delete(struct xfrm_state *x) { + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -402,6 +411,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -762,39 +772,64 @@ x->replay.bitmap |= (1U << diff); } } +static DEFINE_RWLOCK(xfrm_km_lock); +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); EXPORT_SYMBOL(xfrm_replay_advance); -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); -static DEFINE_RWLOCK(xfrm_km_lock); -static void km_state_expired(struct xfrm_state *x, int hard) +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct xfrm_mgr *km; + read_lock_bh(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock_bh(&xfrm_km_lock); +} + +void km_state_notify(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_mgr *km; + read_lock_bh(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + km->notify(x, c); + read_unlock_bh(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +static void km_state_expired(struct xfrm_state *x, int hard) +{ + struct km_event c; + if (hard) x->km.state = XFRM_STATE_EXPIRED; else x->km.dying = 1; - - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -819,13 +854,12 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-04 08:44:31.000000000 -0400 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -277,6 +278,7 @@ if (!x) return err; + xfrm_state_hold(x); if (nlh->nlmsg_type == XFRM_MSG_NEWSA) err = xfrm_state_add(x); else @@ -285,14 +287,27 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + xfrm_state_put(x); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +319,19 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -672,6 +696,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +708,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +719,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +846,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +875,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +889,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1112,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1129,107 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + if (x->aalg) + RTA_PUT(skb, XFRMA_ALG_AUTH, + sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8, x->aalg); + if (x->ealg) + RTA_PUT(skb, XFRMA_ALG_CRYPT, + sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8, x->ealg); + if (x->calg) + RTA_PUT(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg); + + if (x->encap) + RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: +rtattr_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1363,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1375,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1383,92 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + if (copy_to_user_tmpl(xp, skb) < 0) + goto nlmsg_failure; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("Netlink Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-03-25 22:28:39.000000000 -0500 +++ b/net/key/af_key.c 2005-04-04 08:44:50.000000000 -0400 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1254,6 +1326,7 @@ if (IS_ERR(x)) return PTR_ERR(x); + xfrm_state_hold(x); if (hdr->sadb_msg_type == SADB_ADD) err = xfrm_state_add(x); else @@ -1265,27 +1338,23 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1370,19 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1520,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + hdr->sadb_msg_satype = pfkey_proto2satype(c->data); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1948,35 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + + if (c->data && c->event == XFRM_SAP_DELETED) + out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; + else + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1984,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2052,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2084,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,25 +2120,41 @@ err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + + xfrm_pol_put(xp); + return err; +} + + +static int key_pol_get_resp(struct sock *sk, struct xfrm_policy *xp, struct sadb_msg *hdr, int dir) +{ + int err; + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + err = 0; + out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); goto out; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + pfkey_xfrm_policy2msg(out_skb, xp, dir); out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; + out_hdr->sadb_msg_type = hdr->sadb_msg_type; out_hdr->sadb_msg_satype = 0; out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ONE, sk); err = 0; out: - xfrm_pol_put(xp); return err; } @@ -2037,8 +2163,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2175,16 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.data = 1; // to signal pfkey of SADB_X_SPDDELETE2 + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + } else { + err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2219,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2445,25 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + printk("pfkey doesnt deal with expired policies ..\n"); + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2482,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3035,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-Fpr/1RgxOBG3EaxqfHd0-- From mingz@ele.uri.edu Mon Apr 4 05:57:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:57:12 -0700 (PDT) Received: from leviathan.ele.uri.edu (leviathan.ele.uri.edu [131.128.51.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Cv75U009006 for ; Mon, 4 Apr 2005 05:57:08 -0700 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j34CuuCu026841; Mon, 4 Apr 2005 08:56:57 -0400 (EDT) Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) From: Ming Zhang Reply-To: mingz@ele.uri.edu To: open-iscsi Cc: Dmitry Yusupov , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <20050404063456.GB30855@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> Content-Type: text/plain Message-Id: <1112619415.2880.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 04 Apr 2005 08:56:56 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: netdev yes, it travel 3 times instead of 1 time. and it is duplex. send traffic will take another 20%. so total 80% or it can never run that fast. ming On Mon, 2005-04-04 at 02:34, Grant Grundler wrote: > On Sun, Apr 03, 2005 at 05:56:11PM -0700, Dmitry Yusupov wrote: > > I do not get your concern with memory BW. With good AMD box V40Z(SUN) > > you can get 5.3GBytes/sec. Even with 10Gbps full speed you have 80% > > left. PCI-X BUS BW is bigger concern... > > Yes and No. PCI-X isn't fast enough but the data only crosses > the PCI-X bus once. Think about the data flow: > 1) DMA to RAM > 2) load into CPU cache > 3) store back into RAM > > We are down to 40% left...graphics folks won't like you. > > grant From mingz@ele.uri.edu Mon Apr 4 05:58:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:58:37 -0700 (PDT) Received: from leviathan.ele.uri.edu (leviathan.ele.uri.edu [131.128.51.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CwTVs009566 for ; Mon, 4 Apr 2005 05:58:29 -0700 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j34CwKCu026882; Mon, 4 Apr 2005 08:58:20 -0400 (EDT) Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) From: Ming Zhang Reply-To: mingz@ele.uri.edu To: open-iscsi Cc: Grant Grundler , Dmitry Yusupov , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <20050404001000.5fa8f206.davem@davemloft.net> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> <20050404001000.5fa8f206.davem@davemloft.net> Content-Type: text/plain Message-Id: <1112619500.2880.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 04 Apr 2005 08:58:20 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: netdev On Mon, 2005-04-04 at 03:10, David S. Miller wrote: > On Mon, 4 Apr 2005 00:34:56 -0600 > Grant Grundler wrote: > > > Yes and No. PCI-X isn't fast enough but the data only crosses > > the PCI-X bus once. Think about the data flow: > > 1) DMA to RAM > > 2) load into CPU cache > > 3) store back into RAM > > > > We are down to 40% left...graphics folks won't like you. > > But you're missing the point, which is that the memory system > always catches up to the networking technology. > > We'll have that %60 back before you know it when we have > PCI-Z and DDR8 or whatever even in $500.00USD desktop machines. 10G is supposed to be deployed in 2005 and 2006. while i did not see DDR4 come out yet. > > And those systems will be present by the time we put together > this complicated infrastructure for RDMA. > > RDMA is like cache coloring page allocators, it's for yesterday's > technology that we won't be using tomorrow. :-) > > Those steps #2 and #3 in your data flow are powerful, it is what > gives us flexibility. And in a general purpose OS that is important. From a.kasparas@gmc.lt Mon Apr 4 05:59:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 05:59:36 -0700 (PDT) Received: from sizifas.gmc.lt (esc.ortopedija.lt [213.190.36.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34CxTZh009899 for ; Mon, 4 Apr 2005 05:59:30 -0700 Received: from [10.19.65.83] ([::ffff:10.19.65.83]) by sizifas.gmc.lt with esmtp; Mon, 04 Apr 2005 15:59:25 +0300 Message-ID: <42513A2F.7020504@gmc.lt> Date: Mon, 04 Apr 2005 15:59:27 +0300 From: Aidas Kasparas User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: lt, en, ru, fr MIME-Version: 1.0 To: hadi@cyberus.ca CC: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> <1112538566.1096.391.camel@jzny.localdomain> <425067D9.9050603@gmc.lt> <1112618007.1096.465.camel@jzny.localdomain> In-Reply-To: <1112618007.1096.465.camel@jzny.localdomain> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev jamal wrote: > I think i have made a bad case of explaining. > Yes, I know where acquires terminate. However this is not about where > acquires terminate. It is insufficient to assume that a succesful > acquire to user space equates to successful interaction to the KE server > which will do an update. Why? -- Aidas Kasparas IT administrator GM Consult Group, UAB From herbert@gondor.apana.org.au Mon Apr 4 06:03:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 06:03:18 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34D39ul010777 for ; Mon, 4 Apr 2005 06:03:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIRE6-00036i-00; Mon, 04 Apr 2005 23:02:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIRDk-0003Gp-00; Mon, 04 Apr 2005 23:02:24 +1000 Date: Mon, 4 Apr 2005 23:02:24 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404130224.GA12546@gondor.apana.org.au> References: <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112619096.1088.473.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 08:51:37AM -0400, jamal wrote: > > > > -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > > > -static DEFINE_RWLOCK(xfrm_km_lock); > > > > How about letting these guys stay where they are? The move was > > necessary before because the km_*_notify functions had to be called > > in this file but that's no longer the case. > > Changed > - dont see what the harm was as they were in that patch though. Please see below. > +static DEFINE_RWLOCK(xfrm_km_lock); > +static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > EXPORT_SYMBOL(xfrm_replay_advance); > > -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > -static DEFINE_RWLOCK(xfrm_km_lock); All I wanted was to leave these lines as is so that they didn't appear in the patch at all (except as conext) :) When reviewing patches the most annoying thing is to see things moved around or rearranged because that distracts the reviewer from the substantiative changes. > ;-> Yes, indeed. I think its time for you to throw in the towel ;-> Alright I give in :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Apr 4 06:09:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 06:09:31 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34D9R4a011520 for ; Mon, 4 Apr 2005 06:09:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DIRKW-0001Ls-2x for netdev@oss.sgi.com; Mon, 04 Apr 2005 09:09:24 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIRKV-0006M7-2e; Mon, 04 Apr 2005 09:09:23 -0400 Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire From: jamal Reply-To: hadi@cyberus.ca To: Aidas Kasparas Cc: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org In-Reply-To: <42513A2F.7020504@gmc.lt> References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> <1112538566.1096.391.camel@jzny.localdomain> <425067D9.9050603@gmc.lt> <1112618007.1096.465.camel@jzny.localdomain> <42513A2F.7020504@gmc.lt> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112620159.1087.486.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 09:09:19 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1348 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, 2005-04-04 at 08:59, Aidas Kasparas wrote: > jamal wrote: > > I think i have made a bad case of explaining. > > Yes, I know where acquires terminate. However this is not about where > > acquires terminate. It is insufficient to assume that a succesful > > acquire to user space equates to successful interaction to the KE server > > which will do an update. > > Why? The reason the kernel sends an acquire is to update larval SAs it created. The result is either updating the SA or a rejection for that matter. Else theres failure in communication. Anology: If you are trying to send a message from one end system to another and there are multiple hops between them, then just because it made it to the first hop does not equate it made it to its final destination. To make it to the final destination, the confirmation has to come from the target end. So if you said the KE was the final destination then kernel to user space was the first hop. I am not sure if this is clear as an analogy. cheers, jamal From hadi@cyberus.ca Mon Apr 4 06:17:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 06:17:08 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34DH38o012207 for ; Mon, 4 Apr 2005 06:17:03 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIRRr-0000Y3-NA for netdev@oss.sgi.com; Mon, 04 Apr 2005 09:16:59 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIRRq-0007PZ-L9; Mon, 04 Apr 2005 09:16:58 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404130224.GA12546@gondor.apana.org.au> References: <1112403845.1088.14.camel@jzny.localdomain> <20050402012813.GA24575@gondor.apana.org.au> <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112620614.1088.489.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 09:16:55 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1349 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, 2005-04-04 at 09:02, Herbert Xu wrote: > > -static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); > > -static DEFINE_RWLOCK(xfrm_km_lock); > > All I wanted was to leave these lines as is so that they didn't > appear in the patch at all (except as conext) :) > > When reviewing patches the most annoying thing is to see things > moved around or rearranged because that distracts the reviewer > from the substantiative changes. Ok, fair enough. It annoys me too when i review patches ;-> So i will fix this before final. > > > ;-> Yes, indeed. I think its time for you to throw in the towel ;-> > > Alright I give in :) Goody - now we can have Masahide run his full test. cheers, jamal From Robert.Olsson@data.slu.se Mon Apr 4 06:17:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 06:17:50 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34DHjeC012307 for ; Mon, 4 Apr 2005 06:17:45 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j34DHCwI018239; Mon, 4 Apr 2005 15:17:12 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 42A31EE2B1; Mon, 4 Apr 2005 15:17:12 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16977.15960.242211.442811@robur.slu.se> Date: Mon, 4 Apr 2005 15:17:12 +0200 To: Herbert Xu Cc: Robert Olsson , Eric Dumazet , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() In-Reply-To: <20050404104857.GA32359@gondor.apana.org.au> References: <424E641A.1020609@cosmosbay.com> <16974.41648.568927.54429@robur.slu.se> <20050402193224.GA25157@gondor.apana.org.au> <16976.17876.832677.945878@robur.slu.se> <20050403214358.GA15901@gondor.apana.org.au> <16977.6411.415326.988754@robur.slu.se> <20050404104857.GA32359@gondor.apana.org.au> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1350 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 Herbert Xu writes: > What I'm trying to catch is the case when you've got x number of > entries in the table and a large fraction of them are all in one > chain. > > This does not conflict with the goal of keeping the chains short. > > Even if you strictly allow only 8 entries per chain, it's trivial > to exceed 8 times the average chain length. OK! Since deletions doen't happen instantly.. Try some code it can print a warning to start with. > > IMO the thoughts of extending in-flow GC etc are interesting and can > > hopefully give us more robust performance. > > Indeed, it looks like Alexey has already put the code there. It just > needs to be made more strict :) It needs to free entries even if they > are in use. > > After all, freeing an entry in use can't be much worse than not having > a cache at all. OTOH, having a very long chain is definitely much worse > than not having a cache :) FYI I'm experimenting with "new" routing algo that does 24-bit ipv4 lookup and routing without route hash to see if we can come close route hash performance This needs memory. :) IP: FIB routing table of 16777216 buckets, 65536Kbytes for table id=255 Needs some more work before testing. --ro From a.kasparas@gmc.lt Mon Apr 4 07:21:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 07:21:08 -0700 (PDT) Received: from sizifas.gmc.lt (esc.ortopedija.lt [213.190.36.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34EL2ZA015721 for ; Mon, 4 Apr 2005 07:21:03 -0700 Received: from [10.19.65.83] ([::ffff:10.19.65.83]) by sizifas.gmc.lt with esmtp; Mon, 04 Apr 2005 17:20:57 +0300 Message-ID: <42514D4B.1040202@gmc.lt> Date: Mon, 04 Apr 2005 17:20:59 +0300 From: Aidas Kasparas User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: lt, en, ru, fr MIME-Version: 1.0 To: hadi@cyberus.ca CC: ipsec-tools-devel@lists.sourceforge.net, netdev , nakam@linux-ipv6.org Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire References: <1112405303.1096.37.camel@jzny.localdomain> <424E454D.4090402@gmc.lt> <1112477326.1088.321.camel@jzny.localdomain> <424FA946.70809@gmc.lt> <1112538566.1096.391.camel@jzny.localdomain> <425067D9.9050603@gmc.lt> <1112618007.1096.465.camel@jzny.localdomain> <42513A2F.7020504@gmc.lt> <1112620159.1087.486.camel@jzny.localdomain> In-Reply-To: <1112620159.1087.486.camel@jzny.localdomain> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev jamal wrote: > On Mon, 2005-04-04 at 08:59, Aidas Kasparas wrote: > >>jamal wrote: >> >>>I think i have made a bad case of explaining. >>>Yes, I know where acquires terminate. However this is not about where >>>acquires terminate. It is insufficient to assume that a succesful >>>acquire to user space equates to successful interaction to the KE server >>>which will do an update. >> >>Why? > > > The reason the kernel sends an acquire is to update larval SAs it > created. The result is either updating the SA or a rejection for that > matter. Else theres failure in communication. > > Anology: If you are trying to send a message from one end system > to another and there are multiple hops between them, then just because > it made it to the first hop does not equate it made it to its final > destination. To make it to the final destination, the confirmation has > to come from the target end. > So if you said the KE was the final destination then kernel to user > space was the first hop. > I am not sure if this is clear as an analogy. OK, if you have a chain with sevaral hops, then probably there is no better way than signal from other end that it got something. The thing we do not agree is how this should be managed and supervised. I would like to provide an analogy too. You have a telenet application. You try to connect to some host:port. Your telnet application just makes connect(2) syscall and do not cares how kernel establishes that connection. What MAC address to send packet to, how and when to retransmit syn packet if the ack was not received in timely fashion, and so on, so on, so on. If kernel does his job fine, then we have connected socket on which to communicate further. If it does not, or there are some problems on the target host or network in between, then we will not have that connected socket - syscall will return an error. With ipsec system the situation is quite similar, just kernel and userspace have swaped places. Kernel told the userspace to update larval SA. Userspace works on that. If it has negotiated keys for that SA with KE at remote site, fine, userspace will update SA. If there are problems, and key negotiation is not possible -- these SA will not get updated and eventually will die. But single signal to userspace is sufficient for that process to be performed. Yes, kernel can check state of SA every time some packet has to use that SA. But to make noise by asking "please negotiate the SA which you're supposed to be negotiating already" ... IMHO it is contrproductive. -- Aidas Kasparas IT administrator GM Consult Group, UAB From sds@tycho.nsa.gov Mon Apr 4 07:22:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 07:22:41 -0700 (PDT) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34EMYCK015993 for ; Mon, 4 Apr 2005 07:22:34 -0700 Received: from tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id j34EJDis015970; Mon, 4 Apr 2005 14:19:13 GMT Received: from moss-spartans.epoch.ncsc.mil (moss-spartans [144.51.25.121]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id j34ENsDo029994; Mon, 4 Apr 2005 10:23:55 -0400 (EDT) Subject: Re: [PATCH] Fix SELinux for removal of i_sock From: Stephen Smalley To: "David S. Miller" Cc: jmorris@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, matthew@wil.cx In-Reply-To: <20050401123520.7532528b.davem@davemloft.net> References: <1112385997.14481.192.camel@moss-spartans.epoch.ncsc.mil> <20050401123520.7532528b.davem@davemloft.net> Content-Type: text/plain Organization: National Security Agency Date: Mon, 04 Apr 2005 10:13:53 -0400 Message-Id: <1112624033.7629.61.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-14) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sds@tycho.nsa.gov Precedence: bulk X-list: netdev On Fri, 2005-04-01 at 12:35 -0800, David S. Miller wrote: > On Fri, 01 Apr 2005 15:06:37 -0500 > Stephen Smalley wrote: > > > This patch against -bk eliminates the use of i_sock by SELinux as it > > appears to have been removed recently, breaking the build of SELinux in > > -bk. Simply replacing the i_sock test with an S_ISSOCK test would be > > unsafe in the SELinux code, as the latter will also return true for the > > inodes of socket files in the filesystem, not just the actual socket > > objects IIUC. Hence this patch reworks the SELinux code to avoid the > > need to apply such a test in the first place, part of which was > > obsoleted anyway by earlier changes to SELinux. Please apply. > > > > Signed-off-by: Stephen Smalley > > Signed-off-by: James Morris > > Applied, thanks Stephen. So, just for clarification, since a S_ISSOCK test is not necessarily equivalent to an i_sock test (in the case of inodes of socket files in the filesystem), was removing i_sock truly the right choice? It may not be an issue for typical users of i_sock since you can't open a descriptor to such a socket file, so any code that was acting on an open file shouldn't have to deal with this ambiguity, but could possibly lead to an erroneous use of SOCKET_I on the inode of a socket file in other code (which is what would have happened in SELinux if we had just changed the i_sock test to an ISSOCK test). Thanks, just trying to avoid confusion in the kernel in the future... -- Stephen Smalley National Security Agency From greearb@candelatech.com Mon Apr 4 08:44:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 08:44:30 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34FiNB9022886 for ; Mon, 4 Apr 2005 08:44:23 -0700 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j34GAbLH004256; Mon, 4 Apr 2005 09:10:37 -0700 Message-ID: <425160D1.6060701@candelatech.com> Date: Mon, 04 Apr 2005 08:44:17 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: netdev@oss.sgi.com, dcmwai@pl.jaring.my Subject: Re: Fw: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan References: <20050404041822.2ea0c16a.akpm@osdl.org> In-Reply-To: <20050404041822.2ea0c16a.akpm@osdl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1353 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 Andrew Morton wrote: > > Begin forwarded message: > > Date: Mon, 4 Apr 2005 04:15:25 -0700 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan > > > http://bugme.osdl.org/show_bug.cgi?id=4441 > > Summary: unregister_netdevice Prompt and system shell lookup when > trying to shutdown vlan > Kernel Version: 2.6.11-gentoo-r4 i686 > Status: NEW > Severity: high > Owner: acme@conectiva.com.br > Submitter: dcmwai@pl.jaring.my > > > Distribution: > Gentoo, FC2, FC3 > > Hardware Environment: > Pentium 4 3.0E, > Intel SE7210TP1-E Server Entry Board > 512 MB DDR Ram > 2x Intel® PRO/1000 Dual Port Adapters > > Software Environment: > Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1) > Fc2 and Fc2 original kernel. > > Problem Description: > When Shutdown a Vlan using this command > vconfig rem eth4.1001 > The interface will be down (using ifconfig) > However the following error will be prompt on the screen and the log leaving the > shell to be not responding. > > Even if "ifconfig eth4.1001 down" is run before "vconfig rem" sill the problem > will be there. > The only way I tested on solve this problem is to shutdown the interface totally. > ifconfig eth4 down > > Then the vlan can be removed correctly. > > This problem don't happen on the following "special Condition" > 1) On another motherboard (Gigabyte GA-81PE1000-G) same NIC on Fc3 > 1) On eth0 > > > Steps to reproduce: > 1. get a vlan supported NIC, emerge vconfig > 2. ifconfig ethx 0.0.0.0 > 3. create a vlan using "vconfig add ethx nnnn" > 4. ifconfig ethx.nnnn aaa.bbb.ccc.ddd > 5. remove the vlan using "vconfig rem ethx.nnnn" > 6. Wait for the error like the below. > * Motherboard and NIC seem to be a Problem in my case. > > unregister_netdevice: waiting for ethx.nnnn to become free. Usage count = 6 In the past, IPv6 has often been the problem here. Are you using IPv6? What is the hardware/driver for eth4? Thanks, Ben > > I've also open a bug in Gentoo > http://bugs.gentoo.org/show_bug.cgi?id=87495 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ganesh.venkatesan@gmail.com Mon Apr 4 08:59:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 08:59:08 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Fx3Qr023960 for ; Mon, 4 Apr 2005 08:59:03 -0700 Received: by rproxy.gmail.com with SMTP id r35so1210877rna for ; Mon, 04 Apr 2005 08:59:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QFV/TOJAgUzkcmGw15aOqirYL/nfc9WMnGu4vU5CpVFGt5Hfo5hI+yL7bYpj7kwZO5vUBeSJrIA4DkbIIcT+l75Hw1Cb1B+UfHr6eBJl7Z/HsOCh2exSXY+ORJHgNBssKRWg4ITlQc6qOdLRYslY0q4kBCwszb3q8JZBaPYugDc= Received: by 10.38.87.21 with SMTP id k21mr5262305rnb; Mon, 04 Apr 2005 08:59:02 -0700 (PDT) Received: by 10.54.29.37 with HTTP; Mon, 4 Apr 2005 08:59:02 -0700 (PDT) Message-ID: <5fc59ff3050404085928b37e57@mail.gmail.com> Date: Mon, 4 Apr 2005 08:59:02 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Ben Greear Subject: Re: Fw: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan Cc: Andrew Morton , netdev@oss.sgi.com, dcmwai@pl.jaring.my In-Reply-To: <425160D1.6060701@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050404041822.2ea0c16a.akpm@osdl.org> <425160D1.6060701@candelatech.com> X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev I have seen a similar issue without the VLAN module. I was using IPv4. Happens with 10/100 and 1GbE drivers on Itanium and AMD Opteron systems. Kernel used was RHEL4 (2.6.9-5.ELsmp). ganesh. On Apr 4, 2005 8:44 AM, Ben Greear wrote: > Andrew Morton wrote: > > > > Begin forwarded message: > > > > Date: Mon, 4 Apr 2005 04:15:25 -0700 > > From: bugme-daemon@osdl.org > > To: bugme-new@lists.osdl.org > > Subject: [Bugme-new] [Bug 4441] New: unregister_netdevice Prompt and system shell lookup when trying to shutdown vlan > > > > > > http://bugme.osdl.org/show_bug.cgi?id=4441 > > > > Summary: unregister_netdevice Prompt and system shell lookup when > > trying to shutdown vlan > > Kernel Version: 2.6.11-gentoo-r4 i686 > > Status: NEW > > Severity: high > > Owner: acme@conectiva.com.br > > Submitter: dcmwai@pl.jaring.my > > > > > > Distribution: > > Gentoo, FC2, FC3 > > > > Hardware Environment: > > Pentium 4 3.0E, > > Intel SE7210TP1-E Server Entry Board > > 512 MB DDR Ram > > 2x Intel(r) PRO/1000 Dual Port Adapters > > > > Software Environment: > > Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1) > > Fc2 and Fc2 original kernel. > > > > Problem Description: > > When Shutdown a Vlan using this command > > vconfig rem eth4.1001 > > The interface will be down (using ifconfig) > > However the following error will be prompt on the screen and the log leaving the > > shell to be not responding. > > > > Even if "ifconfig eth4.1001 down" is run before "vconfig rem" sill the problem > > will be there. > > The only way I tested on solve this problem is to shutdown the interface totally. > > ifconfig eth4 down > > > > Then the vlan can be removed correctly. > > > > This problem don't happen on the following "special Condition" > > 1) On another motherboard (Gigabyte GA-81PE1000-G) same NIC on Fc3 > > 1) On eth0 > > > > > > Steps to reproduce: > > 1. get a vlan supported NIC, emerge vconfig > > 2. ifconfig ethx 0.0.0.0 > > 3. create a vlan using "vconfig add ethx nnnn" > > 4. ifconfig ethx.nnnn aaa.bbb.ccc.ddd > > 5. remove the vlan using "vconfig rem ethx.nnnn" > > 6. Wait for the error like the below. > > * Motherboard and NIC seem to be a Problem in my case. > > > > unregister_netdevice: waiting for ethx.nnnn to become free. Usage count = 6 > > In the past, IPv6 has often been the problem here. Are you using IPv6? > > What is the hardware/driver for eth4? > > Thanks, > Ben > > > > > I've also open a bug in Gentoo > > http://bugs.gentoo.org/show_bug.cgi?id=87495 > > > > ------- You are receiving this mail because: ------- > > You are on the CC list for the bug, or are watching someone who is. > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From rharper333@hotmail.com Mon Apr 4 09:17:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:17:54 -0700 (PDT) Received: from OMC3-S41.phx.gbl (omc3-s41.bay6.hotmail.com [65.54.249.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34GHksC000737 for ; Mon, 4 Apr 2005 09:17:46 -0700 Received: from hotmail.com ([64.4.54.112]) by OMC3-S41.phx.gbl with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:17:41 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Apr 2005 09:17:41 -0700 Message-ID: Received: from 192.38.69.230 by by20fd.bay20.hotmail.msn.com with HTTP; Mon, 04 Apr 2005 16:17:40 GMT X-Originating-IP: [192.38.69.230] X-Originating-Email: [rharper333@hotmail.com] X-Sender: rharper333@hotmail.com From: "R Harper" To: netdev@oss.sgi.com Subject: RFC 1323 Date: Mon, 04 Apr 2005 18:17:40 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Apr 2005 16:17:41.0398 (UTC) FILETIME=[D3783B60:01C53931] X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rharper333@hotmail.com Precedence: bulk X-list: netdev Hello I have been taking a look at the timestamp feature in RFC 1323. My question is how are the TSval and TSecr fields represented in the current implementation of linux, e.g. that is the resolution of the timers. Is the format simply timeval.tv_sec from the time.h or is timeval.tv_usec also mixed into the timestamp. (If someone would point to where in the code this is defined) Another question, as I understand the RFC, the timestamp are only relevant to the box generating them. Are TCP implementation different in how the TSval data is represented? Is it possible to make use of the timestamp in an intermediate box, e.g. estimating RTT in a box that a TCP connection passes? I someone has the time to answer these question, it would be great. with regards r.harper _________________________________________________________________ Undgå pop-ups med MSN Toolbar - http://toolbar.msn.dk/ hent den gratis! From alpt@freaknet.org Mon Apr 4 09:22:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:23:04 -0700 (PDT) Received: from alpt.dyndns.org (host183-41.pool8251.interbusiness.it [82.51.41.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34GMsbT001557 for ; Mon, 4 Apr 2005 09:22:57 -0700 Received: (qmail 10087 invoked by uid 1000); 4 Apr 2005 18:22:01 +0200 Date: Mon, 4 Apr 2005 18:22:01 +0200 From: Alpt To: linux-net@vger.kernel.org, netdev@oss.sgi.com, bridge@lists.osdl.org Subject: Re: [PATCH bridge-2.6.11] bridge hub_enabled option Message-ID: <20050404162201.GA10070@nihil> Mail-Followup-To: Alpt , linux-net@vger.kernel.org, netdev@oss.sgi.com, bridge@lists.osdl.org References: <20050327092700.GA19972@nihil> <20050329112733.GA6274@darkalpt.hinezumilabs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20050329112733.GA6274@darkalpt.hinezumilabs.org> User-Agent: Mutt/1.4.2.1i User-Agent: hahaSRY X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alpt@freaknet.org Precedence: bulk X-list: netdev --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2005 at 01:27:33PM +0200, Alpt wrote : ~> The document describing this patch is here: ~> http://www.freaknet.org/alpt/src/bridge-hub/readme ~>=20 ~> There is a small correction for this patch. The new version is attached ~> here and be be found also here: ~> http://www.freaknet.org/alpt/src/bridge-hub/bridge-2.6.11-hub.patch ~>=20 ~> The patch for the bridge-utils: ~> http://www.freaknet.org/alpt/src/bridge-hub/bridge-utils-1.0.6-hub.patch so.. is it applied or not? Best Regards --=20 :wq! "I don't know nothing" The One Who reached the Thinking Matter '.' [ Alpt --- Freaknet Medialab ] [ GPG Key ID 441CF0EE ] [ Key fingerprint =3D 8B02 26E8 831A 7BB9 81A9 5277 BFF8 037E 441C F0EE ] --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCUWmpv/gDfkQc8O4RAhPXAJwNGJMFHkVEPVrV5reo3bknUdtJygCgxBWM fMqPves8wmP6yoXMCdDaBXQ= =xnaj -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From grundler@lackof.org Mon Apr 4 09:29:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:29:45 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34GTbWx002339 for ; Mon, 4 Apr 2005 09:29:37 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 6F57E29802F; Mon, 4 Apr 2005 10:31:27 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07632-04; Mon, 4 Apr 2005 10:31:25 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id E0B7B298010; Mon, 4 Apr 2005 10:31:25 -0600 (MDT) Date: Mon, 4 Apr 2005 10:31:25 -0600 From: Grant Grundler To: "David S. Miller" Cc: dmitry_yus@yahoo.com, open-iscsi@googlegroups.com, mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050404163125.GA6809@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> <20050404001000.5fa8f206.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050404001000.5fa8f206.davem@davemloft.net> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 12:10:00AM -0700, David S. Miller wrote: > On Mon, 4 Apr 2005 00:34:56 -0600 > Grant Grundler wrote: > > > Yes and No. PCI-X isn't fast enough but the data only crosses > > the PCI-X bus once. Think about the data flow: > > 1) DMA to RAM > > 2) load into CPU cache > > 3) store back into RAM > > > > We are down to 40% left...graphics folks won't like you. > > But you're missing the point, which is that the memory system > always catches up to the networking technology. No. Bus bandwidth catches up to "a" networking technology - not the "current" technology. Networking and graphics are usually starving for bus bandwidth. > We'll have that %60 back before you know it when we have > PCI-Z and DDR8 or whatever even in $500.00USD desktop machines. Yes, I agree. That's certainly how it went for 100bt and gige. Even laptops come with gige now. But we aren't in that part "of the curve" for IB or 10GigE *yet*. > And those systems will be present by the time we put together > this complicated infrastructure for RDMA. And that will be fine for "general use". > RDMA is like cache coloring page allocators, it's for yesterday's > technology that we won't be using tomorrow. :-) > > Those steps #2 and #3 in your data flow are powerful, it is what > gives us flexibility. Agreed - some very cool things have been done with it. And for general use, it'll perf sufficiently well over gige. In the future, I agree IB or 10gigE will too. > And in a general purpose OS that is important. I think most of the people interested in IB and 10GigE aren't looking for "general use". They have a particular application in mind and they want to maximize performance for dollar spent. Things like "science appliance", "router", "data warehouse" come to mind. "General Use" will be a reality only when the dollar cost comes down so those new technologies can compete with gige. thanks, grant From shemminger@osdl.org Mon Apr 4 09:30:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:30:53 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34GUmXJ002616 for ; Mon, 4 Apr 2005 09:30:48 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j34GUZs4012382 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Apr 2005 09:30:36 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j34GUZDs020853; Mon, 4 Apr 2005 09:30:35 -0700 Date: Mon, 4 Apr 2005 09:30:36 -0700 From: Stephen Hemminger To: Alpt Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, bridge@lists.osdl.org Subject: Re: [PATCH bridge-2.6.11] bridge hub_enabled option Message-ID: <20050404093036.1065a465@dxpl.pdx.osdl.net> In-Reply-To: <20050404162201.GA10070@nihil> References: <20050327092700.GA19972@nihil> <20050329112733.GA6274@darkalpt.hinezumilabs.org> <20050404162201.GA10070@nihil> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 4 Apr 2005 18:22:01 +0200 Alpt wrote: > On Tue, Mar 29, 2005 at 01:27:33PM +0200, Alpt wrote : > ~> The document describing this patch is here: > ~> http://www.freaknet.org/alpt/src/bridge-hub/readme > ~> > ~> There is a small correction for this patch. The new version is attached > ~> here and be be found also here: > ~> http://www.freaknet.org/alpt/src/bridge-hub/bridge-2.6.11-hub.patch > ~> > ~> The patch for the bridge-utils: > ~> http://www.freaknet.org/alpt/src/bridge-hub/bridge-utils-1.0.6-hub.patch > > so.. is it applied or not? > > Best Regards I would rather it not be applied to mainline since it only has specialized usage. I am willing to hold keep it in the patches area of the bridge site so others can find it. From shemminger@osdl.org Mon Apr 4 09:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:51:15 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Gp3xB004024 for ; Mon, 4 Apr 2005 09:51:03 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j34Goms4014278 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Apr 2005 09:50:48 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j34Gol14021977; Mon, 4 Apr 2005 09:50:47 -0700 Date: Mon, 4 Apr 2005 09:50:47 -0700 From: Stephen Hemminger To: jaganav@us.ibm.com Cc: Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050404095047.4d5c263f@dxpl.pdx.osdl.net> In-Reply-To: <1112405833.424df749e61b5@imap.linux.ibm.com> References: <1112405833.424df749e61b5@imap.linux.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 1 Apr 2005 20:37:13 -0500 jaganav@us.ibm.com wrote: > Quoting Stephen Hemminger : > > > On Thu, 31 Mar 2005 21:13:39 -0500 > > jaganav@us.ibm.com wrote: > > > > > Quoting Roland Dreier : > > > > I have to admit I don't know much about the TOE / RDMA/TCP / RNIC (or > > > > whatever you want to call it) world. However I know that the large > > > > majority of InfiniBand use right now is running on Linux, and I hope > > > > the Linux community is willing to work with the IB community. > > > > > > > > > > Just want to let everyone know know that we have started an opensource > > > effort (www.openrdma.org) for enablement of RNICs (RDMA enabled NICs). > > This > > > community has now come up with an architecture > > > (http://rdma.sourceforge.net/architecture.pdf) to build this support in > > Linux. > > > Would really appreciate if you review and provide any comments. We have > > just > > > started to hack but no code is available on this project yet. > > > > > > Thanks > > > Venkat > > > > OpenRdma is a misnomer, because as I read your architecture you are trying > > to > > create a "kernel abstraction layer" for closed source vendor RDMA drivers. > > This will > > never be accepted, please go back to the drawing board and figure out how to > > make > > real open source drivers. > > > > > > First let me say that the purpose of this project is to > make the entire stack (with all of the enablement layers) > including the drivers opensourced. How about putting out code early that implements a subset of what you want (and not waiting till you think it is done). > The kernel abstraction layer will be built > around standards based (opengroup.org/icsc) RNIC-PI > interface and which allows the RNIC vendors to opensource > their drivers using that interface. BTW, RNIC-PI > interface is work-in-progress and the first draft > is targeted to be published soon. But standards based abstraction layer is sure to be limited to least common denominator. The locking model and setup/teardown are sure to be different under each OS. Also, it is impossible to build any decent abstraction top-down in a "waterfall" model. You need to have an iterative process that refines and is willing to have compatibility restrictions. Also, the kernel community hates interfaces and code where there is a big *don't go here* box that prevents fixing bugs and improving interfaces. Linux puts a big emphasis on long-term maintainability of code. Another issue that concerns me is making sure that all the security and policy are maintained when doing RDMA. How do you do firewalling and routing when you are allowing adapter to control the world? > Several RNIC adapter vendors, who contribute to the > openRDMA effort, are quite willing to opensource > their drivers through openRDMA project. > > BTW, I understood why you got the impression > that the this is for closed source vendor drivers: > Our intention is not to allow the kernel verbs > provider code (kVP) to be private and that was > an error. Thanks for pointing this out > but we'll make this change soon. You are attacking a hard problem. Thanks for the effort. From dmitry_yus@yahoo.com Mon Apr 4 09:54:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:54:18 -0700 (PDT) Received: from smtp110.mail.sc5.yahoo.com (smtp110.mail.sc5.yahoo.com [66.163.170.8]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j34GsCSr004647 for ; Mon, 4 Apr 2005 09:54:12 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp110.mail.sc5.yahoo.com with SMTP; 4 Apr 2005 16:54:12 -0000 Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) From: Dmitry Yusupov To: Grant Grundler Cc: "open-iscsi@googlegroups.com" , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com In-Reply-To: <20050404063456.GB30855@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> Content-Type: text/plain Date: Mon, 04 Apr 2005 09:54:10 -0700 Message-Id: <1112633650.9559.142.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev On Mon, 2005-04-04 at 00:34 -0600, Grant Grundler wrote: > On Sun, Apr 03, 2005 at 05:56:11PM -0700, Dmitry Yusupov wrote: > > I do not get your concern with memory BW. With good AMD box V40Z(SUN) > > you can get 5.3GBytes/sec. Even with 10Gbps full speed you have 80% > > left. PCI-X BUS BW is bigger concern... > > Yes and No. PCI-X isn't fast enough but the data only crosses > the PCI-X bus once. Think about the data flow: > 1) DMA to RAM yes. > 2) load into CPU cache yes. > 3) store back into RAM no. we are talking about receive side optimization only. why do you think store back into RAM comes to the picture? also keep in mind that we have huge L2 & L3 caches today and write operation is usually very well buffered. > We are down to 40% left...graphics folks won't like you. > > grant > From rick.jones2@hp.com Mon Apr 4 09:56:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 09:56:29 -0700 (PDT) Received: from ccerelrim03.cce.hp.com (smtp.cce.hp.com [161.114.21.24]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34GuOsC005260 for ; Mon, 4 Apr 2005 09:56:24 -0700 Received: from ccerelrim03.cce.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id DC12332E42; Mon, 4 Apr 2005 11:56:18 -0500 (CDT) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) by ccerelrim03.cce.hp.com (Postfix) with ESMTP id AFDD532E82; Mon, 4 Apr 2005 11:56:16 -0500 (CDT) Received: from [192.168.1.100] (adsl-64-171-2-144.dsl.sntc01.pacbell.net [64.171.2.144]) by mailstation.cce.hp.com (Postfix) with ESMTP id 960781CCC8; Mon, 4 Apr 2005 11:56:15 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: rick jones Subject: Re: RFC 1323 Date: Mon, 4 Apr 2005 09:56:06 -0700 To: "R Harper" X-Mailer: Apple Mail (2.619.2) X-PMX-Version: 5.0.0.131485, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.4.4.8 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev > > Another question, as I understand the RFC, the timestamp are only > relevant to the box generating them. Are TCP implementation different > in how the TSval data is represented? They certainly can be - for the PAWS portion of 1323 the fields in the "timestamp" options only have to be monotonic nondecreasing so they can extend the sequence number space. From my brief perusal of the RFC, sender's are free to have them be more or less whatever they want, and as networks become faster (10G) looks like higher resolution will be desired. [I wonder when even the extra 32 bits will not be enough :) ] With the recent dust-up about ID'ing systems based on their clock skew, it would not surprise me to see someone suggest that the options should just be for PAWS and not for RTTM. > Is it possible to make use of the timestamp in an intermediate box, > e.g. estimating RTT in a box that a TCP connection passes? If you know that the sender is using the option for timing, and know the resolution - basically that means knowing what the sender is running. rick jones there is no rest for the wicked, yet the virtuous have no pillows From ayyappan.veeraiyan@intel.com Mon Apr 4 10:26:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 10:26:56 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34HQmgQ007045 for ; Mon, 4 Apr 2005 10:26:49 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j34HQSdY020356; Mon, 4 Apr 2005 17:26:28 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j34HQNeL028773; Mon, 4 Apr 2005 17:26:27 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005040410262504784 ; Mon, 04 Apr 2005 10:26:26 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 10:26:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: pktgen problem (skb refcount) in 2.6.12-rc1 Date: Mon, 4 Apr 2005 10:26:18 -0700 Message-ID: <9D602ABCE51B0B488BF857A4787939B5042E7396@orsmsx410> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pktgen problem (skb refcount) in 2.6.12-rc1 Thread-Index: AcU41yY6h7+AmF6WRLCqF13GmO45xAAXoIhw From: "Veeraiyan, Ayyappan" To: "Harald Welte" , "Robert Olsson" Cc: X-OriginalArrivalTime: 04 Apr 2005 17:26:19.0787 (UTC) FILETIME=[6A3885B0:01C5393B] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j34HQmgQ007045 X-archive-position: 1362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ayyappan.veeraiyan@intel.com Precedence: bulk X-list: netdev Harald, > > As for e1000 and or generic TX path changes, I don't have the time to > review them now, sorry :( That's why I posted it to netdev, to let > people who have an idea about the committed changes know that there is > an issue. > What version of e1000 you are using? If you are using e1000 5.7.6-k2 and haven't tried older versions, Could you please try e1000 version 5.6.10.1-k2 (available in kernel 2.6.11) and inform us the result? Thanks, Ayyappan V. > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of Harald Welte > Sent: Sunday, April 03, 2005 10:27 PM > To: Robert Olsson > Cc: netdev@oss.sgi.com > Subject: Re: pktgen problem (skb refcount) in 2.6.12-rc1 > > On Sun, Apr 03, 2005 at 09:18:30PM +0200, Robert Olsson wrote: > > > > I've tried to track the problem down, and I've confirmed that skb- > >users > > > never goes down to 1 but instead stays at '2'. > > > > > The same system with the same pktgen script works fine with 2.6.11.6. > > > > > > I'm reporting this since it seems like it sounds like we have a skb > > > usage count leak somewhere :( > > > > Sounds like a diff could give some clues. pktgen, e1000 and TX-path > should > > be interesting as ev. changes in kernel config. > > no changes in kernel config. I've reviewed pktgen changes and couldn't > find something that would cause the problem. It always only > atomic_inc'ed the ussage cound (and decrements only in error path) which > is perfectly fine. > > As for e1000 and or generic TX path changes, I don't have the time to > review them now, sorry :( That's why I posted it to netdev, to let > people who have an idea about the committed changes know that there is > an issue. > > Cheers, > Harald > -- > - Harald Welte > http://gnumonks.org/ > ======================================================================== == > == > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) From bcrl@kvack.org Mon Apr 4 10:30:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 10:30:37 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34HUWkL007665 for ; Mon, 4 Apr 2005 10:30:33 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Mon, 4 Apr 2005 13:30:10 -0400 Date: Mon, 4 Apr 2005 13:30:10 -0400 From: Benjamin LaHaise To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] fix uninitialized proto_list_lock Message-ID: <20050404173010.GA19451@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Please apply the following patch which fixes a BUG() on boot when the kernel is compiled with spinlock debugging in bk head. Cheers, -ben ===== net/core/sock.c 1.67 vs edited ===== --- 1.67/net/core/sock.c 2005-03-26 18:04:35 -05:00 +++ edited/net/core/sock.c 2005-04-04 12:46:26 -04:00 @@ -1352,7 +1352,7 @@ EXPORT_SYMBOL(sk_common_release); -static rwlock_t proto_list_lock; +static rwlock_t proto_list_lock = RW_LOCK_UNLOCKED; static LIST_HEAD(proto_list); int proto_register(struct proto *prot, int alloc_slab) From davem@davemloft.net Mon Apr 4 10:36:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 10:36:48 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34HagQx008344 for ; Mon, 4 Apr 2005 10:36:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIVTi-00045i-00; Mon, 04 Apr 2005 10:35:10 -0700 Date: Mon, 4 Apr 2005 10:35:09 -0700 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, netdev@oss.sgi.com Subject: Re: [IPSEC]: Protect against BHs in xfrm_user_policy() Message-Id: <20050404103509.06ca48a4.davem@davemloft.net> In-Reply-To: <20050404115508.GA12171@gondor.apana.org.au> References: <4250160D.2040405@trash.net> <20050404012040.GA16960@gondor.apana.org.au> <20050404115508.GA12171@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 4 Apr 2005 21:55:08 +1000 Herbert Xu wrote: > The read_lock()'s only need to be protected from the write_lock()'s. > > Since all the write_lock()'s are made in process context, we don't > need to disable BH on the read_lock()'s. This is correct. It's actually a common technique, only disable IRQ or BH in the write_locks. From davem@redhat.com Mon Apr 4 10:43:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 10:43:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Hhl49009059 for ; Mon, 4 Apr 2005 10:43:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j34Hhkfu002729; Mon, 4 Apr 2005 13:43:46 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j34HhkO16745; Mon, 4 Apr 2005 13:43:46 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with SMTP id j34HhjAs018053; Mon, 4 Apr 2005 13:43:45 -0400 Date: Mon, 4 Apr 2005 10:42:54 -0700 From: "David S. Miller" To: Benjamin LaHaise Cc: netdev@oss.sgi.com Subject: Re: [PATCH] fix uninitialized proto_list_lock Message-Id: <20050404104254.0d30ba8d.davem@redhat.com> In-Reply-To: <20050404173010.GA19451@kvack.org> References: <20050404173010.GA19451@kvack.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1365 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, 4 Apr 2005 13:30:10 -0400 Benjamin LaHaise wrote: > Please apply the following patch which fixes a BUG() on boot when the > kernel is compiled with spinlock debugging in bk head. Cheers, This is already in Linus's tree. Thanks. From arnaldo.melo@gmail.com Mon Apr 4 10:45:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 10:45:46 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34HjcKR009540 for ; Mon, 4 Apr 2005 10:45:38 -0700 Received: by wproxy.gmail.com with SMTP id 68so1642512wri for ; Mon, 04 Apr 2005 10:45:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iscThFzpwHhGqjnirB8wtlISRQdIOFHHB0SmyeGue0FNMXYNhckUCVCyKJEnzBj9AzslfjFVjeZY95zq214PwsnN60q6clWl22zdbGKAeNIw6kr8QPu3gPp92uWtkSJWm1djGl0gPFwK+RiSXMVrwoCf8SLwmu7hOyJ6G8RBve8= Received: by 10.54.15.26 with SMTP id 26mr77695wro; Mon, 04 Apr 2005 10:45:31 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Mon, 4 Apr 2005 10:45:30 -0700 (PDT) Message-ID: <39e6f6c7050404104578221d01@mail.gmail.com> Date: Mon, 4 Apr 2005 14:45:30 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Benjamin LaHaise Subject: Re: [PATCH] fix uninitialized proto_list_lock Cc: davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <20050404173010.GA19451@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050404173010.GA19451@kvack.org> X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On Apr 4, 2005 2:30 PM, Benjamin LaHaise wrote: > Please apply the following patch which fixes a BUG() on boot when the > kernel is compiled with spinlock debugging in bk head. Cheers, > > -ben > > ===== net/core/sock.c 1.67 vs edited ===== > --- 1.67/net/core/sock.c 2005-03-26 18:04:35 -05:00 > +++ edited/net/core/sock.c 2005-04-04 12:46:26 -04:00 > @@ -1352,7 +1352,7 @@ > > EXPORT_SYMBOL(sk_common_release); > > -static rwlock_t proto_list_lock; > +static rwlock_t proto_list_lock = RW_LOCK_UNLOCKED; This was already fixed by James Bottomley and its in Dave tree waiting for Linus to do a pull. Thanks anyway! - Arnaldo From rick.jones2@hp.com Mon Apr 4 11:57:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 11:58:00 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34IvrO8013446 for ; Mon, 4 Apr 2005 11:57:54 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id 69BCF1C04AC0; Mon, 4 Apr 2005 11:57:53 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id LAA21630; Mon, 4 Apr 2005 11:57:52 -0700 (PDT) Message-ID: <42518E30.2090207@hp.com> Date: Mon, 04 Apr 2005 11:57:52 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: "open-iscsi@googlegroups.com" , ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics References: <20050324215922.GT14202@opteron.random> <424346FE.20704@cs.wisc.edu> <20050324233921.GZ14202@opteron.random> <20050325034341.GV32638@waste.org> <20050327035149.GD4053@g5.random> <20050327054831.GA15453@waste.org> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@davemloft.net> <52vf7bwo4w.fsf@topspin.com> <1112042936.5088.22.camel@beastie> <20050328223203.GC28983@kvack.org> <1112465317.24936.10.camel@mylaptop> In-Reply-To: <1112465317.24936.10.camel@mylaptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev > What RDMA gives us is zero-copy on receive and new networking api which > has a potential to be HW accelerated. SoftRDMA will never avoid copying > on receive. But benefit for SoftRDMA would be its availability on client > sides. It is free and it could be easily deployed. Soon Intel & Co will > give us 2,4,8... multi-core CPUs for around 200$ :), So, who cares if > one of those cores will do receive side copying? 20 years ago, in certain circles at least, people were saying "With 32-bits of addressing, who cares if we allocate much memory" :) Speaking a bit more prosaicly, if that core is sitting there churning through data copies, what affect does that have on the rest of the bus(ses) and the memory? What else will the client want to be able to push around that those data copies may preclude? rick jones From grundler@lackof.org Mon Apr 4 12:09:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 12:09:18 -0700 (PDT) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34J9Ca6014760 for ; Mon, 4 Apr 2005 12:09:12 -0700 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 260C629802F; Mon, 4 Apr 2005 13:11:03 -0600 (MDT) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09890-03; Mon, 4 Apr 2005 13:11:01 -0600 (MDT) Received: by colo.lackof.org (Postfix, from userid 27253) id C4D90298010; Mon, 4 Apr 2005 13:11:01 -0600 (MDT) Date: Mon, 4 Apr 2005 13:11:01 -0600 From: Grant Grundler To: Dmitry Yusupov Cc: "open-iscsi@googlegroups.com" , "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Message-ID: <20050404191101.GB6809@colo.lackof.org> References: <67D69596DDF0C2448DB0F0547D0F947E01781F2E@yogi.asicdesigners.com> <1112576171.4227.5.camel@mylaptop> <20050404063456.GB30855@colo.lackof.org> <1112633650.9559.142.camel@beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112633650.9559.142.camel@beastie> X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 09:54:10AM -0700, Dmitry Yusupov wrote: > > 3) store back into RAM > > no. we are talking about receive side optimization only. > why do you think store back into RAM comes to the picture? Application eventually wants to read the data. > also keep in mind that we have huge L2 & L3 caches today and write > operation is usually very well buffered. Agreed. But how effective the cache is will depend on if the CPU (application) can process the data as fast as it arrives (and still be in the cache). Otherwise the data will get pushed out in (3) and recalled later when the app can consume it (4th time across). It also assumes the application is running on a CPU core that shares the cache with the CPU that did the copy. If the CPU is saturated with the copy (ok, assume we've got 2 Cores per socket), then the other CPU has to be *assigned* manually to make sure it does the other part. Jamal learned all this when he moved to a dual core PPC for his fast routing work. Jamal, did that ever make it into a paper? grant From acme@ghostprotocols.net Mon Apr 4 12:49:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 12:49:31 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34JnI3i021966 for ; Mon, 4 Apr 2005 12:49:22 -0700 Received: from [200.138.131.177] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DIXa7-0005JG-00; Mon, 04 Apr 2005 16:49:55 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 6366014631; Mon, 4 Apr 2005 16:48:35 -0300 (BRT) Date: Mon, 4 Apr 2005 16:48:35 -0300 To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH 1/2][AX25] make ax25_queue_xmit a net_device parameter Message-ID: <20050404194835.GI640@conectiva.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi David, Ralf, This one is just in preparation for the second, that introduces ax25_type_trans. Available at: bk://kernel.bkbits.net/acme/sk_buff-2.6 Regards, - Arnaldo --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ax25.1.patch" =================================================================== ChangeSet@1.2245, 2005-04-04 16:23:29-03:00, acme@toy.ghostprotocols.net [AX25] make ax25_queue_xmit a net_device parameter I.e. not using skb->dev as a way to pass the parameter used to fill... skb->dev :-) Also to get the _type_trans open coded sequence grouped, next changesets will introduce ax25_type_trans. Signed-off-by: Ralf Baechle Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller include/net/ax25.h | 2 +- net/ax25/af_ax25.c | 4 +--- net/ax25/ax25_ip.c | 4 +--- net/ax25/ax25_out.c | 8 +++----- net/ax25/ax25_subr.c | 4 +--- 5 files changed, 7 insertions(+), 15 deletions(-) diff -Nru a/include/net/ax25.h b/include/net/ax25.h --- a/include/net/ax25.h 2005-04-04 16:43:28 -03:00 +++ b/include/net/ax25.h 2005-04-04 16:43:28 -03:00 @@ -305,7 +305,7 @@ extern void ax25_output(ax25_cb *, int, struct sk_buff *); extern void ax25_kick(ax25_cb *); extern void ax25_transmit_buffer(ax25_cb *, struct sk_buff *, int); -extern void ax25_queue_xmit(struct sk_buff *); +extern void ax25_queue_xmit(struct sk_buff *skb, struct net_device *dev); extern int ax25_check_iframes_acked(ax25_cb *, unsigned short); /* ax25_route.c */ diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c 2005-04-04 16:43:28 -03:00 +++ b/net/ax25/af_ax25.c 2005-04-04 16:43:28 -03:00 @@ -1587,9 +1587,7 @@ *asmptr = AX25_UI; /* Datagram frames go straight out of the door as UI */ - skb->dev = ax25->ax25_dev->dev; - - ax25_queue_xmit(skb); + ax25_queue_xmit(skb, ax25->ax25_dev->dev); err = len; diff -Nru a/net/ax25/ax25_ip.c b/net/ax25/ax25_ip.c --- a/net/ax25/ax25_ip.c 2005-04-04 16:43:28 -03:00 +++ b/net/ax25/ax25_ip.c 2005-04-04 16:43:28 -03:00 @@ -199,9 +199,7 @@ skb = ourskb; } - skb->dev = dev; - - ax25_queue_xmit(skb); + ax25_queue_xmit(skb, dev); put: ax25_put_route(route); diff -Nru a/net/ax25/ax25_out.c b/net/ax25/ax25_out.c --- a/net/ax25/ax25_out.c 2005-04-04 16:43:28 -03:00 +++ b/net/ax25/ax25_out.c 2005-04-04 16:43:28 -03:00 @@ -340,21 +340,19 @@ ax25_addr_build(ptr, &ax25->source_addr, &ax25->dest_addr, ax25->digipeat, type, ax25->modulus); - skb->dev = ax25->ax25_dev->dev; - - ax25_queue_xmit(skb); + ax25_queue_xmit(skb, ax25->ax25_dev->dev); } /* * A small shim to dev_queue_xmit to add the KISS control byte, and do * any packet forwarding in operation. */ -void ax25_queue_xmit(struct sk_buff *skb) +void ax25_queue_xmit(struct sk_buff *skb, struct net_device *dev) { unsigned char *ptr; skb->protocol = htons(ETH_P_AX25); - skb->dev = ax25_fwd_dev(skb->dev); + skb->dev = ax25_fwd_dev(dev); ptr = skb_push(skb, 1); *ptr = 0x00; /* KISS */ diff -Nru a/net/ax25/ax25_subr.c b/net/ax25/ax25_subr.c --- a/net/ax25/ax25_subr.c 2005-04-04 16:43:28 -03:00 +++ b/net/ax25/ax25_subr.c 2005-04-04 16:43:28 -03:00 @@ -220,9 +220,7 @@ dptr = skb_push(skb, ax25_addr_size(digi)); dptr += ax25_addr_build(dptr, dest, src, &retdigi, AX25_RESPONSE, AX25_MODULUS); - skb->dev = dev; - - ax25_queue_xmit(skb); + ax25_queue_xmit(skb, dev); } /* --mYCpIKhGyMATD0i+-- From sam@ravnborg.org Mon Apr 4 12:49:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 12:49:46 -0700 (PDT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34JnTsl022036 for ; Mon, 4 Apr 2005 12:49:30 -0700 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepa.post.tele.dk (Postfix) with ESMTP id 5B57247FEA7; Mon, 4 Apr 2005 21:49:20 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 27A746AC01D; Mon, 4 Apr 2005 21:50:52 +0200 (CEST) Date: Mon, 4 Apr 2005 21:50:52 +0200 From: Sam Ravnborg To: "Randy.Dunlap" Cc: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers Message-ID: <20050404195051.GA12364@mars.ravnborg.org> References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4250B4C5.2000200@osdl.org> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 08:30:13PM -0700, Randy.Dunlap wrote: > Any comments on this new version? The new Networking menu looks unstructured. And the net/Kconfig file contains a lot of config snippets that does not belong there. So I took a stamp on it with focus on: - Move config bits to appropriate places, creating several new Kconfig files - Made uses of menus more consistent at least on first and second level - Move submenu to the top - Rename top menu to "Networking" and located it just before "File systems" The patch became much larger. The win is that the top-level net/Kconfig contains much less cruft. Many of the 56 lines added are due to the additional files. I did not (on purpose) change any functionality. Only bit that I am worried about is the statement in SCTP: depends on IPV6 || IPV6=n That looked like a noop to me. It had the sideeffect that SCTP menu entries where idented an extra level which was not desireable with currect layout. Comments appreciated. Patch on top of rc2. Signed-off-by: Sam Ravnborg --- Sam drivers/Kconfig | 5 drivers/net/Kconfig | 5 drivers/net/appletalk/Kconfig | 28 ++ net/8021q/Kconfig | 21 + net/Kconfig | 541 +++--------------------------------------- net/atm/Kconfig | 77 +++++ net/bridge/Kconfig | 32 ++ net/bridge/netfilter/Kconfig | 1 net/core/Kconfig | 67 +++++ net/decnet/Kconfig | 24 + net/econet/Kconfig | 34 ++ net/ipv4/netfilter/Kconfig | 5 net/ipv6/Kconfig | 20 + net/ipx/Kconfig | 33 ++ net/lapb/Kconfig | 24 + net/packet/Kconfig | 26 ++ net/sched/Kconfig | 40 +++ net/sctp/Kconfig | 5 net/unix/Kconfig | 22 + net/wanrouter/Kconfig | 31 ++ net/x25/Kconfig | 35 ++ 21 files changed, 567 insertions(+), 509 deletions(-) diff -Nru a/drivers/Kconfig b/drivers/Kconfig --- a/drivers/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/drivers/Kconfig 2005-04-04 21:41:57 +02:00 @@ -28,7 +28,7 @@ source "drivers/macintosh/Kconfig" -source "net/Kconfig" +source "drivers/net/Kconfig" source "drivers/isdn/Kconfig" @@ -59,3 +59,6 @@ source "drivers/infiniband/Kconfig" endmenu + +source "net/Kconfig" + diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/drivers/net/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,8 +1,9 @@ - # # Network device configuration # +menu "Network device support" + config NETDEVICES depends on NET bool "Network device support" @@ -2535,4 +2536,6 @@ ---help--- If you want to log kernel messages over the network, enable this. See for details. + +endmenu diff -Nru a/drivers/net/appletalk/Kconfig b/drivers/net/appletalk/Kconfig --- a/drivers/net/appletalk/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/drivers/net/appletalk/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,6 +1,34 @@ # # Appletalk driver configuration # +config ATALK + tristate "Appletalk protocol support" + depends on NET + select LLC + ---help--- + AppleTalk is the protocol that Apple computers can use to communicate + on a network. If your Linux box is connected to such a network and you + wish to connect to it, say Y. You will need to use the netatalk package + so that your Linux box can act as a print and file server for Macs as + well as access AppleTalk printers. Check out + on the WWW for details. + EtherTalk is the name used for AppleTalk over Ethernet and the + cheaper and slower LocalTalk is AppleTalk over a proprietary Apple + network using serial links. EtherTalk and LocalTalk are fully + supported by Linux. + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . The + NET-3-HOWTO, available from + , contains valuable + information as well. + + To compile this driver as a module, choose M here: the module will be + called appletalk. You almost certainly want to compile it as a + module so you can restart your AppleTalk stack without rebooting + your machine. I hear that the GNU boycott of Apple is over, so + even politically correct people are allowed to say Y here. + config DEV_APPLETALK bool "Appletalk interfaces support" depends on ATALK diff -Nru a/net/8021q/Kconfig b/net/8021q/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/8021q/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,21 @@ +# +# Configuration for 802.1Q VLAN support +# + +config VLAN_8021Q + tristate "802.1Q VLAN Support" + ---help--- + Select this and you will be able to create 802.1Q VLAN interfaces + on your ethernet interfaces. 802.1Q VLAN supports almost + everything a regular ethernet interface does, including + firewalling, bridging, and of course IP traffic. You will need + the 'vconfig' tool from the VLAN project in order to effectively + use VLANs. See the VLAN web page for more information: + + + To compile this code as a module, choose M here: the module + will be called 8021q. + + If unsure, say N. + + diff -Nru a/net/Kconfig b/net/Kconfig --- a/net/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/Kconfig 2005-04-04 21:41:57 +02:00 @@ -2,7 +2,7 @@ # Network configuration # -menu "Networking support" +menu "Networking" config NET bool "Networking support" @@ -10,7 +10,9 @@ Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even when running on a stand-alone machine that isn't connected to any - other computer. If you are upgrading from an older kernel, you + other computer. + + If you are upgrading from an older kernel, you should consider updating your networking tools too because changes in the kernel and the tools often go hand in hand. The tools are contained in the package net-tools, the location and version number @@ -20,57 +22,9 @@ recommended to read the NET-HOWTO, available from . -menu "Networking options" - depends on NET - -config PACKET - tristate "Packet socket" - ---help--- - The Packet protocol is used by applications which communicate - directly with network devices without an intermediate network - protocol implemented in the kernel, e.g. tcpdump. If you want them - to work, choose Y. - - To compile this driver as a module, choose M here: the module will - be called af_packet. - - If unsure, say Y. - -config PACKET_MMAP - bool "Packet socket: mmapped IO" - depends on PACKET - help - If you say Y here, the Packet protocol driver will use an IO - mechanism that results in faster communication. - - If unsure, say N. - -config UNIX - tristate "Unix domain sockets" - ---help--- - If you say Y here, you will include support for Unix domain sockets; - sockets are the standard Unix mechanism for establishing and - accessing network connections. Many commonly used programs such as - the X Window system and syslog use these sockets even if your - machine is not connected to any network. Unless you are working on - an embedded system or something similar, you therefore definitely - want to say Y here. - - To compile this driver as a module, choose M here: the module will be - called unix. Note that several important services won't work - correctly if you say M here and then neglect to load the module. - - Say Y unless you know what you are doing. - -config NET_KEY - tristate "PF_KEY sockets" - select XFRM - ---help--- - PF_KEYv2 socket family, compatible to KAME ones. - They are required if you are going to use IPsec tools ported - from KAME. +if NET - Say Y unless you know what you are doing. +menu "Networking protocols" config INET bool "TCP/IP networking" @@ -94,31 +48,29 @@ Short answer: say Y. +if INET source "net/ipv4/Kconfig" +source "net/ipv6/Kconfig" +source "net/sctp/Kconfig" +endif -# IPv6 as module will cause a CRASH if you try to unload it -config IPV6 - tristate "The IPv6 protocol" - depends on INET - default m - select CRYPTO if IPV6_PRIVACY - select CRYPTO_MD5 if IPV6_PRIVACY - ---help--- - This is complemental support for the IP version 6. - You will still be able to do traditional IPv4 networking as well. - - For general information about IPv6, see - . - For Linux IPv6 development information, see . - For specific information about IPv6 under Linux, read the HOWTO at - . +source "net/decnet/Kconfig" +source "net/llc/Kconfig" +source "net/ipx/Kconfig" +source "drivers/net/appletalk/Kconfig" +source "net/x25/Kconfig" +source "net/lapb/Kconfig" +source "net/econet/Kconfig" +source "net/ax25/Kconfig" +source "net/irda/Kconfig" +source "net/bluetooth/Kconfig" - To compile this protocol support as a module, choose M here: the - module will be called ipv6. +endmenu +# end options and protocols -source "net/ipv6/Kconfig" +menu "Network packet filtering" -menuconfig NETFILTER +config NETFILTER bool "Network packet filtering (replaces ipchains)" ---help--- Netfilter is a framework for filtering and mangling network packets @@ -205,442 +157,37 @@ source "net/bridge/netfilter/Kconfig" endif +endmenu +# end netfilter + +source "net/sched/Kconfig" +source "net/core/Kconfig" + config XFRM bool - depends on NET source "net/xfrm/Kconfig" -source "net/sctp/Kconfig" - -config ATM - tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - ATM is a high-speed networking technology for Local Area Networks - and Wide Area Networks. It uses a fixed packet size and is - connection oriented, allowing for the negotiation of minimum - bandwidth requirements. - - In order to participate in an ATM network, your Linux box needs an - ATM networking card. If you have that, say Y here and to the driver - of your ATM card below. - - Note that you need a set of user-space programs to actually make use - of ATM. See the file for - further details. - -config ATM_CLIP - tristate "Classical IP over ATM (EXPERIMENTAL)" - depends on ATM && INET - help - Classical IP over ATM for PVCs and SVCs, supporting InARP and - ATMARP. If you want to communication with other IP hosts on your ATM - network, you will typically either say Y here or to "LAN Emulation - (LANE)" below. - -config ATM_CLIP_NO_ICMP - bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" - depends on ATM_CLIP - help - Normally, an "ICMP host unreachable" message is sent if a neighbour - cannot be reached because there is no VC to it in the kernel's - ATMARP table. This may cause problems when ATMARP table entries are - briefly removed during revalidation. If you say Y here, packets to - such neighbours are silently discarded instead. - -config ATM_LANE - tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" - depends on ATM - help - LAN Emulation emulates services of existing LANs across an ATM - network. Besides operating as a normal ATM end station client, Linux - LANE client can also act as an proxy client bridging packets between - ELAN and Ethernet segments. You need LANE if you want to try MPOA. - -config ATM_MPOA - tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" - depends on ATM && INET && ATM_LANE!=n - help - Multi-Protocol Over ATM allows ATM edge devices such as routers, - bridges and ATM attached hosts establish direct ATM VCs across - subnetwork boundaries. These shortcut connections bypass routers - enhancing overall network performance. - -config ATM_BR2684 - tristate "RFC1483/2684 Bridged protocols" - depends on ATM && INET - help - ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) - This device will act like an ethernet from the kernels point of view, - with the traffic being carried by ATM PVCs (currently 1 PVC/device). - This is sometimes used over DSL lines. If in doubt, say N. - -config ATM_BR2684_IPFILTER - bool "Per-VC IP filter kludge" - depends on ATM_BR2684 - help - This is an experimental mechanism for users who need to terminating a - large number of IP-only vcc's. Do not enable this unless you are sure - you know what you are doing. - -config BRIDGE - tristate "802.1d Ethernet Bridging" - ---help--- - If you say Y here, then your Linux box will be able to act as an - Ethernet bridge, which means that the different Ethernet segments it - is connected to will appear as one Ethernet to the participants. - Several such bridges can work together to create even larger - networks of Ethernets using the IEEE 802.1 spanning tree algorithm. - As this is a standard, Linux bridges will cooperate properly with - other third party bridge products. - - In order to use the Ethernet bridge, you'll need the bridge - configuration tools; see - for location. Please read the Bridge mini-HOWTO for more - information. - - If you enable iptables support along with the bridge support then you - turn your bridge into a bridging IP firewall. - iptables will then see the IP packets being bridged, so you need to - take this into account when setting up your firewall rules. - Enabling arptables support when bridging will let arptables see - bridged ARP traffic in the arptables FORWARD chain. - - To compile this code as a module, choose M here: the module - will be called bridge. - - If unsure, say N. - -config VLAN_8021Q - tristate "802.1Q VLAN Support" - ---help--- - Select this and you will be able to create 802.1Q VLAN interfaces - on your ethernet interfaces. 802.1Q VLAN supports almost - everything a regular ethernet interface does, including - firewalling, bridging, and of course IP traffic. You will need - the 'vconfig' tool from the VLAN project in order to effectively - use VLANs. See the VLAN web page for more information: - - - To compile this code as a module, choose M here: the module - will be called 8021q. - - If unsure, say N. - -config DECNET - tristate "DECnet Support" - ---help--- - The DECnet networking protocol was used in many products made by - Digital (now Compaq). It provides reliable stream and sequenced - packet communications over which run a variety of services similar - to those which run over TCP/IP. - - To find some tools to use with the kernel layer support, please - look at Patrick Caulfield's web site: - . - - More detailed documentation is available in - . - - Be sure to say Y to "/proc file system support" and "Sysctl support" - below when using DECnet, since you will need sysctl support to aid - in configuration at run time. - - The DECnet code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module is called decnet. - -source "net/decnet/Kconfig" - -source "net/llc/Kconfig" - -config IPX - tristate "The IPX protocol" - select LLC - ---help--- - This is support for the Novell networking protocol, IPX, commonly - used for local networks of Windows machines. You need it if you - want to access Novell NetWare file or print servers using the Linux - Novell client ncpfs (available from - ) or from - within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, - available from ). In order - to do the former, you'll also have to say Y to "NCP file system - support", below. - - IPX is similar in scope to IP, while SPX, which runs on top of IPX, - is similar to TCP. There is also experimental support for SPX in - Linux (see "SPX networking", below). - - To turn your Linux box into a fully featured NetWare file server and - IPX router, say Y here and fetch either lwared from - or - mars_nwe from . For more - information, read the IPX-HOWTO available from - . - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . - - The IPX driver would enlarge your kernel by about 16 KB. To compile - this driver as a module, choose M here: the module will be called ipx. - Unless you want to integrate your Linux box with a local Novell - network, say N. - -source "net/ipx/Kconfig" - -config ATALK - tristate "Appletalk protocol support" - select LLC - ---help--- - AppleTalk is the protocol that Apple computers can use to communicate - on a network. If your Linux box is connected to such a network and you - wish to connect to it, say Y. You will need to use the netatalk package - so that your Linux box can act as a print and file server for Macs as - well as access AppleTalk printers. Check out - on the WWW for details. - EtherTalk is the name used for AppleTalk over Ethernet and the - cheaper and slower LocalTalk is AppleTalk over a proprietary Apple - network using serial links. EtherTalk and LocalTalk are fully - supported by Linux. - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . The - NET-3-HOWTO, available from - , contains valuable - information as well. - - To compile this driver as a module, choose M here: the module will be - called appletalk. You almost certainly want to compile it as a - module so you can restart your AppleTalk stack without rebooting - your machine. I hear that the GNU boycott of Apple is over, so - even politically correct people are allowed to say Y here. - -source "drivers/net/appletalk/Kconfig" - -config X25 - tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - X.25 is a set of standardized network protocols, similar in scope to - frame relay; the one physical line from your box to the X.25 network - entry point can carry several logical point-to-point connections - (called "virtual circuits") to other computers connected to the X.25 - network. Governments, banks, and other organizations tend to use it - to connect to each other or to form Wide Area Networks (WANs). Many - countries have public X.25 networks. X.25 consists of two - protocols: the higher level Packet Layer Protocol (PLP) (say Y here - if you want that) and the lower level data link layer protocol LAPB - (say Y to "LAPB Data Link Driver" below if you want that). - - You can read more about X.25 at and - . - Information about X.25 for Linux is contained in the files - and - . - - One connects to an X.25 network either with a dedicated network card - using the X.21 protocol (not yet supported by Linux) or one can do - X.25 over a standard telephone line using an ordinary modem (say Y - to "X.25 async driver" below) or over Ethernet using an ordinary - Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link - Driver" and "LAPB over Ethernet driver" below). - - To compile this driver as a module, choose M here: the module - will be called x25. If unsure, say N. - -config LAPB - tristate "LAPB Data Link Driver (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. - the lower) part of the X.25 protocol. It offers a reliable - connection service to exchange data frames with one other host, and - it is used to transport higher level protocols (mostly X.25 Packet - Layer, the higher part of X.25, but others are possible as well). - Usually, LAPB is used with specialized X.21 network cards, but Linux - currently supports LAPB only over Ethernet connections. If you want - to use LAPB connections over Ethernet, say Y here and to "LAPB over - Ethernet driver" below. Read - for technical - details. - - To compile this driver as a module, choose M here: the - module will be called lapb. If unsure, say N. - -config NET_DIVERT - bool "Frame Diverter (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - The Frame Diverter allows you to divert packets from the - network, that are not aimed at the interface receiving it (in - promisc. mode). Typically, a Linux box setup as an Ethernet bridge - with the Frames Diverter on, can do some *really* transparent www - caching using a Squid proxy for example. - - This is very useful when you don't want to change your router's - config (or if you simply don't have access to it). - - The other possible usages of diverting Ethernet Frames are - numberous: - - reroute smtp traffic to another interface - - traffic-shape certain network streams - - transparently proxy smtp connections - - etc... - - For more informations, please refer to: - - - - If unsure, say N. - -config ECONET - tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" - depends on EXPERIMENTAL && INET - ---help--- - Econet is a fairly old and slow networking protocol mainly used by - Acorn computers to access file and print servers. It uses native - Econet network cards. AUN is an implementation of the higher level - parts of Econet that runs over ordinary Ethernet connections, on - top of the UDP packet protocol, which in turn runs on top of the - Internet protocol IP. - - If you say Y here, you can choose with the next two options whether - to send Econet/AUN traffic over a UDP Ethernet connection or over - a native Econet network card. - - To compile this driver as a module, choose M here: the module - will be called econet. - -config ECONET_AUNUDP - bool "AUN over UDP" - depends on ECONET - help - Say Y here if you want to send Econet/AUN traffic over a UDP - connection (UDP is a packet based protocol that runs on top of the - Internet protocol IP) using an ordinary Ethernet network card. - -config ECONET_NATIVE - bool "Native Econet" - depends on ECONET - help - Say Y here if you have a native Econet network card installed in - your computer. - -config WAN_ROUTER - tristate "WAN router" - depends on EXPERIMENTAL - ---help--- - Wide Area Networks (WANs), such as X.25, frame relay and leased - lines, are used to interconnect Local Area Networks (LANs) over vast - distances with data transfer rates significantly higher than those - achievable with commonly used asynchronous modem connections. - Usually, a quite expensive external device called a `WAN router' is - needed to connect to a WAN. - - As an alternative, WAN routing can be built into the Linux kernel. - With relatively inexpensive WAN interface cards available on the - market, a perfectly usable router can be built for less than half - the price of an external router. If you have one of those cards and - wish to use your Linux box as a WAN router, say Y here and also to - the WAN driver for your card, below. You will then need the - wan-tools package which is available from . - Read for more - information. - - To compile WAN routing support as a module, choose M here: the - module will be called wanrouter. - - If unsure, say N. - -menu "QoS and/or fair queueing" - -config NET_SCHED - bool "QoS and/or fair queueing" - ---help--- - When the kernel has several packets to send out over a network - device, it has to decide which ones to send first, which ones to - delay, and which ones to drop. This is the job of the packet - scheduler, and several different algorithms for how to do this - "fairly" have been proposed. - - If you say N here, you will get the standard packet scheduler, which - is a FIFO (first come, first served). If you say Y here, you will be - able to choose from among several alternative algorithms which can - then be attached to different network devices. This is useful for - example if some of your network devices are real time devices that - need a certain minimum data flow rate, or if you need to limit the - maximum data flow rate for traffic which matches specified criteria. - This code is considered to be experimental. - - To administer these schedulers, you'll need the user-level utilities - from the package iproute2+tc at . - That package also contains some documentation; for more, check out - . - - This Quality of Service (QoS) support will enable you to use - Differentiated Services (diffserv) and Resource Reservation Protocol - (RSVP) on your Linux router if you also say Y to "QoS support", - "Packet classifier API" and to some classifiers below. Documentation - and software is at . - - If you say Y here and to "/proc file system" below, you will be able - to read status information about packet schedulers from the file - /proc/net/psched. - - The available schedulers are listed in the following questions; you - can say Y to as many as you like. If unsure, say N now. - -source "net/sched/Kconfig" - -endmenu - -menu "Network testing" - -config NET_PKTGEN - tristate "Packet Generator (USE WITH CAUTION)" - depends on PROC_FS +config NET_KEY + tristate "PF_KEY sockets" + select XFRM ---help--- - This module will inject preconfigured packets, at a configurable - rate, out of a given interface. It is used for network interface - stress testing and performance analysis. If you don't understand - what was just said, you don't need it: say N. - - Documentation on how to use the packet generator can be found - at . - - To compile this code as a module, choose M here: the - module will be called pktgen. - -endmenu - -endmenu - -config NETPOLL - def_bool NETCONSOLE - -config NETPOLL_RX - bool "Netpoll support for trapping incoming packets" - default n - depends on NETPOLL - -config NETPOLL_TRAP - bool "Netpoll traffic trapping" - default n - depends on NETPOLL - -config NET_POLL_CONTROLLER - def_bool NETPOLL + PF_KEYv2 socket family, compatible to KAME ones. + They are required if you are going to use IPsec tools ported + from KAME. -source "net/ax25/Kconfig" + Say Y unless you know what you are doing. -source "net/irda/Kconfig" -source "net/bluetooth/Kconfig" +source "net/packet/Kconfig" +source "net/unix/Kconfig" +source "net/bridge/Kconfig" +source "net/8021q/Kconfig" +source "net/wanrouter/Kconfig" -source "drivers/net/Kconfig" +endif +# NET endmenu diff -Nru a/net/atm/Kconfig b/net/atm/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/atm/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,77 @@ +# +# ATM Configarition +# + +config ATM + tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" + depends on EXPERIMENTAL + depends on NET + ---help--- + ATM is a high-speed networking technology for Local Area Networks + and Wide Area Networks. It uses a fixed packet size and is + connection oriented, allowing for the negotiation of minimum + bandwidth requirements. + + In order to participate in an ATM network, your Linux box needs an + ATM networking card. If you have that, say Y here and to the driver + of your ATM card below. + + Note that you need a set of user-space programs to actually make use + of ATM. See the file for + further details. + +config ATM_CLIP + tristate "Classical IP over ATM (EXPERIMENTAL)" + depends on ATM && INET + help + Classical IP over ATM for PVCs and SVCs, supporting InARP and + ATMARP. If you want to communication with other IP hosts on your ATM + network, you will typically either say Y here or to "LAN Emulation + (LANE)" below. + +config ATM_CLIP_NO_ICMP + bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" + depends on ATM_CLIP + help + Normally, an "ICMP host unreachable" message is sent if a neighbour + cannot be reached because there is no VC to it in the kernel's + ATMARP table. This may cause problems when ATMARP table entries are + briefly removed during revalidation. If you say Y here, packets to + such neighbours are silently discarded instead. + +config ATM_LANE + tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" + depends on ATM + help + LAN Emulation emulates services of existing LANs across an ATM + network. Besides operating as a normal ATM end station client, Linux + LANE client can also act as an proxy client bridging packets between + ELAN and Ethernet segments. You need LANE if you want to try MPOA. + +config ATM_MPOA + tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" + depends on ATM && INET && ATM_LANE!=n + help + Multi-Protocol Over ATM allows ATM edge devices such as routers, + bridges and ATM attached hosts establish direct ATM VCs across + subnetwork boundaries. These shortcut connections bypass routers + enhancing overall network performance. + +config ATM_BR2684 + tristate "RFC1483/2684 Bridged protocols" + depends on ATM && INET + help + ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) + This device will act like an ethernet from the kernels point of view, + with the traffic being carried by ATM PVCs (currently 1 PVC/device). + This is sometimes used over DSL lines. If in doubt, say N. + +config ATM_BR2684_IPFILTER + bool "Per-VC IP filter kludge" + depends on ATM_BR2684 + help + This is an experimental mechanism for users who need to terminating a + large number of IP-only vcc's. Do not enable this unless you are sure + you know what you are doing. + + diff -Nru a/net/bridge/Kconfig b/net/bridge/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/bridge/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,32 @@ +# +# Configuration for Ethernet bridging +# + +config BRIDGE + tristate "802.1d Ethernet Bridging" + ---help--- + If you say Y here, then your Linux box will be able to act as an + Ethernet bridge, which means that the different Ethernet segments it + is connected to will appear as one Ethernet to the participants. + Several such bridges can work together to create even larger + networks of Ethernets using the IEEE 802.1 spanning tree algorithm. + As this is a standard, Linux bridges will cooperate properly with + other third party bridge products. + + In order to use the Ethernet bridge, you'll need the bridge + configuration tools; see + for location. Please read the Bridge mini-HOWTO for more + information. + + If you enable iptables support along with the bridge support then you + turn your bridge into a bridging IP firewall. + iptables will then see the IP packets being bridged, so you need to + take this into account when setting up your firewall rules. + Enabling arptables support when bridging will let arptables see + bridged ARP traffic in the arptables FORWARD chain. + + To compile this code as a module, choose M here: the module + will be called bridge. + + If unsure, say N. + diff -Nru a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig --- a/net/bridge/netfilter/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/bridge/netfilter/Kconfig 2005-04-04 21:41:57 +02:00 @@ -139,6 +139,7 @@ config BRIDGE_EBT_ARPREPLY tristate "ebt: arp reply target support" depends on BRIDGE_NF_EBTABLES + depends on INET help This option adds the arp reply target, which allows automatically sending arp replies to arp requests. diff -Nru a/net/core/Kconfig b/net/core/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/core/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,67 @@ +# +# Core configuration +# + +menu "Network testing" + +config NET_PKTGEN + tristate "Packet Generator (USE WITH CAUTION)" + depends on PROC_FS + depends on INET + ---help--- + This module will inject preconfigured packets, at a configurable + rate, out of a given interface. It is used for network interface + stress testing and performance analysis. If you don't understand + what was just said, you don't need it: say N. + + Documentation on how to use the packet generator can be found + at . + + To compile this code as a module, choose M here: the + module will be called pktgen. + +endmenu + +config NETPOLL + def_bool NETCONSOLE + +config NETPOLL_RX + bool "Netpoll support for trapping incoming packets" + default n + depends on NETPOLL + +config NETPOLL_TRAP + bool "Netpoll traffic trapping" + default n + depends on NETPOLL + +config NET_POLL_CONTROLLER + def_bool NETPOLL + +config NET_DIVERT + bool "Frame Diverter (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + The Frame Diverter allows you to divert packets from the + network, that are not aimed at the interface receiving it (in + promisc. mode). Typically, a Linux box setup as an Ethernet bridge + with the Frames Diverter on, can do some *really* transparent www + caching using a Squid proxy for example. + + This is very useful when you don't want to change your router's + config (or if you simply don't have access to it). + + The other possible usages of diverting Ethernet Frames are + numberous: + - reroute smtp traffic to another interface + - traffic-shape certain network streams + - transparently proxy smtp connections + - etc... + + For more informations, please refer to: + + + + If unsure, say N. + + diff -Nru a/net/decnet/Kconfig b/net/decnet/Kconfig --- a/net/decnet/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/decnet/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,6 +1,30 @@ # # DECnet configuration # + +config DECNET + tristate "DECnet Support" + ---help--- + The DECnet networking protocol was used in many products made by + Digital (now Compaq). It provides reliable stream and sequenced + packet communications over which run a variety of services similar + to those which run over TCP/IP. + + To find some tools to use with the kernel layer support, please + look at Patrick Caulfield's web site: + . + + More detailed documentation is available in + . + + Be sure to say Y to "/proc file system support" and "Sysctl support" + below when using DECnet, since you will need sysctl support to aid + in configuration at run time. + + The DECnet code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called decnet. + config DECNET_ROUTER bool "DECnet: router support (EXPERIMENTAL)" depends on DECNET && EXPERIMENTAL diff -Nru a/net/econet/Kconfig b/net/econet/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/econet/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,34 @@ + +config ECONET + tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" + depends on EXPERIMENTAL && INET + ---help--- + Econet is a fairly old and slow networking protocol mainly used by + Acorn computers to access file and print servers. It uses native + Econet network cards. AUN is an implementation of the higher level + parts of Econet that runs over ordinary Ethernet connections, on + top of the UDP packet protocol, which in turn runs on top of the + Internet protocol IP. + + If you say Y here, you can choose with the next two options whether + to send Econet/AUN traffic over a UDP Ethernet connection or over + a native Econet network card. + + To compile this driver as a module, choose M here: the module + will be called econet. + +config ECONET_AUNUDP + bool "AUN over UDP" + depends on ECONET + help + Say Y here if you want to send Econet/AUN traffic over a UDP + connection (UDP is a packet based protocol that runs on top of the + Internet protocol IP) using an ordinary Ethernet network card. + +config ECONET_NATIVE + bool "Native Econet" + depends on ECONET + help + Say Y here if you have a native Econet network card installed in + your computer. + diff -Nru a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig --- a/net/ipv4/netfilter/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/ipv4/netfilter/Kconfig 2005-04-04 21:41:57 +02:00 @@ -2,9 +2,6 @@ # IP netfilter configuration # -menu "IP: Netfilter Configuration" - depends on INET && NETFILTER - # connection tracking, helpers and protocols config IP_NF_CONNTRACK tristate "Connection tracking (required for masq/NAT)" @@ -691,6 +688,4 @@ help Allows altering the ARP packet payload: source and destination hardware and network addresses. - -endmenu diff -Nru a/net/ipv6/Kconfig b/net/ipv6/Kconfig --- a/net/ipv6/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/ipv6/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,6 +1,26 @@ # # IPv6 configuration # + +# IPv6 as module will cause a CRASH if you try to unload it +config IPV6 + tristate "The IPv6 protocol" + default m + select CRYPTO if IPV6_PRIVACY + select CRYPTO_MD5 if IPV6_PRIVACY + ---help--- + This is complemental support for the IP version 6. + You will still be able to do traditional IPv4 networking as well. + + For general information about IPv6, see + . + For Linux IPv6 development information, see . + For specific information about IPv6 under Linux, read the HOWTO at + . + + To compile this protocol support as a module, choose M here: the + module will be called ipv6. + config IPV6_PRIVACY bool "IPv6: Privacy Extensions (RFC 3041) support" depends on IPV6 diff -Nru a/net/ipx/Kconfig b/net/ipx/Kconfig --- a/net/ipx/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/ipx/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,6 +1,39 @@ # # IPX configuration # +config IPX + tristate "The IPX protocol" + select LLC + ---help--- + This is support for the Novell networking protocol, IPX, commonly + used for local networks of Windows machines. You need it if you + want to access Novell NetWare file or print servers using the Linux + Novell client ncpfs (available from + ) or from + within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, + available from ). In order + to do the former, you'll also have to say Y to "NCP file system + support", below. + + IPX is similar in scope to IP, while SPX, which runs on top of IPX, + is similar to TCP. There is also experimental support for SPX in + Linux (see "SPX networking", below). + + To turn your Linux box into a fully featured NetWare file server and + IPX router, say Y here and fetch either lwared from + or + mars_nwe from . For more + information, read the IPX-HOWTO available from + . + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . + + The IPX driver would enlarge your kernel by about 16 KB. To compile + this driver as a module, choose M here: the module will be called ipx. + Unless you want to integrate your Linux box with a local Novell + network, say N. + config IPX_INTERN bool "IPX: Full internal IPX network" depends on IPX diff -Nru a/net/lapb/Kconfig b/net/lapb/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/lapb/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,24 @@ +# +# LAPB Configuration +# + +config LAPB + tristate "LAPB Data Link Driver (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. + the lower) part of the X.25 protocol. It offers a reliable + connection service to exchange data frames with one other host, and + it is used to transport higher level protocols (mostly X.25 Packet + Layer, the higher part of X.25, but others are possible as well). + Usually, LAPB is used with specialized X.21 network cards, but Linux + currently supports LAPB only over Ethernet connections. If you want + to use LAPB connections over Ethernet, say Y here and to "LAPB over + Ethernet driver" below. Read + for technical + details. + + To compile this driver as a module, choose M here: the + module will be called lapb. If unsure, say N. + + diff -Nru a/net/packet/Kconfig b/net/packet/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/packet/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,26 @@ +# +# Packet configuration +# + +config PACKET + tristate "Packet socket" + ---help--- + The Packet protocol is used by applications which communicate + directly with network devices without an intermediate network + protocol implemented in the kernel, e.g. tcpdump. If you want them + to work, choose Y. + + To compile this driver as a module, choose M here: the module will + be called af_packet. + + If unsure, say Y. + +config PACKET_MMAP + bool "Packet socket: mmapped IO" + depends on PACKET + help + If you say Y here, the Packet protocol driver will use an IO + mechanism that results in faster communication. + + If unsure, say N. + diff -Nru a/net/sched/Kconfig b/net/sched/Kconfig --- a/net/sched/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/sched/Kconfig 2005-04-04 21:41:57 +02:00 @@ -1,6 +1,45 @@ # # Traffic control configuration. # + +menu "QoS and/or fair quiueing" + +config NET_SCHED + bool "QoS and/or fair queueing" + ---help--- + When the kernel has several packets to send out over a network + device, it has to decide which ones to send first, which ones to + delay, and which ones to drop. This is the job of the packet + scheduler, and several different algorithms for how to do this + "fairly" have been proposed. + + If you say N here, you will get the standard packet scheduler, which + is a FIFO (first come, first served). If you say Y here, you will be + able to choose from among several alternative algorithms which can + then be attached to different network devices. This is useful for + example if some of your network devices are real time devices that + need a certain minimum data flow rate, or if you need to limit the + maximum data flow rate for traffic which matches specified criteria. + This code is considered to be experimental. + + To administer these schedulers, you'll need the user-level utilities + from the package iproute2+tc at . + That package also contains some documentation; for more, check out + . + + This Quality of Service (QoS) support will enable you to use + Differentiated Services (diffserv) and Resource Reservation Protocol + (RSVP) on your Linux router if you also say Y to "QoS support", + "Packet classifier API" and to some classifiers below. Documentation + and software is at . + + If you say Y here and to "/proc file system" below, you will be able + to read status information about packet schedulers from the file + /proc/net/psched. + + The available schedulers are listed in the following questions; you + can say Y to as many as you like. If unsure, say N now. + choice prompt "Packet scheduler clock source" depends on NET_SCHED @@ -506,3 +545,4 @@ Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. +endmenu diff -Nru a/net/sctp/Kconfig b/net/sctp/Kconfig --- a/net/sctp/Kconfig 2005-04-04 21:41:57 +02:00 +++ b/net/sctp/Kconfig 2005-04-04 21:41:57 +02:00 @@ -2,12 +2,8 @@ # SCTP configuration # -menu "SCTP Configuration (EXPERIMENTAL)" - depends on INET && EXPERIMENTAL - config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" - depends on IPV6 || IPV6=n select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 select CRYPTO_SHA1 if SCTP_HMAC_SHA1 @@ -86,4 +82,3 @@ advised to use either HMAC-MD5 or HMAC-SHA1. endchoice -endmenu diff -Nru a/net/unix/Kconfig b/net/unix/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/unix/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,22 @@ +# +# Configuration for Unix domain sockets +# + +config UNIX + tristate "Unix domain sockets" + ---help--- + If you say Y here, you will include support for Unix domain sockets; + sockets are the standard Unix mechanism for establishing and + accessing network connections. Many commonly used programs such as + the X Window system and syslog use these sockets even if your + machine is not connected to any network. Unless you are working on + an embedded system or something similar, you therefore definitely + want to say Y here. + + To compile this driver as a module, choose M here: the module will be + called unix. Note that several important services won't work + correctly if you say M here and then neglect to load the module. + + Say Y unless you know what you are doing. + + diff -Nru a/net/wanrouter/Kconfig b/net/wanrouter/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/wanrouter/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,31 @@ +# +# Configuration for WAN Router +# + +config WAN_ROUTER + tristate "WAN router" + depends on EXPERIMENTAL + ---help--- + Wide Area Networks (WANs), such as X.25, frame relay and leased + lines, are used to interconnect Local Area Networks (LANs) over vast + distances with data transfer rates significantly higher than those + achievable with commonly used asynchronous modem connections. + Usually, a quite expensive external device called a `WAN router' is + needed to connect to a WAN. + + As an alternative, WAN routing can be built into the Linux kernel. + With relatively inexpensive WAN interface cards available on the + market, a perfectly usable router can be built for less than half + the price of an external router. If you have one of those cards and + wish to use your Linux box as a WAN router, say Y here and also to + the WAN driver for your card, below. You will then need the + wan-tools package which is available from . + Read for more + information. + + To compile WAN routing support as a module, choose M here: the + module will be called wanrouter. + + If unsure, say N. + + diff -Nru a/net/x25/Kconfig b/net/x25/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/x25/Kconfig 2005-04-04 21:41:57 +02:00 @@ -0,0 +1,35 @@ +# +# X25 Configuration +# + +config X25 + tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + X.25 is a set of standardized network protocols, similar in scope to + frame relay; the one physical line from your box to the X.25 network + entry point can carry several logical point-to-point connections + (called "virtual circuits") to other computers connected to the X.25 + network. Governments, banks, and other organizations tend to use it + to connect to each other or to form Wide Area Networks (WANs). Many + countries have public X.25 networks. X.25 consists of two + protocols: the higher level Packet Layer Protocol (PLP) (say Y here + if you want that) and the lower level data link layer protocol LAPB + (say Y to "LAPB Data Link Driver" below if you want that). + + You can read more about X.25 at and + . + Information about X.25 for Linux is contained in the files + and + . + + One connects to an X.25 network either with a dedicated network card + using the X.21 protocol (not yet supported by Linux) or one can do + X.25 over a standard telephone line using an ordinary modem (say Y + to "X.25 async driver" below) or over Ethernet using an ordinary + Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link + Driver" and "LAPB over Ethernet driver" below). + + To compile this driver as a module, choose M here: the module + will be called x25. If unsure, say N. + From acme@ghostprotocols.net Mon Apr 4 12:50:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 12:50:49 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34JoWda022536 for ; Mon, 4 Apr 2005 12:50:37 -0700 Received: from [200.138.131.177] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DIXbp-0005JQ-00; Mon, 04 Apr 2005 16:51:41 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id D673E14631; Mon, 4 Apr 2005 16:50:30 -0300 (BRT) Date: Mon, 4 Apr 2005 16:50:30 -0300 To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH 2/2][AX25] make ax25_queue_xmit a net_device parameter Message-ID: <20050404195030.GJ640@conectiva.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi David, Ralf, I'm trying to get back to the work of reducing the number of direct references to skb->{h,nh,raw}, that eventually will become just a void pointer. Available at: bk://kernel.bkbits.net/acme/sk_buff-2.6 Regards, - Arnaldo --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ax25.2.patch" =================================================================== ChangeSet@1.2246, 2005-04-04 16:28:37-03:00, acme@toy.ghostprotocols.net [AX25] Introduce ax25_type_trans Replacing the open coded equivalents and making ax25 look more like a linux network protocol, i.e. more similar to inet. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ralf Baechle Signed-off-by: David S. Miller drivers/net/hamradio/6pack.c | 4 +--- drivers/net/hamradio/baycom_epp.c | 4 +--- drivers/net/hamradio/bpqether.c | 10 ++-------- drivers/net/hamradio/dmascc.c | 4 +--- drivers/net/hamradio/hdlcdrv.c | 4 +--- drivers/net/hamradio/mkiss.c | 4 +--- drivers/net/hamradio/scc.c | 5 +---- drivers/net/hamradio/yam.c | 4 +--- include/net/ax25.h | 8 ++++++++ net/ax25/ax25_ds_subr.c | 3 +-- net/ax25/ax25_out.c | 3 +-- 11 files changed, 19 insertions(+), 34 deletions(-) diff -Nru a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c --- a/drivers/net/hamradio/6pack.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/6pack.c 2005-04-04 16:44:28 -03:00 @@ -394,13 +394,11 @@ if ((skb = dev_alloc_skb(count)) == NULL) goto out_mem; - skb->dev = sp->dev; ptr = skb_put(skb, count); *ptr++ = cmd; /* KISS command */ memcpy(ptr, sp->cooked_buf + 1, count); - skb->mac.raw = skb->data; - skb->protocol = htons(ETH_P_AX25); + skb->protocol = ax25_type_trans(skb, sp->dev); netif_rx(skb); sp->dev->last_rx = jiffies; sp->stats.rx_packets++; diff -Nru a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c --- a/drivers/net/hamradio/baycom_epp.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/baycom_epp.c 2005-04-04 16:44:28 -03:00 @@ -601,12 +601,10 @@ bc->stats.rx_dropped++; return; } - skb->dev = dev; cp = skb_put(skb, pktlen); *cp++ = 0; /* KISS kludge */ memcpy(cp, bc->hdlcrx.buf, pktlen - 1); - skb->protocol = htons(ETH_P_AX25); - skb->mac.raw = skb->data; + skb->protocol = ax25_type_trans(skb, dev); netif_rx(skb); dev->last_rx = jiffies; bc->stats.rx_packets++; diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/bpqether.c 2005-04-04 16:44:28 -03:00 @@ -211,11 +211,7 @@ ptr = skb_push(skb, 1); *ptr = 0; - skb->dev = dev; - skb->protocol = htons(ETH_P_AX25); - skb->mac.raw = skb->data; - skb->pkt_type = PACKET_HOST; - + skb->protocol = ax25_type_trans(skb, dev); netif_rx(skb); dev->last_rx = jiffies; unlock: @@ -272,8 +268,6 @@ skb = newskb; } - skb->protocol = htons(ETH_P_AX25); - ptr = skb_push(skb, 2); *ptr++ = (size + 5) % 256; @@ -287,7 +281,7 @@ return -ENODEV; } - skb->dev = dev; + skb->protocol = ax25_type_trans(skb, dev); skb->nh.raw = skb->data; dev->hard_header(skb, dev, ETH_P_BPQ, bpq->dest_addr, NULL, 0); bpq->stats.tx_packets++; diff -Nru a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c --- a/drivers/net/hamradio/dmascc.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/dmascc.c 2005-04-04 16:44:28 -03:00 @@ -1306,9 +1306,7 @@ data = skb_put(skb, cb + 1); data[0] = 0; memcpy(&data[1], priv->rx_buf[i], cb); - skb->dev = priv->dev; - skb->protocol = ntohs(ETH_P_AX25); - skb->mac.raw = skb->data; + skb->protocol = ax25_type_trans(skb, priv->dev); netif_rx(skb); priv->dev->last_rx = jiffies; priv->stats.rx_packets++; diff -Nru a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c --- a/drivers/net/hamradio/hdlcdrv.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/hdlcdrv.c 2005-04-04 16:44:28 -03:00 @@ -174,12 +174,10 @@ s->stats.rx_dropped++; return; } - skb->dev = dev; cp = skb_put(skb, pkt_len); *cp++ = 0; /* KISS kludge */ memcpy(cp, s->hdlcrx.buffer, pkt_len - 1); - skb->protocol = htons(ETH_P_AX25); - skb->mac.raw = skb->data; + skb->protocol = ax25_type_trans(skb, dev); netif_rx(skb); dev->last_rx = jiffies; s->stats.rx_packets++; diff -Nru a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c --- a/drivers/net/hamradio/mkiss.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/mkiss.c 2005-04-04 16:44:28 -03:00 @@ -332,12 +332,10 @@ return; } - skb->dev = ax->dev; spin_lock_bh(&ax->buflock); memcpy(skb_put(skb,count), ax->rbuff, count); spin_unlock_bh(&ax->buflock); - skb->mac.raw = skb->data; - skb->protocol = htons(ETH_P_AX25); + skb->protocol = ax25_type_trans(skb, ax->dev); netif_rx(skb); ax->dev->last_rx = jiffies; ax->rx_packets++; diff -Nru a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c --- a/drivers/net/hamradio/scc.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/scc.c 2005-04-04 16:44:28 -03:00 @@ -1630,10 +1630,7 @@ scc->dev_stat.rx_packets++; scc->dev_stat.rx_bytes += skb->len; - skb->dev = scc->dev; - skb->protocol = htons(ETH_P_AX25); - skb->mac.raw = skb->data; - skb->pkt_type = PACKET_HOST; + skb->protocol = ax25_type_trans(skb, scc->dev); netif_rx(skb); scc->dev->last_rx = jiffies; diff -Nru a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c --- a/drivers/net/hamradio/yam.c 2005-04-04 16:44:28 -03:00 +++ b/drivers/net/hamradio/yam.c 2005-04-04 16:44:28 -03:00 @@ -522,12 +522,10 @@ ++yp->stats.rx_dropped; } else { unsigned char *cp; - skb->dev = dev; cp = skb_put(skb, pkt_len); *cp++ = 0; /* KISS kludge */ memcpy(cp, yp->rx_buf, pkt_len - 1); - skb->protocol = htons(ETH_P_AX25); - skb->mac.raw = skb->data; + skb->protocol = ax25_type_trans(skb, dev); netif_rx(skb); dev->last_rx = jiffies; ++yp->stats.rx_packets; diff -Nru a/include/net/ax25.h b/include/net/ax25.h --- a/include/net/ax25.h 2005-04-04 16:44:28 -03:00 +++ b/include/net/ax25.h 2005-04-04 16:44:28 -03:00 @@ -220,6 +220,14 @@ } } +static inline unsigned short ax25_type_trans(struct sk_buff *skb, struct net_device *dev) +{ + skb->dev = dev; + skb->pkt_type = PACKET_HOST; + skb->mac.raw = skb->data; + return htons(ETH_P_AX25); +} + /* af_ax25.c */ extern struct hlist_head ax25_list; extern spinlock_t ax25_list_lock; diff -Nru a/net/ax25/ax25_ds_subr.c b/net/ax25/ax25_ds_subr.c --- a/net/ax25/ax25_ds_subr.c 2005-04-04 16:44:28 -03:00 +++ b/net/ax25/ax25_ds_subr.c 2005-04-04 16:44:28 -03:00 @@ -143,8 +143,7 @@ *p++ = cmd; *p++ = param; - skb->dev = ax25_dev->dev; - skb->protocol = htons(ETH_P_AX25); + skb->protocol = ax25_type_trans(skb, ax25_dev->dev); dev_queue_xmit(skb); } diff -Nru a/net/ax25/ax25_out.c b/net/ax25/ax25_out.c --- a/net/ax25/ax25_out.c 2005-04-04 16:44:28 -03:00 +++ b/net/ax25/ax25_out.c 2005-04-04 16:44:28 -03:00 @@ -351,8 +351,7 @@ { unsigned char *ptr; - skb->protocol = htons(ETH_P_AX25); - skb->dev = ax25_fwd_dev(dev); + skb->protocol = ax25_type_trans(skb, ax25_fwd_dev(dev)); ptr = skb_push(skb, 1); *ptr = 0x00; /* KISS */ --7ZAtKRhVyVSsbBD2-- From acme@ghostprotocols.net Mon Apr 4 12:52:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 12:52:57 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Jqj8f024314 for ; Mon, 4 Apr 2005 12:52:46 -0700 Received: from [200.138.131.177] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DIXdy-0005Jl-00; Mon, 04 Apr 2005 16:53:54 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 1962814631; Mon, 4 Apr 2005 16:52:44 -0300 (BRT) Date: Mon, 4 Apr 2005 16:52:44 -0300 To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [AX25] Introduce ax25_type_trans. was Re: [PATCH 2/2][AX25] make ax25_queue_xmit a net_device parameter Message-ID: <20050404195243.GK640@conectiva.com.br> References: <20050404195030.GJ640@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050404195030.GJ640@conectiva.com.br> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev Sorry, this one got the same subject as the previous one, it should have been "[AX25] Introduce ax25_type_trans". - Arnaldo From hadi@cyberus.ca Mon Apr 4 13:12:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 13:12:05 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34KC1tM032714 for ; Mon, 4 Apr 2005 13:12:01 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DIXvN-0005Mq-Ui for netdev@oss.sgi.com; Mon, 04 Apr 2005 14:11:53 -0600 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIXvC-0002rh-Cy; Mon, 04 Apr 2005 16:11:42 -0400 Subject: Re: [PATCH 2/2][AX25] make ax25_queue_xmit a net_device parameter From: jamal Reply-To: hadi@cyberus.ca To: Arnaldo Carvalho de Melo Cc: "David S. Miller" , Ralf Baechle , netdev In-Reply-To: <20050404195030.GJ640@conectiva.com.br> References: <20050404195030.GJ640@conectiva.com.br> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112645495.1078.40.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 16:11:36 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1373 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 You probably wanna set skb->input_dev in ax25_type_trans() as well something like: skb->input_dev = skb->dev = dev cheers, jamal On Mon, 2005-04-04 at 15:50, Arnaldo Carvalho de Melo wrote: > Hi David, Ralf, > > I'm trying to get back to the work of reducing the number of direct > references to skb->{h,nh,raw}, that eventually will become just a void > pointer. > > Available at: > > bk://kernel.bkbits.net/acme/sk_buff-2.6 > > Regards, > > - Arnaldo From rddunlap@osdl.org Mon Apr 4 13:49:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 13:49:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Knc1M002701 for ; Mon, 4 Apr 2005 13:49:40 -0700 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j34Kmms4004974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 4 Apr 2005 13:48:49 -0700 Message-ID: <4251A830.5030905@osdl.org> Date: Mon, 04 Apr 2005 13:48:48 -0700 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg CC: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> In-Reply-To: <20050404195051.GA12364@mars.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi Sam- Sam Ravnborg wrote: > On Sun, Apr 03, 2005 at 08:30:13PM -0700, Randy.Dunlap wrote: > >>Any comments on this new version? > > The new Networking menu looks unstructured. > And the net/Kconfig file contains a lot of config snippets that does not > belong there. > So I took a stamp on it with focus on: > - Move config bits to appropriate places, creating several new Kconfig > files Very Good. > - Made uses of menus more consistent at least on first and second level Very Good again. > - Move submenu to the top > - Rename top menu to "Networking" and located it just before > "File systems" I still prefer Networking to come before Device Drivers FWIW. Just makes some kind of hierarchical sense to me. > The patch became much larger. The win is that the top-level > net/Kconfig contains much less cruft. > > Many of the 56 lines added are due to the additional files. > I did not (on purpose) change any functionality. > > Only bit that I am worried about is the statement in SCTP: > depends on IPV6 || IPV6=n > > That looked like a noop to me. It had the sideeffect that SCTP > menu entries where idented an extra level which was not desireable > with currect layout. Yeah, I was having several identation problems. > Comments appreciated. Nice job overall. Especially nice to move ATM, bridge, DECNET, ECONET, etc., to their own Kconfig files so that they are more manageable. I propose that the new file net/atm/Kconfig be sourced somewhere. I'll look at it more to see if I have any other comments. > Patch on top of rc2. > > Signed-off-by: Sam Ravnborg > --- > > > Sam > > drivers/Kconfig | 5 > drivers/net/Kconfig | 5 > drivers/net/appletalk/Kconfig | 28 ++ > net/8021q/Kconfig | 21 + > net/Kconfig | 541 +++--------------------------------------- > net/atm/Kconfig | 77 +++++ > net/bridge/Kconfig | 32 ++ > net/bridge/netfilter/Kconfig | 1 > net/core/Kconfig | 67 +++++ > net/decnet/Kconfig | 24 + > net/econet/Kconfig | 34 ++ > net/ipv4/netfilter/Kconfig | 5 > net/ipv6/Kconfig | 20 + > net/ipx/Kconfig | 33 ++ > net/lapb/Kconfig | 24 + > net/packet/Kconfig | 26 ++ > net/sched/Kconfig | 40 +++ > net/sctp/Kconfig | 5 > net/unix/Kconfig | 22 + > net/wanrouter/Kconfig | 31 ++ > net/x25/Kconfig | 35 ++ > 21 files changed, 567 insertions(+), 509 deletions(-) Thanks! -- ~Randy From herbert@gondor.apana.org.au Mon Apr 4 14:33:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 14:34:07 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34LXvmU004547 for ; Mon, 4 Apr 2005 14:33:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIZC8-0008Fm-00; Tue, 05 Apr 2005 07:33:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIZAk-0003xk-00; Tue, 05 Apr 2005 07:31:50 +1000 Date: Tue, 5 Apr 2005 07:31:49 +1000 To: jamal Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050404213149.GA15222@gondor.apana.org.au> References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112620614.1088.489.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 09:16:55AM -0400, jamal wrote: > > Ok, fair enough. It annoys me too when i review patches ;-> > So i will fix this before final. Just one more thing, can you please remove the _bh's that you added to the read_lock for xfrm_km_list? It turns out that they're not necessary since the write_lock()'s are only held in process context. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From sam@ravnborg.org Mon Apr 4 14:55:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 14:55:26 -0700 (PDT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34LtIX6006011 for ; Mon, 4 Apr 2005 14:55:21 -0700 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepa.post.tele.dk (Postfix) with ESMTP id 26AAB47FE7E; Mon, 4 Apr 2005 23:54:22 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id DC3EC6AC01D; Mon, 4 Apr 2005 23:55:54 +0200 (CEST) Date: Mon, 4 Apr 2005 23:55:54 +0200 From: Sam Ravnborg To: "Randy.Dunlap" Cc: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers Message-ID: <20050404215554.GA29170@mars.ravnborg.org> References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> <4251A830.5030905@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4251A830.5030905@osdl.org> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: netdev > >- Move submenu to the top > >- Rename top menu to "Networking" and located it just before > > "File systems" > > I still prefer Networking to come before Device Drivers FWIW. > Just makes some kind of hierarchical sense to me. Moved up as suggested. > I propose that the new file net/atm/Kconfig be sourced somewhere. Thanks, I have missed that one - added just before wanrouter. > I'll look at it more to see if I have any other comments. OK. I will await and post an updated patch if you do not beat me. Sam From hadi@cyberus.ca Mon Apr 4 15:20:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 15:20:33 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34MKRhB007138 for ; Mon, 4 Apr 2005 15:20:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DIZvo-0005mQ-Sp for netdev@oss.sgi.com; Mon, 04 Apr 2005 18:20:28 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIZvi-00038k-0N; Mon, 04 Apr 2005 18:20:22 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Patrick McHardy , Masahide NAKAMURA , "David S. Miller" , netdev In-Reply-To: <20050404213149.GA15222@gondor.apana.org.au> References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112653217.1088.2.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 18:20:17 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1377 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, 2005-04-04 at 17:31, Herbert Xu wrote: > On Mon, Apr 04, 2005 at 09:16:55AM -0400, jamal wrote: > > > > Ok, fair enough. It annoys me too when i review patches ;-> > > So i will fix this before final. > > Just one more thing, can you please remove the _bh's that you > added to the read_lock for xfrm_km_list? It turns out that they're > not necessary since the write_lock()'s are only held in process > context. Doesnt the policy notification one need it at least ? I thought it is entered at interupt context on packet path, no? cheers, jamal From davem@davemloft.net Mon Apr 4 15:26:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 15:26:55 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34MQnvU007829 for ; Mon, 4 Apr 2005 15:26:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIa0I-0005rl-00; Mon, 04 Apr 2005 15:25:06 -0700 Date: Mon, 4 Apr 2005 15:25:06 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, kaber@trash.net, nakam@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-Id: <20050404152506.15e1404b.davem@davemloft.net> In-Reply-To: <1112653217.1088.2.camel@jzny.localdomain> References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On 04 Apr 2005 18:20:17 -0400 jamal wrote: > On Mon, 2005-04-04 at 17:31, Herbert Xu wrote: > > On Mon, Apr 04, 2005 at 09:16:55AM -0400, jamal wrote: > > > > > > Ok, fair enough. It annoys me too when i review patches ;-> > > > So i will fix this before final. > > > > Just one more thing, can you please remove the _bh's that you > > added to the read_lock for xfrm_km_list? It turns out that they're > > not necessary since the write_lock()'s are only held in process > > context. > > Doesnt the policy notification one need it at least ? I thought it is > entered at interupt context on packet path, no? If you only take write_lock() from process context, only the write_lock()'s need BH disabling. read_lock() takers can then nest arbitrarily, BH or not. From hadi@cyberus.ca Mon Apr 4 15:43:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 15:43:08 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34Mh4G5008765 for ; Mon, 4 Apr 2005 15:43:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DIaHh-0007om-26 for netdev@oss.sgi.com; Mon, 04 Apr 2005 18:43:05 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIaHb-0006Ma-T9; Mon, 04 Apr 2005 18:43:00 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: herbert@gondor.apana.org.au, kaber@trash.net, nakam@linux-ipv6.org, netdev In-Reply-To: <20050404152506.15e1404b.davem@davemloft.net> References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112654575.1089.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Apr 2005 18:42:55 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1379 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, 2005-04-04 at 18:25, David S. Miller wrote: > If you only take write_lock() from process context, only the write_lock()'s > need BH disabling. read_lock() takers can then nest arbitrarily, BH or not. Ok, never mind - Ive made the change. As soon as Masahide tests i will post the final patch. cheers, jamal From arnaldo.melo@gmail.com Mon Apr 4 16:08:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 16:08:53 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34N8iIP009987 for ; Mon, 4 Apr 2005 16:08:45 -0700 Received: by wproxy.gmail.com with SMTP id 68so1742918wri for ; Mon, 04 Apr 2005 16:08:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eJqEO9seUN4hAcomQRcO6ctk+XHGwEe3AWJVXjbwbSrWvsDFO6MhdWfW4SxowsX4cfwbW6XF6SH6jDWnN8nPOMFkLbNLWd7+ynGEl22IL5r2dQySiMZD3zK2SVMbANUnZUkFhDZ4wE6j7lvUi1xSW+ZAb/r7PnzgS276QUICL6k= Received: by 10.54.84.18 with SMTP id h18mr166504wrb; Mon, 04 Apr 2005 16:08:39 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Mon, 4 Apr 2005 16:08:39 -0700 (PDT) Message-ID: <39e6f6c70504041608707cb02f@mail.gmail.com> Date: Mon, 4 Apr 2005 20:08:39 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: hadi@cyberus.ca Subject: Re: [PATCH 2/2][AX25] make ax25_queue_xmit a net_device parameter Cc: Arnaldo Carvalho de Melo , "David S. Miller" , Ralf Baechle , netdev In-Reply-To: <1112645495.1078.40.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050404195030.GJ640@conectiva.com.br> <1112645495.1078.40.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 04 Apr 2005 16:11:36 -0400, jamal wrote: > > You probably wanna set skb->input_dev in ax25_type_trans() as well > something like: > skb->input_dev = skb->dev = dev Yup, forgot about this one in this patch, but I want right now is mostly to reduce open coding all around while maintaining the same behaviour, in time we can eventually see a better abstraction for this set of operations, it should also set skb->protocol internally and not return a value to set skb->protocol, etc. :-) - Arnaldo From rddunlap@osdl.org Mon Apr 4 16:12:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 16:12:22 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34NCIA7010714 for ; Mon, 4 Apr 2005 16:12:18 -0700 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j34NBXs4017472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 4 Apr 2005 16:11:34 -0700 Message-ID: <4251C9A5.3020704@osdl.org> Date: Mon, 04 Apr 2005 16:11:33 -0700 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg CC: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> <4251A830.5030905@osdl.org> <20050404215554.GA29170@mars.ravnborg.org> In-Reply-To: <20050404215554.GA29170@mars.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Sam Ravnborg wrote: > >>>- Move submenu to the top >>>- Rename top menu to "Networking" and located it just before >>>"File systems" >> >>I still prefer Networking to come before Device Drivers FWIW. >>Just makes some kind of hierarchical sense to me. > > Moved up as suggested. > > >>I propose that the new file net/atm/Kconfig be sourced somewhere. > > Thanks, I have missed that one - added just before wanrouter. > > >>I'll look at it more to see if I have any other comments. > > OK. I will await and post an updated patch if you do not beat me. Sam, Here are a few more suggestions for you to consider. - in Networking support, move Network testing and Netpoll support to the end of the menu (basically put the devel. tools toward the bottom of the menu) - I would rather not "hide" Amateur Radio, IrDA, and Bluetooth in the Networking protocols area, but have them near 802.1x and ATM in the top-level Networking support menu. How does that sound to you? Thanks. -- ~Randy From tgraf@suug.ch Mon Apr 4 16:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 16:29:27 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34NTJMt014947 for ; Mon, 4 Apr 2005 16:29:20 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 8A2A084 for ; Tue, 5 Apr 2005 01:28:52 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id F349F1C0EA; Tue, 5 Apr 2005 01:29:34 +0200 (CEST) Date: Tue, 5 Apr 2005 01:29:34 +0200 From: Thomas Graf To: netdev@oss.sgi.com Subject: [ANNOUNCE] netlink library 0.5.0 Message-ID: <20050404232934.GK26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev I released libnl 0.5.0 today introducing address, routing, and routing rules support, various cleanups, more callbacks to customize message parsers, support for non-blocking sockets and a complete API reference in HTML and PostScript. About 70% of the features have been implemented of what I would call the basics needed for a feature freeze to let things stabilize for a 1.0 version. http://people.suug.ch/~tgr/libnl/ http://people.suug.ch/~tgr/libnl/files/libnl-0.5.0.tar.gz Summary of Changes from 0.4.4 to 0.5.0 ================================================ Thomas Graf o API documentation o nl_cache_filter to manually filter on a object o partial routing support o routing rules support o Propely set address family when setting addresses o debug flag and some rare messages, more to come o make error mesage verboseness configureable o tc fixes to wait for ack o cleanup and adaption of address code to latest internal API o various cleanups o dozens of API breakages (better now than later) Daniel Hottinger o arch 64bit printf length modifier fixes Baruch Even , Mediatrix Telecom, inc. o address support From ravinandan.arakali@neterion.com Mon Apr 4 18:49:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 18:49:45 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j351ndu8019254 for ; Mon, 4 Apr 2005 18:49:40 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j350nFOC012602; Mon, 4 Apr 2005 20:49:15 -0400 (EDT) Received: from rarakali ([10.16.16.58]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j350nDDD018529; Mon, 4 Apr 2005 20:49:13 -0400 (EDT) From: "Ravinandan Arakali" To: "'Arthur Kepner'" Cc: , , "'Leonid. Grossman \(E-mail\)'" , "'Raghavendra. Koushik \(E-mail\)'" Subject: RE: High CPU utilization with Bonding driver ? Date: Mon, 4 Apr 2005 17:49:07 -0700 Message-ID: <004101c53979$45f02800$3a10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Arthur, On what kernel version should your below mentioned patch be applied ? We tried on one of the older kernels(2.6.5) and got an Oops while loading the bonding driver. Thanks, Ravi -----Original Message----- From: Arthur Kepner [mailto:akepner@sgi.com] Sent: Tuesday, March 29, 2005 10:29 AM To: Ravinandan Arakali Cc: netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net; Leonid. Grossman (E-mail); Raghavendra. Koushik (E-mail) Subject: Re: High CPU utilization with Bonding driver ? On Tue, 29 Mar 2005, Ravinandan Arakali wrote: > .... > Results(8 nttcp/chariot streams): > --------------------------------- > 1. Combined throughputs(but no bonding): > 3.1 + 6.2 = 9.3 Gbps with 58% CPU idle. > > 2. eth0 and eth1 bonded together in LACP mode: > 8.2 Gbps with 1% CPU idle. > > From the above results, when Bonding driver is used(#2), the CPUs are > completely maxed out compared to the case when traffic is run > simultaneously on both the cards(#1). > Can anybody suggest some reasons for the above behavior ? > Ravi; Have you tried this patch? http://marc.theaimsgroup.com/?l=linux-netdev&m=111091146828779&w=2 If not, it will likely go a long way to solving your problem. -- Arthur From akepner@sgi.com Mon Apr 4 20:05:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 20:05:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35351YH022026 for ; Mon, 4 Apr 2005 20:05:01 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j354gqxw012558 for ; Mon, 4 Apr 2005 21:43:02 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3534VbT55254226 for ; Mon, 4 Apr 2005 20:04:31 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-49.corp.sgi.com [134.15.0.49]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3533PlV10842885; Mon, 4 Apr 2005 20:03:27 -0700 (PDT) Date: Mon, 4 Apr 2005 20:03:02 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Ravinandan Arakali cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, "'Leonid. Grossman (E-mail)'" , "'Raghavendra. Koushik (E-mail)'" Subject: RE: High CPU utilization with Bonding driver ? In-Reply-To: <004101c53979$45f02800$3a10100a@pc.s2io.com> Message-ID: References: <004101c53979$45f02800$3a10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev On Mon, 4 Apr 2005, Ravinandan Arakali wrote: > Arthur, > On what kernel version should your below mentioned patch be applied ? > We tried on one of the older kernels(2.6.5) and got an Oops while > loading the bonding driver. > ..... Hmmm, interesting. I've used it with 2.6.X for at least two values of X (one of them being 5) so I'm surprised. Can you provide details about the oops? -- Arthut From jmorris@redhat.com Mon Apr 4 22:05:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 22:06:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3555rU0029947 for ; Mon, 4 Apr 2005 22:05:54 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3555B9x021150; Tue, 5 Apr 2005 01:05:12 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3555BO11361; Tue, 5 Apr 2005 01:05:11 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j3555Av9028068; Tue, 5 Apr 2005 01:05:10 -0400 Date: Tue, 5 Apr 2005 01:05:10 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Evgeniy Polyakov cc: linux-kernel@vger.kernel.org, , "David S. Miller" , Herbert Xu , , Greg KH , Andrew Morton Subject: Netlink Connector / CBUS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1385 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 Evgeniy, Please send networking patches to netdev@oss.sgi.com. Your connector code (under drivers/connector) is now in the -mm tree and as far as I can tell, has not received any review from the network developers. Looking at it briefly, it seems quite unfinished. I'm not entirely sure what it's purpose is. A clear explanation of its purpose would be helpful (to me, at least), as well as documentation of the API and majore data structures (which akpm has also asked for, IIRC). I can see one example of where it's being used with kobject_uevent, and it seems to have arrived via Greg-KH's I2C tree... If you're trying to add a generic, psuedo-reliable Netlink communication system, perhaps this should be built into Netlink itself as an extension of the existing Netlink API. I don't think this should be done as a separate "driver" off somewhere else with a new API. A few questions: - Why does it by default use NETLINK_NFLOG a kernel socket, and also allow this to be overriden by a module parameter? - Why does the cn.o module (poor namespace choice) add a callback itself on initialization? - Where is the userspace code which uses this? I checked out dbus from cvs and couldn't see anything obvious. Thanks, - James -- James Morris From jmorris@redhat.com Mon Apr 4 22:10:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 22:10:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j355AOAV030773 for ; Mon, 4 Apr 2005 22:10:25 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j355A7lF022142; Tue, 5 Apr 2005 01:10:07 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j355A6O12574; Tue, 5 Apr 2005 01:10:06 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j355A6v9028398; Tue, 5 Apr 2005 01:10:06 -0400 Date: Tue, 5 Apr 2005 01:10:06 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Evgeniy Polyakov cc: linux-kernel@vger.kernel.org, , "David S. Miller" , Herbert Xu , , Greg KH , Andrew Morton Subject: Re: Netlink Connector / CBUS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1386 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, 5 Apr 2005, James Morris wrote: > A few questions: Also, please allow cn_add_callback() allow it to be passed a NULL callback function, so the caller doesn't pass in a dummy function and your code doesn't waste time dealing with something which isn't real. - James -- James Morris From lark@linux.net.cn Mon Apr 4 22:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 22:35:24 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j355ZC9N032019 for ; Mon, 4 Apr 2005 22:35:14 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id D34243F89E for ; Tue, 5 Apr 2005 13:35:05 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 08008-04-3 for ; Tue, 5 Apr 2005 13:35:02 +0800 (CST) Received: from [192.168.0.120] (unknown [61.48.107.46]) by mx.linux.net.cn (Postfix) with ESMTP id 6BEF33F895 for ; Tue, 5 Apr 2005 13:35:02 +0800 (CST) Date: Tue, 05 Apr 2005 13:35:02 +0800 From: Wang Jian To: netdev@oss.sgi.com Subject: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-Id: <20050405133336.0247.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_42520103041705CB2AF8_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev --------_42520103041705CB2AF8_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, This is a simple patch against net/sched/cls_fw.c. The idea of this patch is discussed in this thread https://lists.netfilter.org/pipermail/netfilter-devel/2005-March/018762.html I chose 509 for FW_FILTER_HSIZE. If you feel it is waste of memory, then 251 is good too. BTW: I don't know much about hash performance and hash distribution of jhash. This is a quick fix. -- lark --------_42520103041705CB2AF8_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="hash-cls_fw.diff" Content-Disposition: attachment; filename="hash-cls_fw.diff" Content-Transfer-Encoding: base64 SW5kZXg6IGNsc19mdy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGNsc19mdy5jCShyZXZpc2lvbiAxKQorKysg Y2xzX2Z3LmMJKHdvcmtpbmcgY29weSkKQEAgLTQ1LDEwICs0NSwxMyBAQAogI2luY2x1ZGUgPG5l dC9zb2NrLmg+CiAjaW5jbHVkZSA8bmV0L2FjdF9hcGkuaD4KICNpbmNsdWRlIDxuZXQvcGt0X2Ns cy5oPgorI2luY2x1ZGUgPGxpbnV4L2poYXNoLmg+CiAKKyNkZWZpbmUgRldfRklMVEVSX0hTSVpF CQk1MDkKKwogc3RydWN0IGZ3X2hlYWQKIHsKLQlzdHJ1Y3QgZndfZmlsdGVyICpodFsyNTZdOwor CXN0cnVjdCBmd19maWx0ZXIgKmh0W0ZXX0ZJTFRFUl9IU0laRV07CiB9OwogCiBzdHJ1Y3QgZndf ZmlsdGVyCkBAIC02OSw3ICs3Miw3IEBACiAKIHN0YXRpYyBfX2lubGluZV9fIGludCBmd19oYXNo KHUzMiBoYW5kbGUpCiB7Ci0JcmV0dXJuIGhhbmRsZSYweEZGOworCXJldHVybiAoamhhc2hfMXdv cmQoaGFuZGxlLCAweEYzMEE3MTI5KSAlIEZXX0ZJTFRFUl9IU0laRSk7CiB9CiAKIHN0YXRpYyBp bnQgZndfY2xhc3NpZnkoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IHRjZl9wcm90byAqdHAs CkBAIC0xNTIsNyArMTU1LDcgQEAKIAlpZiAoaGVhZCA9PSBOVUxMKQogCQlyZXR1cm47CiAKLQlm b3IgKGg9MDsgaDwyNTY7IGgrKykgeworCWZvciAoaD0wOyBoPEZXX0ZJTFRFUl9IU0laRTsgaCsr KSB7CiAJCXdoaWxlICgoZj1oZWFkLT5odFtoXSkgIT0gTlVMTCkgewogCQkJaGVhZC0+aHRbaF0g PSBmLT5uZXh0OwogCQkJZndfZGVsZXRlX2ZpbHRlcih0cCwgZik7CkBAIC0yOTEsNyArMjk0LDcg QEAKIAlpZiAoYXJnLT5zdG9wKQogCQlyZXR1cm47CiAKLQlmb3IgKGggPSAwOyBoIDwgMjU2OyBo KyspIHsKKwlmb3IgKGggPSAwOyBoIDwgRldfRklMVEVSX0hTSVpFOyBoKyspIHsKIAkJc3RydWN0 IGZ3X2ZpbHRlciAqZjsKIAogCQlmb3IgKGYgPSBoZWFkLT5odFtoXTsgZjsgZiA9IGYtPm5leHQp IHsK --------_42520103041705CB2AF8_MULTIPART_MIXED_-- From davem@davemloft.net Mon Apr 4 22:38:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 22:39:02 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j355ctK0032703 for ; Mon, 4 Apr 2005 22:38:58 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIgky-0000BB-00; Mon, 04 Apr 2005 22:37:44 -0700 Date: Mon, 4 Apr 2005 22:37:44 -0700 From: "David S. Miller" To: Wang Jian Cc: netdev@oss.sgi.com Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-Id: <20050404223744.1f04c130.davem@davemloft.net> In-Reply-To: <20050405133336.0247.LARK@linux.net.cn> References: <20050405133336.0247.LARK@linux.net.cn> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 05 Apr 2005 13:35:02 +0800 Wang Jian wrote: > https://lists.netfilter.org/pipermail/netfilter-devel/2005-March/018762.html > > I chose 509 for FW_FILTER_HSIZE. If you feel it is waste of memory, then > 251 is good too. Please us a power of two, the "%" is expensive on some cpus. From lark@linux.net.cn Mon Apr 4 23:06:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 23:06:16 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35663Kq001837 for ; Mon, 4 Apr 2005 23:06:07 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id D2D7E3F89E for ; Tue, 5 Apr 2005 14:05:58 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 08289-06-4 for ; Tue, 5 Apr 2005 14:05:56 +0800 (CST) Received: from [192.168.0.120] (unknown [61.48.107.46]) by mx.linux.net.cn (Postfix) with ESMTP id 76BD63F895 for ; Tue, 5 Apr 2005 14:05:56 +0800 (CST) Date: Tue, 05 Apr 2005 14:05:56 +0800 From: Wang Jian To: netdev@oss.sgi.com Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function In-Reply-To: <20050404223744.1f04c130.davem@davemloft.net> References: <20050405133336.0247.LARK@linux.net.cn> <20050404223744.1f04c130.davem@davemloft.net> Message-Id: <20050405140342.024A.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_42522A3E043B033D6C20_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev --------_42522A3E043B033D6C20_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi David S. Miller, New patch attached. Hashsize is 256, the same as old one. On Mon, 4 Apr 2005 22:37:44 -0700, "David S. Miller" wrote: > On Tue, 05 Apr 2005 13:35:02 +0800 > Wang Jian wrote: > > > https://lists.netfilter.org/pipermail/netfilter-devel/2005-March/018762.html > > > > I chose 509 for FW_FILTER_HSIZE. If you feel it is waste of memory, then > > 251 is good too. > > Please us a power of two, the "%" is expensive on some cpus. -- lark --------_42522A3E043B033D6C20_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="hash-cls_fw-2.diff" Content-Disposition: attachment; filename="hash-cls_fw-2.diff" Content-Transfer-Encoding: base64 SW5kZXg6IGxpbnV4LTIuNi4xMS13L25ldC9zY2hlZC9jbHNfZncuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBs aW51eC0yLjYuMTEtdy9uZXQvc2NoZWQvY2xzX2Z3LmMJKHJldmlzaW9uIDEpCisrKyBsaW51eC0y LjYuMTEtdy9uZXQvc2NoZWQvY2xzX2Z3LmMJKHdvcmtpbmcgY29weSkKQEAgLTQ1LDEwICs0NSwx MyBAQAogI2luY2x1ZGUgPG5ldC9zb2NrLmg+CiAjaW5jbHVkZSA8bmV0L2FjdF9hcGkuaD4KICNp bmNsdWRlIDxuZXQvcGt0X2Nscy5oPgorI2luY2x1ZGUgPGxpbnV4L2poYXNoLmg+CiAKKyNkZWZp bmUgRldfRklMVEVSX0hTSVpFCQkyNTYKKwogc3RydWN0IGZ3X2hlYWQKIHsKLQlzdHJ1Y3QgZndf ZmlsdGVyICpodFsyNTZdOworCXN0cnVjdCBmd19maWx0ZXIgKmh0W0ZXX0ZJTFRFUl9IU0laRV07 CiB9OwogCiBzdHJ1Y3QgZndfZmlsdGVyCkBAIC02OSw3ICs3Miw3IEBACiAKIHN0YXRpYyBfX2lu bGluZV9fIGludCBmd19oYXNoKHUzMiBoYW5kbGUpCiB7Ci0JcmV0dXJuIGhhbmRsZSYweEZGOwor CXJldHVybiAoamhhc2hfMXdvcmQoaGFuZGxlLCAweEYzMEE3MTI5KSAlIEZXX0ZJTFRFUl9IU0la RSk7CiB9CiAKIHN0YXRpYyBpbnQgZndfY2xhc3NpZnkoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3Ry dWN0IHRjZl9wcm90byAqdHAsCkBAIC0xNTIsNyArMTU1LDcgQEAKIAlpZiAoaGVhZCA9PSBOVUxM KQogCQlyZXR1cm47CiAKLQlmb3IgKGg9MDsgaDwyNTY7IGgrKykgeworCWZvciAoaD0wOyBoPEZX X0ZJTFRFUl9IU0laRTsgaCsrKSB7CiAJCXdoaWxlICgoZj1oZWFkLT5odFtoXSkgIT0gTlVMTCkg ewogCQkJaGVhZC0+aHRbaF0gPSBmLT5uZXh0OwogCQkJZndfZGVsZXRlX2ZpbHRlcih0cCwgZik7 CkBAIC0yOTEsNyArMjk0LDcgQEAKIAlpZiAoYXJnLT5zdG9wKQogCQlyZXR1cm47CiAKLQlmb3Ig KGggPSAwOyBoIDwgMjU2OyBoKyspIHsKKwlmb3IgKGggPSAwOyBoIDwgRldfRklMVEVSX0hTSVpF OyBoKyspIHsKIAkJc3RydWN0IGZ3X2ZpbHRlciAqZjsKIAogCQlmb3IgKGYgPSBoZWFkLT5odFto XTsgZjsgZiA9IGYtPm5leHQpIHsK --------_42522A3E043B033D6C20_MULTIPART_MIXED_-- From johnpol@2ka.mipt.ru Mon Apr 4 23:59:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Apr 2005 23:59:31 -0700 (PDT) Received: from vocord.com (ns2.vocord.com [194.220.215.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j356xNbl004930 for ; Mon, 4 Apr 2005 23:59:24 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j356uTw7024383; Tue, 5 Apr 2005 10:57:29 +0400 Subject: Re: Netlink Connector / CBUS From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: James Morris Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , Herbert Xu , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p5aA2EfudVVDZNSzIBGU" Organization: MIPT Date: Tue, 05 Apr 2005 11:03:16 +0400 Message-Id: <1112684596.28858.4.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/762/Mon Mar 14 02:35:33 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 05 Apr 2005 10:57:35 +0400 (MSD) X-archive-position: 1390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-p5aA2EfudVVDZNSzIBGU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote:=20 > Evgeniy, >=20 > Please send networking patches to netdev@oss.sgi.com. It was sent there two times. > Your connector code (under drivers/connector) is now in the -mm tree and=20 > as far as I can tell, has not received any review from the network=20 > developers. I received comments and feature requests from Herbert Xu and Jamal Hadi Salim, almost all were successfully resolved. > Looking at it briefly, it seems quite unfinished. Hmmm... I think it is fully functional and ready for inclusion. > I'm not entirely sure what it's purpose is. 1. Provide very flexible userspace control over netlink. 2. Provide very flexible notification mechanism. > A clear explanation of its purpose would be helpful (to me, at least), as= =20 > well as documentation of the API and majore data structures (which akpm=20 > has also asked for, IIRC). Documentation exists in Documentation/connector/connector.txt. Patch with brief source documentation was already created, so I will post it with other minor updates soon. > I can see one example of where it's being used with kobject_uevent, and i= t=20 > seems to have arrived via Greg-KH's I2C tree... It also is used in SuperIO and acrypto subsystems. > If you're trying to add a generic, psuedo-reliable Netlink communication=20 > system, perhaps this should be built into Netlink itself as an extension=20 > of the existing Netlink API. So, you recommend to create for each driver, that wants to be controlled over netlink, new netlink socket, register it's unit and learn how SKB is allocated, processed and so on? This is wrong. Much easier to just register a callback. > I don't think this should be done as a separate "driver" off somewhere=20 > else with a new API. It is much easier to use connector instead of direct netlink sockets. One should only register callback and identifier. When driver receives special netlink message with appropriate identifier, appropriate callback will be called. =46rom the userspace point of view it's quite straightforward: socket(); bind(); send(); recv(); But if kernelspace want to use full power of such connections, driver writer must create special sockets, must know about struct sk_buff handling... Connector allows any kernelspace agents to use netlink based networking for inter-process communication in a significantly easier way: int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); void cn_netlink_send(struct cn_msg *msg, u32 __groups); >=20 > A few questions: >=20 > - Why does it by default use NETLINK_NFLOG a kernel socket, and also allo= w=20 > this to be overriden by a module parameter? Because while this driver lived outside kernel tree there were no empty=20 registered socket. It can be changed if driver will go upstream. > - Why does the cn.o module (poor namespace choice) add a callback itself > on initialization? Because that callback is used for notification requests. > - Where is the userspace code which uses this? I checked out dbus from=20 > cvs and couldn't see anything obvious. I posted it with SuperIO, kobject_uevent, acrypto and fork changes. It is quite straightforward: s =3D socket(PF_NETLINK, SOCK_DGRAM, NETLINK_NFLOG); if (s =3D=3D -1) { perror("socket"); return -1; } l_local.nl_family =3D AF_NETLINK; l_local.nl_groups =3D CN_ACRYPTO_IDX; l_local.nl_pid =3D getpid(); if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) =3D=3D -1) { perror("bind"); close(s); return -1; } case NLMSG_DONE: data =3D (struct cn_msg *)NLMSG_DATA(reply); m =3D (struct crypto_conn_data *)(data + 1); stat =3D (struct crypto_device_stat *)(m+1); time(&tm); fprintf(out, "%.24s : [%x.%x] [seq=3D%u, ack=3D%u], name= =3D %s, cmd=3D%#02x, " "sesions: completed=3D%llu, started=3D%llu, finished=3D%llu, cache_failed=3D%llu.\n", ctime(&tm), data->id.idx, data->id.val, data->seq, data->ack, m->name, m->cmd, stat->scompleted, stat->sstarted, stat- >sfinished, stat->cache_failed); fflush(out); break; >=20 > Thanks, Thank you for your comments. >=20 > - James --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-p5aA2EfudVVDZNSzIBGU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCUjg0IKTPhE+8wY0RAtW9AJ0a0EjP0tCQ+mf28pplSyNYxtY5DgCfQq0x oMdIKfBX1VrHHWNtXPzhMAc= =C9qk -----END PGP SIGNATURE----- --=-p5aA2EfudVVDZNSzIBGU-- From johnpol@2ka.mipt.ru Tue Apr 5 00:04:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 00:04:13 -0700 (PDT) Received: from vocord.com (ns2.vocord.com [194.220.215.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35745hU005695 for ; Tue, 5 Apr 2005 00:04:06 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j35731D8024623; Tue, 5 Apr 2005 11:03:05 +0400 Subject: Re: Netlink Connector / CBUS From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: James Morris Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , Herbert Xu , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q31YfxoFqrjCdpDRIKy3" Organization: MIPT Date: Tue, 05 Apr 2005 11:08:04 +0400 Message-Id: <1112684884.28858.10.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/762/Mon Mar 14 02:35:33 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 05 Apr 2005 11:03:05 +0400 (MSD) X-archive-position: 1391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-Q31YfxoFqrjCdpDRIKy3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-04-05 at 01:10 -0400, James Morris wrote: > On Tue, 5 Apr 2005, James Morris wrote: >=20 > > A few questions: >=20 > Also, please allow cn_add_callback() allow it to be passed a NULL=20 > callback function, so the caller doesn't pass in a dummy function and you= r=20 > code doesn't waste time dealing with something which isn't real. Why can anyone want to add callback that will not supposed to be usefull? Callback is called when someone sends netlink message with appropriate idx/val inside, if there is no registered callback with such ID,=20 nothing will be called and skb will be freed. >=20 > - James --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-Q31YfxoFqrjCdpDRIKy3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCUjlUIKTPhE+8wY0RAv/qAJ4gmxfOafjdLprCQ4Ue0e7d6SxbrACfcJM7 qFXZGBk8rY3rtFUCIyZgu3Q= =0Car -----END PGP SIGNATURE----- --=-Q31YfxoFqrjCdpDRIKy3-- From herbert@gondor.apana.org.au Tue Apr 5 00:11:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 00:11:36 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j357BQBi006725 for ; Tue, 5 Apr 2005 00:11:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIiDB-0002zX-00; Tue, 05 Apr 2005 17:10:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIiCI-00050h-00; Tue, 05 Apr 2005 17:10:02 +1000 Date: Tue, 5 Apr 2005 17:10:02 +1000 To: Evgeniy Polyakov Cc: James Morris , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , rml@novell.com, Greg KH , Andrew Morton Subject: Re: Netlink Connector / CBUS Message-ID: <20050405071002.GA19186@gondor.apana.org.au> References: <1112684596.28858.4.camel@uganda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112684596.28858.4.camel@uganda> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote: > > I received comments and feature requests from Herbert Xu and Jamal Hadi > Salim, > almost all were successfully resolved. Please do not construe my involvement in these threads as endorsement for this system. In fact to this day I still don't understand what problems this thing is meant to solve. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Tue Apr 5 00:28:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 00:28:56 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j357SllX011474 for ; Tue, 5 Apr 2005 00:28:48 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j357Rstm025626; Tue, 5 Apr 2005 11:27:54 +0400 Subject: Re: Netlink Connector / CBUS From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , James Morris , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sXlTmFdVb1kJKT8aZHNH" Organization: MIPT Date: Tue, 05 Apr 2005 11:34:40 +0400 Message-Id: <1112686480.28858.17.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/762/Mon Mar 14 02:35:33 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 05 Apr 2005 11:27:54 +0400 (MSD) X-archive-position: 1393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-sXlTmFdVb1kJKT8aZHNH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: >On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote: >>=20 >> I received comments and feature requests from Herbert Xu and Jamal Hadi >> Salim, >> almost all were successfully resolved. > >Please do not construe my involvement in these threads as endorsement >for this system. Sure. I remember you are against it :). >In fact to this day I still don't understand what problems this thing is >meant to solve. Hmm, what else can I add to my words? May be checking the size of the code needed to broadcast kobject changes in kobject_uevent.c for example... Netlink socket allocation + skb handling against call to cn_netlink_send(). >--=20 >Visit Openswan at http://www.openswan.org/ >Email: Herbert Xu ~{PmV>HI~} >Home Page: http://gondor.apana.org.au/~herbert/ >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-sXlTmFdVb1kJKT8aZHNH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCUj+QIKTPhE+8wY0RAtcKAJ91ZXvgUr1gGOjGWtnLZRc6iQYeCwCfWLe/ hMplKPbqSYSR1MIMr/E38+E= =Xfba -----END PGP SIGNATURE----- --=-sXlTmFdVb1kJKT8aZHNH-- From nakam@linux-ipv6.org Tue Apr 5 00:35:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 00:36:02 -0700 (PDT) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j357ZvsU012410 for ; Tue, 5 Apr 2005 00:35:58 -0700 Received: from [192.168.2.173] (polaris.linux-ipv6.org [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id 7725E109D; Tue, 5 Apr 2005 16:35:48 +0900 (JST) Message-ID: <42523FD3.8010400@linux-ipv6.org> Date: Tue, 05 Apr 2005 16:35:47 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: "David S. Miller" , herbert@gondor.apana.org.au, kaber@trash.net, netdev Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> In-Reply-To: <1112654575.1089.17.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello Jamal, jamal wrote: > On Mon, 2005-04-04 at 18:25, David S. Miller wrote: > > >>If you only take write_lock() from process context, only the write_lock()'s >>need BH disabling. read_lock() takers can then nest arbitrarily, BH or not. > > > Ok, never mind - Ive made the change. > As soon as Masahide tests i will post the final patch. I've tested normal cases below with the latest patch and it works fine. I think you can go ahead. tested cases: o netlink (using iproute2 "ip xfrm monitor" to confirm it) - add/del/flush/expire for SA/SP - acquire,allocspi,update for SA - update for SP o pfkey - running racoon o both sockets - running racoon with using "ip xfrm monitor". Regards, -- Masahide NAKAMURA From guillaume.thouvenin@bull.net Tue Apr 5 01:11:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 01:11:46 -0700 (PDT) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j358BYbd014731 for ; Tue, 5 Apr 2005 01:11:40 -0700 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 987FE19D90B; Tue, 5 Apr 2005 10:11:23 +0200 (CEST) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03244-04; Tue, 5 Apr 2005 10:11:21 +0200 (CEST) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 54BC919D90A; Tue, 5 Apr 2005 10:11:21 +0200 (CEST) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005040510211477:2848 ; Tue, 5 Apr 2005 10:21:14 +0200 Subject: Re: Netlink Connector / CBUS From: Guillaume Thouvenin To: Herbert Xu Cc: lkml , Netlink List , "David S. Miller" , James Morris , rml@novell.com, Greg KH , Andrew Morton , Evgeniy Polyakov In-Reply-To: <1112686480.28858.17.camel@uganda> References: <1112686480.28858.17.camel@uganda> Date: Tue, 05 Apr 2005 10:11:23 +0200 Message-Id: <1112688683.8456.10.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 05/04/2005 10:21:14, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 05/04/2005 10:21:15, Serialize complete at 05/04/2005 10:21:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 1395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev On Tue, 2005-04-05 at 11:34 +0400, Evgeniy Polyakov wrote: > On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: > > >In fact to this day I still don't understand what problems this thing is > >meant to solve. > > Hmm, what else can I add to my words? > May be checking the size of the code needed to broadcast kobject changes > in kobject_uevent.c for example... > Netlink socket allocation + skb handling against call to cn_netlink_send(). And It's the same for the fork connector. It allows to send a message to a user space application when a fork occurs by adding only one line (two with the #include) in the kernel/fork.c file. Thus, the netlink connector is a very simple and fast mechanism when you need to send a small amount of information from kernel space to user space. Regards, Guillaume From marcel@holtmann.org Tue Apr 5 02:35:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 02:35:53 -0700 (PDT) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j359ZjaK025942 for ; Tue, 5 Apr 2005 02:35:46 -0700 Received: from pegasus (pD9FF9FF2.dip.t-dialin.net [217.255.159.242]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j359aDbo017297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Apr 2005 11:36:14 +0200 Subject: Some sleeping function called from invalid context From: Marcel Holtmann To: Network Development Mailing List Content-Type: text/plain Date: Tue, 05 Apr 2005 11:35:44 +0200 Message-Id: <1112693744.7960.2.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 16:38:58 2005 on coyote.holtmann.net X-Virus-Status: Clean X-archive-position: 1396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Hi, while testing the latest kernel from the Bitkeeper repository, I got some sleeping functions called from invalid context: Freeing unused kernel memory: 180k freed Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [] __might_sleep+0xa6/0xb0 [] kmem_cache_alloc+0x73/0x80 [] kmem_cache_create+0xfe/0x630 [] proto_register+0x9d/0xc0 [] af_unix_init+0x1c/0x7a [unix] [] sys_init_module+0x1b2/0x290 [] syscall_call+0x7/0xb NET: Registered protocol family 1 Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [] __might_sleep+0xa6/0xb0 [] kmem_cache_alloc+0x73/0x80 [] kmem_cache_create+0xfe/0x630 [] wake_up_process+0x1d/0x30 [] free_uid+0x20/0x90 [] proto_register+0x9d/0xc0 [] inet6_init+0x19/0x200 [ipv6] [] sys_init_module+0x1b2/0x290 [] syscall_call+0x7/0xb NET: Registered protocol family 10 Regards Marcel From hadi@cyberus.ca Tue Apr 5 03:18:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:18:42 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35AIXqG000444 for ; Tue, 5 Apr 2005 03:18:34 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIl8g-0006Ze-53 for netdev@oss.sgi.com; Tue, 05 Apr 2005 06:18:30 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIl8a-00024T-OZ; Tue, 05 Apr 2005 06:18:25 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Masahide NAKAMURA Cc: "David S. Miller" , herbert@gondor.apana.org.au, kaber@trash.net, netdev In-Reply-To: <42523FD3.8010400@linux-ipv6.org> References: <1112406164.1088.54.camel@jzny.localdomain> <20050402014619.GB24861@gondor.apana.org.au> <1112469601.1088.173.camel@jzny.localdomain> <1112538718.1096.394.camel@jzny.localdomain> <20050404005805.GA16543@gondor.apana.org.au> <1112614706.1096.439.camel@jzny.localdomain> <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> Content-Type: multipart/mixed; boundary="=-8p91jRGJUs8TN3Xo5ByK" Organization: jamalopolous Message-Id: <1112696301.1089.30.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 06:18:22 -0400 X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1397 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 --=-8p91jRGJUs8TN3Xo5ByK Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-04-05 at 03:35, Masahide NAKAMURA wrote: > Hello Jamal, [..] > I've tested normal cases below with the latest patch and it works fine. > I think you can go ahead. > > tested cases: > o netlink (using iproute2 "ip xfrm monitor" to confirm it) > - add/del/flush/expire for SA/SP > - acquire,allocspi,update for SA > - update for SP > o pfkey > - running racoon > o both sockets > - running racoon with using "ip xfrm monitor". > Thanks a lot Masahide! Ok, heres the patch i will shoot to Dave if no further comments. cheers, jamal --=-8p91jRGJUs8TN3Xo5ByK Content-Disposition: attachment; filename=ipsec-event-take2-5 Content-Type: text/plain; name=ipsec-event-take2-5; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-03-25 22:28:26.000000000 -0500 +++ b/include/net/xfrm.h 2005-04-02 11:59:17.000000000 -0500 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -802,7 +827,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-25 22:28:39.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-02 09:53:03.000000000 -0500 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-03-25 22:28:25.000000000 -0500 +++ b/net/xfrm/xfrm_state.c 2005-04-04 18:22:32.000000000 -0400 @@ -48,7 +48,7 @@ static struct list_head xfrm_state_gc_list = LIST_HEAD_INIT(xfrm_state_gc_list); static DEFINE_SPINLOCK(xfrm_state_gc_lock); -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); @@ -208,8 +208,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -236,14 +238,21 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +int xfrm_state_delete(struct xfrm_state *x) { + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -402,6 +411,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -767,34 +777,60 @@ static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); static DEFINE_RWLOCK(xfrm_km_lock); -static void km_state_expired(struct xfrm_state *x, int hard) +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct xfrm_mgr *km; - if (hard) - x->km.state = XFRM_STATE_EXPIRED; - else - x->km.dying = 1; + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock(&xfrm_km_lock); +} +void km_state_notify(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); + if (km->notify) + km->notify(x, c); read_unlock(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +static void km_state_expired(struct xfrm_state *x, int hard) +{ + struct km_event c; + + if (hard) + x->km.state = XFRM_STATE_EXPIRED; + else + x->km.dying = 1; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -819,13 +855,12 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_user.c 2005-03-25 22:28:22.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-04 18:36:44.000000000 -0400 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -277,6 +278,7 @@ if (!x) return err; + xfrm_state_hold(x); if (nlh->nlmsg_type == XFRM_MSG_NEWSA) err = xfrm_state_add(x); else @@ -285,14 +287,27 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + xfrm_state_put(x); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +319,19 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -335,6 +359,7 @@ int this_idx; }; + static int dump_one_state(struct xfrm_state *x, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -672,6 +697,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +709,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +720,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +847,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +876,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +890,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1113,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1130,122 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int inline xfrm_sa_len(struct xfrm_state *x) +{ + int l = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + if (x->aalg) + l+= RTA_SPACE(sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8); + if (x->ealg) + l+= RTA_SPACE(sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8); + if (x->calg) + l+= RTA_SPACE(sizeof(*(x->calg))); + if (x->encap) + l+= RTA_SPACE(sizeof(*x->encap)); + + return l; +} + +static int xfrm_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = xfrm_sa_len(x); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + if (x->aalg) + RTA_PUT(skb, XFRMA_ALG_AUTH, + sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8, x->aalg); + if (x->ealg) + RTA_PUT(skb, XFRMA_ALG_CRYPT, + sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8, x->ealg); + if (x->calg) + RTA_PUT(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg); + + if (x->encap) + RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: +rtattr_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("netlink: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1379,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1391,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1399,93 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); + len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + if (copy_to_user_tmpl(xp, skb) < 0) + goto nlmsg_failure; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("Netlink Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-03-25 22:28:39.000000000 -0500 +++ b/net/key/af_key.c 2005-04-04 18:45:48.000000000 -0400 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1254,6 +1326,7 @@ if (IS_ERR(x)) return PTR_ERR(x); + xfrm_state_hold(x); if (hdr->sadb_msg_type == SADB_ADD) err = xfrm_state_add(x); else @@ -1265,27 +1338,23 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1370,19 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1520,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + hdr->sadb_msg_satype = pfkey_proto2satype(c->data); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1948,35 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + + if (c->data && c->event == XFRM_SAP_DELETED) + out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; + else + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1984,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2052,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2084,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,25 +2120,41 @@ err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + + xfrm_pol_put(xp); + return err; +} + + +static int key_pol_get_resp(struct sock *sk, struct xfrm_policy *xp, struct sadb_msg *hdr, int dir) +{ + int err; + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + err = 0; + out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); goto out; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + pfkey_xfrm_policy2msg(out_skb, xp, dir); out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; + out_hdr->sadb_msg_type = hdr->sadb_msg_type; out_hdr->sadb_msg_satype = 0; out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ONE, sk); err = 0; out: - xfrm_pol_put(xp); return err; } @@ -2037,8 +2163,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2175,16 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.data = 1; // to signal pfkey of SADB_X_SPDDELETE2 + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + } else { + err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; - -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2219,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2445,24 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2481,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3034,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-8p91jRGJUs8TN3Xo5ByK-- From herbert@gondor.apana.org.au Tue Apr 5 03:23:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:23:45 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35ANZt0001243 for ; Tue, 5 Apr 2005 03:23:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIlD3-0004mZ-00; Tue, 05 Apr 2005 20:23:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIlCh-0006PT-00; Tue, 05 Apr 2005 20:22:39 +1000 Date: Tue, 5 Apr 2005 20:22:39 +1000 To: jamal Cc: Masahide NAKAMURA , "David S. Miller" , kaber@trash.net, netdev Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-ID: <20050405102238.GC23226@gondor.apana.org.au> References: <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> <1112696301.1089.30.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112696301.1089.30.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 06:18:22AM -0400, jamal wrote: > > Ok, heres the patch i will shoot to Dave if no further comments. Thanks for your great work Jamal. Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Tue Apr 5 03:25:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:25:54 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35APj8i002075 for ; Tue, 5 Apr 2005 03:25:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DIlFe-0002Tz-9N for netdev@oss.sgi.com; Tue, 05 Apr 2005 06:25:42 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIlFY-0002hw-9d; Tue, 05 Apr 2005 06:25:36 -0400 Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050405140342.024A.LARK@linux.net.cn> References: <20050405133336.0247.LARK@linux.net.cn> <20050404223744.1f04c130.davem@davemloft.net> <20050405140342.024A.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112696733.1088.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 06:25:34 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1399 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 Wang, I read that thread and i am a little confused. What is this change supposed to improve? cheers, jamal On Tue, 2005-04-05 at 02:05, Wang Jian wrote: > Hi David S. Miller, > > New patch attached. Hashsize is 256, the same as old one. > > > On Mon, 4 Apr 2005 22:37:44 -0700, "David S. Miller" wrote: > > > On Tue, 05 Apr 2005 13:35:02 +0800 > > Wang Jian wrote: > > > > > https://lists.netfilter.org/pipermail/netfilter-devel/2005-March/018762.html > > > > > > I chose 509 for FW_FILTER_HSIZE. If you feel it is waste of memory, then > > > 251 is good too. > > > > Please us a power of two, the "%" is expensive on some cpus. > > From hadi@cyberus.ca Tue Apr 5 03:35:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:35:29 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35AZOBl003011 for ; Tue, 5 Apr 2005 03:35:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIlOz-0004mJ-1m for netdev@oss.sgi.com; Tue, 05 Apr 2005 06:35:21 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIlOu-0003Uc-VC; Tue, 05 Apr 2005 06:35:17 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Masahide NAKAMURA , "David S. Miller" , kaber@trash.net, netdev In-Reply-To: <20050405102238.GC23226@gondor.apana.org.au> References: <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> <1112696301.1089.30.camel@jzny.localdomain> <20050405102238.GC23226@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112697315.1095.36.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 06:35:15 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1400 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 Tue, 2005-04-05 at 06:22, Herbert Xu wrote: > > Thanks for your great work Jamal. > Well, thanks to you for the shepherding and to Masahide-san for the testing and bugs found. cheers, jamal From tgraf@suug.ch Tue Apr 5 03:38:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:38:13 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Ac8I0003711 for ; Tue, 5 Apr 2005 03:38:09 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id D1B6385; Tue, 5 Apr 2005 12:37:44 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 1D1091C0EA; Tue, 5 Apr 2005 12:38:27 +0200 (CEST) Date: Tue, 5 Apr 2005 12:38:27 +0200 From: Thomas Graf To: Wang Jian Cc: netdev@oss.sgi.com Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050405103827.GL26731@postel.suug.ch> References: <20050405133336.0247.LARK@linux.net.cn> <20050404223744.1f04c130.davem@davemloft.net> <20050405140342.024A.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405140342.024A.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Wang Jian <20050405140342.024A.LARK@linux.net.cn> 2005-04-05 14:05 > New patch attached. Hashsize is 256, the same as old one. Do you have any numbers that could prove that this change actually improves the hash distribution and thus the overall lookup performance? The most often used and thus most important range of mark values is definitely 0..255. I did not look into jhash but the risk of collisions definitely increases with this change which affects about 90% of the users of fw which could benefit from a collision free hashtable so far. I would appreciate if you could provide some numbers proving both the need and actual improvement of this change since fwmark is one of the most often used classifiers. Cheers From herbert@gondor.apana.org.au Tue Apr 5 03:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:40:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35AePYX004380 for ; Tue, 5 Apr 2005 03:40:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIlTC-0004wy-00; Tue, 05 Apr 2005 20:39:42 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIlSo-0006Tl-00; Tue, 05 Apr 2005 20:39:18 +1000 Date: Tue, 5 Apr 2005 20:39:18 +1000 To: Patrick McHardy Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-ID: <20050405103918.GA24863@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42501E51.3000401@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, Apr 03, 2005 at 06:48:17PM +0200, Patrick McHardy wrote: > > Agreed. There is also a bug in my patch, tmpl->daddr can be 0 in which > case the daddr passed as an argument to xfrm_state_find() will be used. > My patch only checked tmpl->daddr, this patch fixes it. It also uses Why not just use daddr? It's always guaranteed to be correct. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Tue Apr 5 03:45:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 03:45:07 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Aj2bC005150 for ; Tue, 5 Apr 2005 03:45:02 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DIlYI-0007I5-VX for netdev@oss.sgi.com; Tue, 05 Apr 2005 06:44:58 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIlYA-0004Ob-HL; Tue, 05 Apr 2005 06:44:50 -0400 Subject: Re: Netlink Connector / CBUS From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Herbert Xu , linux-kernel@vger.kernel.org, netdev , "David S. Miller" , James Morris , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: <1112686480.28858.17.camel@uganda> References: <1112686480.28858.17.camel@uganda> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112697888.1089.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 06:44:48 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1403 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 To be fair to Evgeniy I am not against the Konnector idea. I think that it is a useful feature to have an easy to use messaging between kernel-kernel and kernel-userspace. The fact that he leveraged netlink instead of inventing things is a bonus. Having said that i have not seriously scrutinized the code - and i think the idea of this new thing hes tossing around called CBUS maybe pushing it. cheers, jamal On Tue, 2005-04-05 at 03:34, Evgeniy Polyakov wrote: > On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: > >On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote: > >> > >> I received comments and feature requests from Herbert Xu and Jamal Hadi > >> Salim, > >> almost all were successfully resolved. > > > >Please do not construe my involvement in these threads as endorsement > >for this system. > > Sure. > I remember you are against it :). > > >In fact to this day I still don't understand what problems this thing is > >meant to solve. > > Hmm, what else can I add to my words? > May be checking the size of the code needed to broadcast kobject changes > in kobject_uevent.c for example... > Netlink socket allocation + skb handling against call to cn_netlink_send(). > > >-- > >Visit Openswan at http://www.openswan.org/ > >Email: Herbert Xu ~{PmV>HI~} > >Home Page: http://gondor.apana.org.au/~herbert/ > >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > From hadi@cyberus.ca Tue Apr 5 04:00:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 04:00:18 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35B0AbL006656 for ; Tue, 5 Apr 2005 04:00:10 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIlmw-0000Dq-M5 for netdev@oss.sgi.com; Tue, 05 Apr 2005 07:00:06 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIlmt-0005tS-IV; Tue, 05 Apr 2005 07:00:03 -0400 Subject: Re: Netlink Connector / CBUS From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Herbert Xu , linux-kernel@vger.kernel.org, netdev , "David S. Miller" , James Morris , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: <1112697888.1089.44.camel@jzny.localdomain> References: <1112686480.28858.17.camel@uganda> <1112697888.1089.44.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112698800.1088.50.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 07:00:00 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1404 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 and, oh yeah - wheres the documentation Evgeniy? ;-> cheers, jamal On Tue, 2005-04-05 at 06:44, jamal wrote: > To be fair to Evgeniy I am not against the Konnector idea. I think that > it is a useful feature to have an easy to use messaging between > kernel-kernel and kernel-userspace. The fact that he leveraged netlink > instead of inventing things is a bonus. Having said that i have not > seriously scrutinized the code - and i think the idea of this new thing > hes tossing around called CBUS maybe pushing it. > > cheers, > jamal > > On Tue, 2005-04-05 at 03:34, Evgeniy Polyakov wrote: > > On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: > > >On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote: > > >> > > >> I received comments and feature requests from Herbert Xu and Jamal Hadi > > >> Salim, > > >> almost all were successfully resolved. > > > > > >Please do not construe my involvement in these threads as endorsement > > >for this system. > > > > Sure. > > I remember you are against it :). > > > > >In fact to this day I still don't understand what problems this thing is > > >meant to solve. > > > > Hmm, what else can I add to my words? > > May be checking the size of the code needed to broadcast kobject changes > > in kobject_uevent.c for example... > > Netlink socket allocation + skb handling against call to cn_netlink_send(). > > > > >-- > > >Visit Openswan at http://www.openswan.org/ > > >Email: Herbert Xu ~{PmV>HI~} > > >Home Page: http://gondor.apana.org.au/~herbert/ > > >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > > > > > From arnaldo.melo@gmail.com Tue Apr 5 04:13:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 04:14:15 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35BDv59008359 for ; Tue, 5 Apr 2005 04:13:57 -0700 Received: by wproxy.gmail.com with SMTP id 68so1874054wri for ; Tue, 05 Apr 2005 04:13:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gw79SUFsSKIHkAWPOipy04BOGlVHOlpQ0VcpwMp7pBJ+/DZwXKfmCmi7fF3zH44RNNHtzrphbs1FPihkDpGzF76mcKYphrl3Zf/dd+evoOi8pwARwm6bm77U+NBF4gY5z0Mebew2GSnBAJJoEEkkEm9HosQCZgyowUHEB2cakvo= Received: by 10.54.32.33 with SMTP id f33mr791485wrf; Tue, 05 Apr 2005 04:13:51 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Tue, 5 Apr 2005 04:13:51 -0700 (PDT) Message-ID: <39e6f6c70504050413666ea29d@mail.gmail.com> Date: Tue, 5 Apr 2005 08:13:51 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Marcel Holtmann Subject: Re: Some sleeping function called from invalid context Cc: Network Development Mailing List In-Reply-To: <1112693744.7960.2.camel@pegasus> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1112693744.7960.2.camel@pegasus> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On Apr 5, 2005 6:35 AM, Marcel Holtmann wrote: > Hi, > > while testing the latest kernel from the Bitkeeper repository, I got > some sleeping functions called from invalid context: > > Freeing unused kernel memory: 180k freed > Debug: sleeping function called from invalid context at mm/slab.c:2090 > in_atomic():1, irqs_disabled():0 > [] __might_sleep+0xa6/0xb0 > [] kmem_cache_alloc+0x73/0x80 > [] kmem_cache_create+0xfe/0x630 > [] proto_register+0x9d/0xc0 > [] af_unix_init+0x1c/0x7a [unix] > [] sys_init_module+0x1b2/0x290 > [] syscall_call+0x7/0xb > NET: Registered protocol family 1 Damn, thanks for reporting, looking at it now. - Arnaldo From johnpol@2ka.mipt.ru Tue Apr 5 04:20:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 04:20:27 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35BKHik012593 for ; Tue, 5 Apr 2005 04:20:18 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j35BIZju004751; Tue, 5 Apr 2005 15:18:36 +0400 Subject: Re: Netlink Connector / CBUS From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: hadi@cyberus.ca Cc: Herbert Xu , linux-kernel@vger.kernel.org, netdev , "David S. Miller" , James Morris , rml@novell.com, Greg KH , Andrew Morton In-Reply-To: <1112698800.1088.50.camel@jzny.localdomain> References: <1112686480.28858.17.camel@uganda> <1112697888.1089.44.camel@jzny.localdomain> <1112698800.1088.50.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sSnCz6Q18Ygv+8vLJ7Uc" Organization: MIPT Date: Tue, 05 Apr 2005 15:25:22 +0400 Message-Id: <1112700322.28858.42.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/762/Mon Mar 14 02:35:33 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 05 Apr 2005 15:18:39 +0400 (MSD) X-archive-position: 1406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-sSnCz6Q18Ygv+8vLJ7Uc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-04-05 at 07:00 -0400, jamal wrote: > and, oh yeah - wheres the documentation Evgeniy? ;-> In the tree :) Documentation/connector/connector.txt - some notes, API. Documentation/connector/cn_test.c - kernel example. Uses cn_netlink_send(), notification feature. I will send today a pathc that adds in-source documentation bits with some code cleanups. > cheers, > jamal >=20 > On Tue, 2005-04-05 at 06:44, jamal wrote: > > To be fair to Evgeniy I am not against the Konnector idea. I think that > > it is a useful feature to have an easy to use messaging between > > kernel-kernel and kernel-userspace. The fact that he leveraged netlink > > instead of inventing things is a bonus. Having said that i have not > > seriously scrutinized the code - and i think the idea of this new thing > > hes tossing around called CBUS maybe pushing it. > >=20 > > cheers, > > jamal > >=20 > > On Tue, 2005-04-05 at 03:34, Evgeniy Polyakov wrote: > > > On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: > > > >On Tue, Apr 05, 2005 at 11:03:16AM +0400, Evgeniy Polyakov wrote: > > > >>=20 > > > >> I received comments and feature requests from Herbert Xu and Jamal= Hadi > > > >> Salim, > > > >> almost all were successfully resolved. > > > > > > > >Please do not construe my involvement in these threads as endorsemen= t > > > >for this system. > > >=20 > > > Sure. > > > I remember you are against it :). > > >=20 > > > >In fact to this day I still don't understand what problems this thin= g is > > > >meant to solve. > > >=20 > > > Hmm, what else can I add to my words? > > > May be checking the size of the code needed to broadcast kobject chan= ges > > > in kobject_uevent.c for example... > > > Netlink socket allocation + skb handling against call to cn_netlink_s= end(). > > >=20 > > > >--=20 > > > >Visit Openswan at http://www.openswan.org/ > > > >Email: Herbert Xu ~{PmV>HI~} > > > >Home Page: http://gondor.apana.org.au/~herbert/ > > > >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > > >=20 > >=20 > >=20 > >=20 --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-sSnCz6Q18Ygv+8vLJ7Uc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCUnWiIKTPhE+8wY0RAlXXAJ9cqMiWKTv+jyUGIgqYjppnwYvvlACfYXx7 uJSA7Zm+fMplyqvjC2bt38w= =f8I/ -----END PGP SIGNATURE----- --=-sSnCz6Q18Ygv+8vLJ7Uc-- From lark@linux.net.cn Tue Apr 5 04:26:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 04:26:07 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35BPthO013417 for ; Tue, 5 Apr 2005 04:25:59 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 8B7B63EE49; Tue, 5 Apr 2005 19:25:50 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 26513-02-2; Tue, 5 Apr 2005 19:25:46 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id D78473EE29; Tue, 5 Apr 2005 19:25:45 +0800 (CST) Date: Tue, 05 Apr 2005 19:25:45 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: netdev@oss.sgi.com, jamal In-Reply-To: <20050405103827.GL26731@postel.suug.ch> References: <20050405140342.024A.LARK@linux.net.cn> <20050405103827.GL26731@postel.suug.ch> Message-Id: <20050405190024.024D.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j35BPthO013417 X-archive-position: 1407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Hi Thomas Graf, If you read the thread I pointed to, then you know there is chance that nfmark is used as two 16 bit numbers (along with CONNMARK), and the 16 bit number can be mapped to a classid. This is one of many chances. In that case, nfmark can be used like this 0x00010000 0x00020000 0x00030000 ... 0x00000001 0x00000002 0x00000003 ... The old hash function doesn't expect such pattern. I must admit that I am not very familiar with hash function. I find that and use a quick hack. My patch just points out the existing risk. Anyone can improve this by using a faster and even distributed hash function. And actually, for 256 as hash size, the second patch I sent can be still improved, return (jhash_1word(handle, 0xF30A7129) & 0xFF); instead of return (jhash_1word(handle, 0xF30A7129) % 256); On Tue, 5 Apr 2005 12:38:27 +0200, Thomas Graf wrote: > * Wang Jian <20050405140342.024A.LARK@linux.net.cn> 2005-04-05 14:05 > > New patch attached. Hashsize is 256, the same as old one. > > Do you have any numbers that could prove that this change > actually improves the hash distribution and thus the overall > lookup performance? > > The most often used and thus most important range of mark > values is definitely 0..255. I did not look into jhash > but the risk of collisions definitely increases with this > change which affects about 90% of the users of fw which > could benefit from a collision free hashtable so far. > > I would appreciate if you could provide some numbers proving > both the need and actual improvement of this change since > fwmark is one of the most often used classifiers. > > Cheers -- lark From hadi@cyberus.ca Tue Apr 5 04:58:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 04:58:42 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35BwYmd015757 for ; Tue, 5 Apr 2005 04:58:34 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DImhQ-0007Tf-Gi for netdev@oss.sgi.com; Tue, 05 Apr 2005 05:58:28 -0600 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DImhO-0004qp-9J; Tue, 05 Apr 2005 07:58:26 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Masahide NAKAMURA , "David S. Miller" , kaber@trash.net, netdev In-Reply-To: <20050405102238.GC23226@gondor.apana.org.au> References: <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> <1112696301.1089.30.camel@jzny.localdomain> <20050405102238.GC23226@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112702303.1095.107.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 07:58:23 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1408 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 Tue, 2005-04-05 at 06:22, Herbert Xu wrote: > Signed-off-by: Herbert Xu I have a feeling that Dave is not following this thread. All along we have been testing against 2.6.11.6; I just tested against -rc2 and found the patch applies with some fuzz. I fixed that as well as a couple of error messages Masahide didnt like. So please signoff instead the next patch i post in a new thread. cheers, jamal From hadi@cyberus.ca Tue Apr 5 05:03:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:03:40 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35C3W6k016689 for ; Tue, 5 Apr 2005 05:03:32 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DImmH-0008E0-TJ for netdev@oss.sgi.com; Tue, 05 Apr 2005 08:03:29 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DImmE-0005Ln-Dm; Tue, 05 Apr 2005 08:03:26 -0400 Subject: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Herbert Xu , Masahide NAKAMURA , kaber@trash.net, netdev Content-Type: multipart/mixed; boundary="=-/PvpckXwtyeuSTLx4Mw9" Organization: jamalopolous Message-Id: <1112702604.1089.119.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 08:03:24 -0400 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1409 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 --=-/PvpckXwtyeuSTLx4Mw9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Dave, Heres the final patch. What this patch provides - netlink xfrm events - ability to have events generated by netlink propagated to pfkey and vice versa. - fixes the acquire lets-be-happy-with-one-success issue cheers, jamal --=-/PvpckXwtyeuSTLx4Mw9 Content-Disposition: attachment; filename=ipsec-event-take2-6 Content-Type: text/plain; name=ipsec-event-take2-6; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005-04-05 07:19:11.000000000 -0400 +++ b/include/net/xfrm.h 2005-04-05 07:29:00.000000000 -0400 @@ -157,6 +157,28 @@ XFRM_STATE_DEAD }; +/* events that could be sent by kernel */ +enum { + XFRM_SAP_INVALID, + XFRM_SAP_EXPIRED, + XFRM_SAP_ADDED, + XFRM_SAP_UPDATED, + XFRM_SAP_DELETED, + XFRM_SAP_FLUSHED, + __XFRM_SAP_MAX +}; +#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) + +/* callback structure passed from either netlink or pfkey */ +struct km_event +{ + u32 data; + u32 seq; + u32 pid; + u32 event; +}; + + struct xfrm_type; struct xfrm_dst; struct xfrm_policy_afinfo { @@ -178,6 +200,9 @@ extern int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo); extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo); +extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c); +extern void km_state_notify(struct xfrm_state *x, struct km_event *c); + #define XFRM_ACQ_EXPIRES 30 @@ -283,17 +308,17 @@ struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; }; -#define XFRM_KM_TIMEOUT 30 +#define XFRM_KM_TIMEOUT 30 struct xfrm_mgr { struct list_head list; char *id; - int (*notify)(struct xfrm_state *x, int event); + int (*notify)(struct xfrm_state *x, struct km_event *c); int (*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir); struct xfrm_policy *(*compile_policy)(u16 family, int opt, u8 *data, int len, int *dir); int (*new_mapping)(struct xfrm_state *x, xfrm_address_t *ipaddr, u16 sport); - int (*notify_policy)(struct xfrm_policy *x, int dir, int event); + int (*notify_policy)(struct xfrm_policy *x, int dir, struct km_event *c); }; extern int xfrm_register_km(struct xfrm_mgr *km); @@ -805,7 +830,7 @@ extern int xfrm_state_update(struct xfrm_state *x); extern struct xfrm_state *xfrm_state_lookup(xfrm_address_t *daddr, u32 spi, u8 proto, unsigned short family); extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); -extern void xfrm_state_delete(struct xfrm_state *x); +extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto); extern int xfrm_replay_check(struct xfrm_state *x, u32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, u32 seq); --- a/include/linux/xfrm.h 2005-03-02 02:38:37.000000000 -0500 +++ b/include/linux/xfrm.h 2005-04-05 07:29:00.000000000 -0400 @@ -254,5 +254,7 @@ #define XFRMGRP_ACQUIRE 1 #define XFRMGRP_EXPIRE 2 +#define XFRMGRP_SA 4 +#define XFRMGRP_POLICY 8 #endif /* _LINUX_XFRM_H */ --- a/net/xfrm/xfrm_state.c 2005-04-05 07:19:30.000000000 -0400 +++ b/net/xfrm/xfrm_state.c 2005-04-05 07:29:00.000000000 -0400 @@ -50,7 +50,7 @@ static int xfrm_state_gc_flush_bundles; -static void __xfrm_state_delete(struct xfrm_state *x); +static int __xfrm_state_delete(struct xfrm_state *x); static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned short family); static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo); @@ -215,8 +215,10 @@ } EXPORT_SYMBOL(__xfrm_state_destroy); -static void __xfrm_state_delete(struct xfrm_state *x) +static int __xfrm_state_delete(struct xfrm_state *x) { + int err = -ESRCH; + if (x->km.state != XFRM_STATE_DEAD) { x->km.state = XFRM_STATE_DEAD; spin_lock(&xfrm_state_lock); @@ -245,14 +247,21 @@ * is what we are dropping here. */ atomic_dec(&x->refcnt); + err = 0; } + + return err; } -void xfrm_state_delete(struct xfrm_state *x) +int xfrm_state_delete(struct xfrm_state *x) { + int err; + spin_lock_bh(&x->lock); - __xfrm_state_delete(x); + err = __xfrm_state_delete(x); spin_unlock_bh(&x->lock); + + return err; } EXPORT_SYMBOL(xfrm_state_delete); @@ -430,6 +439,7 @@ static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; @@ -795,34 +805,60 @@ static struct list_head xfrm_km_list = LIST_HEAD_INIT(xfrm_km_list); static DEFINE_RWLOCK(xfrm_km_lock); -static void km_state_expired(struct xfrm_state *x, int hard) +void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct xfrm_mgr *km; - if (hard) - x->km.state = XFRM_STATE_EXPIRED; - else - x->km.dying = 1; + read_lock(&xfrm_km_lock); + list_for_each_entry(km, &xfrm_km_list, list) + if (km->notify_policy) + km->notify_policy(xp, dir, c); + read_unlock(&xfrm_km_lock); +} +void km_state_notify(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) - km->notify(x, hard); + if (km->notify) + km->notify(x, c); read_unlock(&xfrm_km_lock); +} + +EXPORT_SYMBOL(km_policy_notify); +EXPORT_SYMBOL(km_state_notify); + +static void km_state_expired(struct xfrm_state *x, int hard) +{ + struct km_event c; + + if (hard) + x->km.state = XFRM_STATE_EXPIRED; + else + x->km.dying = 1; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_state_notify(x, &c); if (hard) wake_up(&km_waitq); } +/* + * We send to all registered managers regardless of failure + * We are happy with one success +*/ static int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *pol) { - int err = -EINVAL; + int err = -EINVAL, acqret; struct xfrm_mgr *km; read_lock(&xfrm_km_lock); list_for_each_entry(km, &xfrm_km_list, list) { - err = km->acquire(x, t, pol, XFRM_POLICY_OUT); - if (!err) - break; + acqret = km->acquire(x, t, pol, XFRM_POLICY_OUT); + if (!acqret) + err = acqret; } read_unlock(&xfrm_km_lock); return err; @@ -847,13 +883,12 @@ void km_policy_expired(struct xfrm_policy *pol, int dir, int hard) { - struct xfrm_mgr *km; + struct km_event c; - read_lock(&xfrm_km_lock); - list_for_each_entry(km, &xfrm_km_list, list) - if (km->notify_policy) - km->notify_policy(pol, dir, hard); - read_unlock(&xfrm_km_lock); + c.data = hard; + c.data = hard; + c.event = XFRM_SAP_EXPIRED; + km_policy_notify(pol, dir, &c); if (hard) wake_up(&km_waitq); --- a/net/xfrm/xfrm_user.c 2005-03-02 02:38:10.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2005-04-05 07:47:45.000000000 -0400 @@ -268,6 +268,7 @@ struct xfrm_usersa_info *p = NLMSG_DATA(nlh); struct xfrm_state *x; int err; + struct km_event c; err = verify_newsa_info(p, (struct rtattr **) xfrma); if (err) @@ -277,6 +278,7 @@ if (!x) return err; + xfrm_state_hold(x); if (nlh->nlmsg_type == XFRM_MSG_NEWSA) err = xfrm_state_add(x); else @@ -285,14 +287,27 @@ if (err < 0) { x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); + return err; } + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + if (nlh->nlmsg_type == XFRM_MSG_NEWSA) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + + km_state_notify(x, &c); + xfrm_state_put(x); + return err; } static int xfrm_del_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { struct xfrm_state *x; + int err; + struct km_event c; struct xfrm_usersa_id *p = NLMSG_DATA(nlh); x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family); @@ -304,10 +319,19 @@ return -EPERM; } - xfrm_state_delete(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); xfrm_state_put(x); - return 0; + return err; } static void copy_to_user_state(struct xfrm_state *x, struct xfrm_usersa_info *p) @@ -335,6 +359,7 @@ int this_idx; }; + static int dump_one_state(struct xfrm_state *x, int count, void *ptr) { struct xfrm_dump_info *sp = ptr; @@ -672,6 +697,7 @@ { struct xfrm_userpolicy_info *p = NLMSG_DATA(nlh); struct xfrm_policy *xp; + struct km_event c; int err; int excl; @@ -683,6 +709,10 @@ if (!xp) return err; + /* shouldnt excl be based on nlh flags?? + * Aha! this is anti-netlink really i.e more pfkey derived + * in netlink excl is a flag and you wouldnt need + * a type XFRM_MSG_UPDPOLICY - JHS */ excl = nlh->nlmsg_type == XFRM_MSG_NEWPOLICY; err = xfrm_policy_insert(p->dir, xp, excl); if (err) { @@ -690,6 +720,16 @@ return err; } + + if (!excl) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; + + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); + xfrm_pol_put(xp); return 0; @@ -807,8 +847,10 @@ struct xfrm_policy *xp; struct xfrm_userpolicy_id *p; int err; + struct km_event c; int delete; + p = NLMSG_DATA(nlh); delete = nlh->nlmsg_type == XFRM_MSG_DELPOLICY; @@ -834,6 +876,11 @@ NETLINK_CB(skb).pid, MSG_DONTWAIT); } + } else { + c.event = XFRM_SAP_DELETED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(xp, p->dir, &c); } xfrm_pol_put(xp); @@ -843,15 +890,28 @@ static int xfrm_flush_sa(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); + c.data = p->proto; + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_state_notify(NULL, &c); + return 0; } static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma) { + struct km_event c; + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.seq = nlh->nlmsg_seq; + c.pid = nlh->nlmsg_pid; + km_policy_notify(NULL, 0, &c); return 0; } @@ -1053,10 +1113,11 @@ return -1; } -static int xfrm_send_state_notify(struct xfrm_state *x, int hard) +static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - + int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; @@ -1069,6 +1130,122 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_sa_flush(struct km_event *c) +{ + struct xfrm_usersa_flush *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, + XFRM_MSG_FLUSHSA, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + p->proto = c->data; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int inline xfrm_sa_len(struct xfrm_state *x) +{ + int l = NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)); + if (x->aalg) + l+= RTA_SPACE(sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8); + if (x->ealg) + l+= RTA_SPACE(sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8); + if (x->calg) + l+= RTA_SPACE(sizeof(*(x->calg))); + if (x->encap) + l+= RTA_SPACE(sizeof(*x->encap)); + + return l; +} + +static int xfrm_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct xfrm_usersa_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt; + unsigned char *b; + int len = xfrm_sa_len(x); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWSA; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDSA; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELSA; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh->nlmsg_flags = 0; + + p = NLMSG_DATA(nlh); + copy_to_user_state(x, p); + + if (x->aalg) + RTA_PUT(skb, XFRMA_ALG_AUTH, + sizeof(*(x->aalg))+(x->aalg->alg_key_len+7)/8, x->aalg); + if (x->ealg) + RTA_PUT(skb, XFRMA_ALG_CRYPT, + sizeof(*(x->ealg))+(x->ealg->alg_key_len+7)/8, x->ealg); + if (x->calg) + RTA_PUT(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg); + + if (x->encap) + RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_SA, GFP_ATOMIC); + +nlmsg_failure: +rtattr_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_state_notify(struct xfrm_state *x, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_EXPIRED: + return xfrm_exp_state_notify(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_ADDED: + return xfrm_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_sa_flush(c); + default: + printk("xfrm_user: Unknown SA event %d\n",c->event); + break; + } + + return 0; + +} + static int build_acquire(struct sk_buff *skb, struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) @@ -1202,7 +1379,8 @@ return -1; } -static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, int hard) + +static int xfrm_exp_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { struct sk_buff *skb; size_t len; @@ -1213,7 +1391,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, hard) < 0) + if (build_polexpire(skb, xp, dir, c->data) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1221,6 +1399,93 @@ return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_EXPIRE, GFP_ATOMIC); } +static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct xfrm_userpolicy_info *p; + struct nlmsghdr *nlh; + struct sk_buff *skb; + u32 nlt = 0 ; + unsigned char *b; + int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); + len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + if (c->event == XFRM_SAP_ADDED) + nlt = XFRM_MSG_NEWPOLICY; + else if (c->event == XFRM_SAP_UPDATED) + nlt = XFRM_MSG_UPDPOLICY; + else if (c->event == XFRM_SAP_DELETED) + nlt = XFRM_MSG_DELPOLICY; + else + goto nlmsg_failure; + + nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + + p = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = 0; + + copy_to_user_policy(xp, p, dir); + if (copy_to_user_tmpl(xp, skb) < 0) + goto nlmsg_failure; + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_notify_policy_flush(struct km_event *c) +{ + struct nlmsghdr *nlh; + struct sk_buff *skb; + unsigned char *b; + int len = NLMSG_LENGTH(0); + + skb = alloc_skb(len, GFP_ATOMIC); + if (skb == NULL) + return -ENOMEM; + b = skb->tail; + + + nlh = NLMSG_PUT(skb, c->pid, c->seq, XFRM_MSG_FLUSHPOLICY, 0); + + nlh->nlmsg_len = skb->tail - b; + + return netlink_broadcast(xfrm_nl, skb, 0, XFRMGRP_POLICY, GFP_ATOMIC); + +nlmsg_failure: + kfree_skb(skb); + return -1; +} + +static int xfrm_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + + switch (c->event) { + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + case XFRM_SAP_DELETED: + return xfrm_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return xfrm_notify_policy_flush(c); + case XFRM_SAP_EXPIRED: + return xfrm_exp_policy_notify(xp, dir, c); + default: + printk("xfrm_user: Unknown Policy event %d\n",c->event); + } + + return 0; + +} + static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, --- a/net/key/af_key.c 2005-04-05 07:19:26.000000000 -0400 +++ b/net/key/af_key.c 2005-04-05 07:48:31.000000000 -0400 @@ -1240,13 +1240,85 @@ return 0; } +static inline int event2poltype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_X_SPDDELETE; + case XFRM_SAP_ADDED: + return SADB_X_SPDADD; + case XFRM_SAP_UPDATED: + return SADB_X_SPDUPDATE; + case XFRM_SAP_EXPIRED: + // return SADB_X_SPDEXPIRE; + default: + printk("pfkey: Unknown policy event %d\n",event); + break; + } + + return 0; +} + +static inline int event2keytype (int event) +{ + switch (event) { + case XFRM_SAP_DELETED: + return SADB_DELETE; + case XFRM_SAP_ADDED: + return SADB_ADD; + case XFRM_SAP_UPDATED: + return SADB_UPDATE; + case XFRM_SAP_EXPIRED: + return SADB_EXPIRE; + default: + printk("pfkey: Unknown SA event %d\n",event); + break; + } + + return 0; +} + +/* ADD/UPD/DEL */ +static int key_notify_sa(struct xfrm_state *x, struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + int hsc = 3; + + if (c->event == XFRM_SAP_DELETED) + hsc = 0; + + if (c->event == XFRM_SAP_EXPIRED) { + if (c->data) + hsc = 2; + else + hsc = 1; + } + + skb = pfkey_xfrm_state2msg(x, 0, hsc); + + if (IS_ERR(skb)) + return PTR_ERR(skb); + + hdr = (struct sadb_msg *) skb->data; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_type = event2keytype(c->event); + hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + hdr->sadb_msg_errno = 0; + hdr->sadb_msg_reserved = 0; + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} static int pfkey_add(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_state *x; int err; + struct km_event c; xfrm_probe_algs(); @@ -1254,6 +1326,7 @@ if (IS_ERR(x)) return PTR_ERR(x); + xfrm_state_hold(x); if (hdr->sadb_msg_type == SADB_ADD) err = xfrm_state_add(x); else @@ -1265,27 +1338,23 @@ return err; } - out_skb = pfkey_xfrm_state2msg(x, 0, 3); - if (IS_ERR(out_skb)) - return PTR_ERR(out_skb); /* XXX Should we return 0 here ? */ - - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_reserved = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + if (hdr->sadb_msg_type == SADB_ADD) + c.event = XFRM_SAP_ADDED; + else + c.event = XFRM_SAP_UPDATED; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_delete(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { struct xfrm_state *x; + struct km_event c; + int err; if (!ext_hdrs[SADB_EXT_SA-1] || !present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], @@ -1301,13 +1370,19 @@ return -EPERM; } - xfrm_state_delete(x); - xfrm_state_put(x); + err = xfrm_state_delete(x); + if (err < 0) { + xfrm_state_put(x); + return err; + } - pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_ALL, sk); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_state_notify(x, &c); + xfrm_state_put(x); - return 0; + return err; } static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) @@ -1445,28 +1520,42 @@ return 0; } +static int key_notify_sa_flush(struct km_event *c) +{ + struct sk_buff *skb; + struct sadb_msg *hdr; + + skb = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); + if (!skb) + return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); + hdr->sadb_msg_satype = pfkey_proto2satype(c->data); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + + pfkey_broadcast(skb, GFP_ATOMIC, BROADCAST_ALL, NULL); + + return 0; +} + static int pfkey_flush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { unsigned proto; - struct sk_buff *skb_out; - struct sadb_msg *hdr_out; + struct km_event c; proto = pfkey_satype2proto(hdr->sadb_msg_satype); if (proto == 0) return -EINVAL; - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); - if (!skb_out) - return -ENOBUFS; - xfrm_state_flush(proto); - - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); + c.data = proto; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_FLUSHED; + km_state_notify(NULL, &c); return 0; } @@ -1859,6 +1948,35 @@ hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } +static int key_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) +{ + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + int err; + + out_skb = pfkey_xfrm_policy2msg_prep(xp); + if (IS_ERR(out_skb)) { + err = PTR_ERR(out_skb); + goto out; + } + pfkey_xfrm_policy2msg(out_skb, xp, dir); + + out_hdr = (struct sadb_msg *) out_skb->data; + out_hdr->sadb_msg_version = PF_KEY_V2; + + if (c->data && c->event == XFRM_SAP_DELETED) + out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; + else + out_hdr->sadb_msg_type = event2poltype(c->event); + out_hdr->sadb_msg_errno = 0; + out_hdr->sadb_msg_seq = c->seq; + out_hdr->sadb_msg_pid = c->pid; + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, NULL); +out: + return 0; + +} + static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { int err; @@ -1866,8 +1984,7 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1935,31 +2052,25 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; - } err = xfrm_policy_insert(pol->sadb_x_policy_dir-1, xp, hdr->sadb_msg_type != SADB_X_SPDUPDATE); + if (err) { - kfree_skb(out_skb); - goto out; + kfree(xp); + return err; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) + c.event = XFRM_SAP_UPDATED; + else + c.event = XFRM_SAP_ADDED; - xfrm_pol_put(xp); + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + xfrm_pol_put(xp); return 0; out: @@ -1973,9 +2084,8 @@ struct sadb_address *sa; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; struct xfrm_selector sel; + struct km_event c; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -2010,25 +2120,41 @@ err = 0; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + + xfrm_pol_put(xp); + return err; +} + + +static int key_pol_get_resp(struct sock *sk, struct xfrm_policy *xp, struct sadb_msg *hdr, int dir) +{ + int err; + struct sk_buff *out_skb; + struct sadb_msg *out_hdr; + err = 0; + out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); goto out; } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); + pfkey_xfrm_policy2msg(out_skb, xp, dir); out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = SADB_X_SPDDELETE; + out_hdr->sadb_msg_type = hdr->sadb_msg_type; out_hdr->sadb_msg_satype = 0; out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); + pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ONE, sk); err = 0; out: - xfrm_pol_put(xp); return err; } @@ -2037,8 +2163,7 @@ int err; struct sadb_x_policy *pol; struct xfrm_policy *xp; - struct sk_buff *out_skb; - struct sadb_msg *out_hdr; + struct km_event c; if ((pol = ext_hdrs[SADB_X_EXT_POLICY-1]) == NULL) return -EINVAL; @@ -2050,24 +2175,16 @@ err = 0; - out_skb = pfkey_xfrm_policy2msg_prep(xp); - if (IS_ERR(out_skb)) { - err = PTR_ERR(out_skb); - goto out; + c.seq = hdr->sadb_msg_seq; + c.pid = hdr->sadb_msg_pid; + if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { + c.data = 1; // to signal pfkey of SADB_X_SPDDELETE2 + c.event = XFRM_SAP_DELETED; + km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); + } else { + err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); } - pfkey_xfrm_policy2msg(out_skb, xp, pol->sadb_x_policy_dir-1); - out_hdr = (struct sadb_msg *) out_skb->data; - out_hdr->sadb_msg_version = hdr->sadb_msg_version; - out_hdr->sadb_msg_type = hdr->sadb_msg_type; - out_hdr->sadb_msg_satype = 0; - out_hdr->sadb_msg_errno = 0; - out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; - out_hdr->sadb_msg_pid = hdr->sadb_msg_pid; - pfkey_broadcast(out_skb, GFP_ATOMIC, BROADCAST_ALL, sk); - err = 0; - -out: xfrm_pol_put(xp); return err; } @@ -2102,22 +2219,33 @@ return xfrm_policy_walk(dump_sp, &data); } -static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +static int key_notify_policy_flush(struct km_event *c) { struct sk_buff *skb_out; - struct sadb_msg *hdr_out; - - skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_KERNEL); + struct sadb_msg *hdr; + skb_out = alloc_skb(sizeof(struct sadb_msg) + 16, GFP_ATOMIC); if (!skb_out) return -ENOBUFS; + hdr = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); + hdr->sadb_msg_seq = c->seq; + hdr->sadb_msg_pid = c->pid; + hdr->sadb_msg_version = PF_KEY_V2; + hdr->sadb_msg_errno = (uint8_t) 0; + hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); + pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL); + return 0; - xfrm_policy_flush(); +} - hdr_out = (struct sadb_msg *) skb_put(skb_out, sizeof(struct sadb_msg)); - pfkey_hdr_dup(hdr_out, hdr); - hdr_out->sadb_msg_errno = (uint8_t) 0; - hdr_out->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t)); - pfkey_broadcast(skb_out, GFP_KERNEL, BROADCAST_ALL, NULL); +static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) +{ + struct km_event c; + + xfrm_policy_flush(); + c.event = XFRM_SAP_FLUSHED; + c.pid = hdr->sadb_msg_pid; + c.seq = hdr->sadb_msg_seq; + km_policy_notify(NULL, 0, &c); return 0; } @@ -2317,11 +2445,24 @@ } } -static int pfkey_send_notify(struct xfrm_state *x, int hard) +/* XXX: Noisy for now */ +static int key_notify_policy_expire(struct xfrm_policy *xp, struct km_event *c) +{ + return 0; +} + +static int key_notify_sa_expire(struct xfrm_state *x, struct km_event *c) { struct sk_buff *out_skb; struct sadb_msg *out_hdr; - int hsc = (hard ? 2 : 1); + int hard; + int hsc; + + hard = c->data; + if (hard) + hsc = 2; + else + hsc = 1; out_skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(out_skb)) @@ -2340,6 +2481,43 @@ return 0; } +static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_sa_expire(x, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_sa(x, c); + case XFRM_SAP_FLUSHED: + return key_notify_sa_flush(c); + default: + printk("pfkey: Unknown SA event %d\n",c->event); + break; + } + + return 0; +} + +static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) +{ + switch (c->event) { + case XFRM_SAP_EXPIRED: + return key_notify_policy_expire(xp, c); + case XFRM_SAP_DELETED: + case XFRM_SAP_ADDED: + case XFRM_SAP_UPDATED: + return key_notify_policy(xp, dir, c); + case XFRM_SAP_FLUSHED: + return key_notify_policy_flush(c); + default: + printk("pfkey: Unknown policy event %d\n",c->event); + break; + } + + return 0; +} static u32 get_acqseq(void) { u32 res; @@ -2856,6 +3034,7 @@ .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, + .notify_policy = pfkey_send_policy_notify, }; static void __exit ipsec_pfkey_exit(void) --=-/PvpckXwtyeuSTLx4Mw9-- From herbert@gondor.apana.org.au Tue Apr 5 05:08:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:08:45 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35C8YCq017502 for ; Tue, 5 Apr 2005 05:08:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DImqj-0005W8-00; Tue, 05 Apr 2005 22:08:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DImq5-0006bF-00; Tue, 05 Apr 2005 22:07:25 +1000 Date: Tue, 5 Apr 2005 22:07:24 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , kaber@trash.net, netdev Subject: Re: PATCH: IPSEC xfrm events Message-ID: <20050405120724.GA25359@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112702604.1089.119.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 08:03:24AM -0400, jamal wrote: > > Heres the final patch. > What this patch provides > > - netlink xfrm events > - ability to have events generated by netlink propagated to pfkey > and vice versa. > - fixes the acquire lets-be-happy-with-one-success issue Jamal you forgot to sign off your own patch :) Anyway this looks good to me. Signed-off-by: Herbert Xu -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Tue Apr 5 05:15:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:15:52 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35CFkBG018601 for ; Tue, 5 Apr 2005 05:15:47 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C74D085; Tue, 5 Apr 2005 14:15:23 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id BFFF81C0EA; Tue, 5 Apr 2005 14:16:05 +0200 (CEST) Date: Tue, 5 Apr 2005 14:16:05 +0200 From: Thomas Graf To: Wang Jian Cc: netdev@oss.sgi.com, jamal Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050405121605.GM26731@postel.suug.ch> References: <20050405140342.024A.LARK@linux.net.cn> <20050405103827.GL26731@postel.suug.ch> <20050405190024.024D.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405190024.024D.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Wang Jian <20050405190024.024D.LARK@linux.net.cn> 2005-04-05 19:25 > If you read the thread I pointed to, then you know there is chance that > nfmark is used as two 16 bit numbers (along with CONNMARK), and the 16 > bit number can be mapped to a classid. This is one of many chances. > > In that case, nfmark can be used like this > > 0x00010000 > 0x00020000 > 0x00030000 > ... > > 0x00000001 > 0x00000002 > 0x00000003 > ... > > The old hash function doesn't expect such pattern. I'm aware of the problem you're facing, if the lower 8bits are set to 0 for a large amount of flows you get all that flows chained in the first hash bucket. > I must admit that I am not very familiar with hash function. I find that > and use a quick hack. My patch just points out the existing risk. Anyone > can improve this by using a faster and even distributed hash function. I can't really give you feedback on this since I don't have the background for this. Theoretically a hash size being a prime would do better but is stupid regarding slab efficiency. What I'm worried about is that we lose the zero collisions behaviour for the most popular use case. New idea: we make this configureable and allow 3 types of hash functions: 1) default as-is, perfect for marks 0..255 2) all bits taken into account (your patch) 3) bitmask + shift provided by the user just like dsmark. Thoughts? From arnaldo.melo@gmail.com Tue Apr 5 05:18:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:18:46 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35CIcna019303 for ; Tue, 5 Apr 2005 05:18:39 -0700 Received: by wproxy.gmail.com with SMTP id 68so1886518wri for ; Tue, 05 Apr 2005 05:18:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BCdr7gokxxBbrdZXIinEb96Ghwcw4BWSo0g6l7TUcUgfknz1diSYskNAONVXJjEH2u3OGoHHoirqvirHvhlzuxSU3Z72e3rNuZ7XPQOnMdLNNsgqF9Nl/gpDbZl3EapoyMDyW+yGFlAIubBiHh9QnjrwFlPcNk27wxN18kal90k= Received: by 10.54.32.33 with SMTP id f33mr837374wrf; Tue, 05 Apr 2005 05:18:33 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Tue, 5 Apr 2005 05:18:33 -0700 (PDT) Message-ID: <39e6f6c705040505186c1c62ed@mail.gmail.com> Date: Tue, 5 Apr 2005 09:18:33 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Marcel Holtmann Subject: Re: Some sleeping function called from invalid context Cc: Network Development Mailing List In-Reply-To: <39e6f6c70504050413666ea29d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1112693744.7960.2.camel@pegasus> <39e6f6c70504050413666ea29d@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On Apr 5, 2005 8:13 AM, Arnaldo Carvalho de Melo wrote: > On Apr 5, 2005 6:35 AM, Marcel Holtmann wrote: > > Hi, > > > > while testing the latest kernel from the Bitkeeper repository, I got > > some sleeping functions called from invalid context: > > > > Freeing unused kernel memory: 180k freed > > Debug: sleeping function called from invalid context at mm/slab.c:2090 > > in_atomic():1, irqs_disabled():0 > > [] __might_sleep+0xa6/0xb0 > > [] kmem_cache_alloc+0x73/0x80 > > [] kmem_cache_create+0xfe/0x630 > > [] proto_register+0x9d/0xc0 > > [] af_unix_init+0x1c/0x7a [unix] > > [] sys_init_module+0x1b2/0x290 > > [] syscall_call+0x7/0xb > > NET: Registered protocol family 1 > > Damn, thanks for reporting, looking at it now. Humm, recent changes in slab.[ch]... I'll try booting with a kernel without proto_register to see if this is some bug introduced by this changeset or if the problem would appear without it, that is my current guess, as we were doing a kmem_cache_create at module __init time before, and it uses SLAB_KERNEL at some point... I.e. with regards to per protocol slab cache creating at module init time we are doing the same thing as before the proto_register changeset, unless I'm missing some obvious thing... - Arnaldo From hadi@cyberus.ca Tue Apr 5 05:19:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:19:20 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35CJEqs019376 for ; Tue, 5 Apr 2005 05:19:14 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIn1T-00007F-06 for netdev@oss.sgi.com; Tue, 05 Apr 2005 08:19:11 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIn1R-0007LT-4E; Tue, 05 Apr 2005 08:19:09 -0400 Subject: Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , kaber@trash.net, netdev In-Reply-To: <20050405120724.GA25359@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050405120724.GA25359@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112703546.1089.137.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 08:19:06 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1413 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 Gah, Ok - I guess i too can be famous Signed-off-by: Jamal Hadi Salim cheers, jamal On Tue, 2005-04-05 at 08:07, Herbert Xu wrote: > > Jamal you forgot to sign off your own patch :) > > Anyway this looks good to me. > > Signed-off-by: Herbert Xu From arnaldo.melo@gmail.com Tue Apr 5 05:24:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:24:40 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35COZXk020915 for ; Tue, 5 Apr 2005 05:24:36 -0700 Received: by wproxy.gmail.com with SMTP id 68so1887802wri for ; Tue, 05 Apr 2005 05:24:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Bbnu7azeoT+8Z2gPRWhyzlZgKlGUx021VrBrCn5uToCfu3ROD6o5tEBVbu03J7NYokiFqY1BpA+1kqsi7Bp5rYPn50bIg7lTWZ685QH8hWXW1Iqgi7mHQAGfUVTIryVjFfYWNRkrIDLVOobAS2ccIN71DAq4qeE/lWkxa0aLXdU= Received: by 10.54.24.49 with SMTP id 49mr658857wrx; Tue, 05 Apr 2005 05:24:30 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Tue, 5 Apr 2005 05:24:30 -0700 (PDT) Message-ID: <39e6f6c705040505241c03d6ce@mail.gmail.com> Date: Tue, 5 Apr 2005 09:24:30 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: hadi@cyberus.ca Subject: Re: PATCH: IPSEC xfrm events Cc: Herbert Xu , "David S. Miller" , Masahide NAKAMURA , kaber@trash.net, netdev In-Reply-To: <1112703546.1089.137.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1112702604.1089.119.camel@jzny.localdomain> <20050405120724.GA25359@gondor.apana.org.au> <1112703546.1089.137.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 05 Apr 2005 08:19:06 -0400, jamal wrote: > > Gah, Ok - I guess i too can be famous Or funny! /me runs - Arnaldo From lark@linux.net.cn Tue Apr 5 05:39:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:39:55 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Cdj6S022240 for ; Tue, 5 Apr 2005 05:39:49 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id E753E3EE29; Tue, 5 Apr 2005 20:39:43 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 32277-04-4; Tue, 5 Apr 2005 20:39:41 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 7AC8C3EC0B; Tue, 5 Apr 2005 20:39:41 +0800 (CST) Date: Tue, 05 Apr 2005 20:39:41 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: netdev@oss.sgi.com, jamal In-Reply-To: <20050405121605.GM26731@postel.suug.ch> References: <20050405190024.024D.LARK@linux.net.cn> <20050405121605.GM26731@postel.suug.ch> Message-Id: <20050405202039.0250.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Hi Thomas Graf, On Tue, 5 Apr 2005 14:16:05 +0200, Thomas Graf wrote: > > What I'm worried about is that we lose the zero collisions behaviour > for the most popular use case. If a web interface is used to generate netfilter/tc rules that use nfmark, then the above assumption is false. nfmark will be used incrementally and wrapped back to 0 somewhere like process id. So zero collision is not likely. When linux's QoS control capability is widely used, such web interface sooner or later comes into being. > New idea: we make this configureable and allow 3 types of hash functions: > 1) default as-is, perfect for marks 0..255 > 2) all bits taken into account (your patch) > 3) bitmask + shift provided by the user just like > dsmark. > > Thoughts? Your suggestion is very considerable. But that needs some more work. And, isn't that some bloated? -- lark From tgraf@suug.ch Tue Apr 5 05:52:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:52:23 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35CqHwN023488 for ; Tue, 5 Apr 2005 05:52:18 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id B751385; Tue, 5 Apr 2005 14:51:54 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9066E1C0EA; Tue, 5 Apr 2005 14:52:37 +0200 (CEST) Date: Tue, 5 Apr 2005 14:52:37 +0200 From: Thomas Graf To: Wang Jian Cc: netdev@oss.sgi.com, jamal Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050405125237.GN26731@postel.suug.ch> References: <20050405190024.024D.LARK@linux.net.cn> <20050405121605.GM26731@postel.suug.ch> <20050405202039.0250.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405202039.0250.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Wang Jian <20050405202039.0250.LARK@linux.net.cn> 2005-04-05 20:39 > On Tue, 5 Apr 2005 14:16:05 +0200, Thomas Graf wrote: > > What I'm worried about is that we lose the zero collisions behaviour > > for the most popular use case. > > If a web interface is used to generate netfilter/tc rules that use > nfmark, then the above assumption is false. nfmark will be used > incrementally and wrapped back to 0 somewhere like process id. So zero > collision is not likely. I did not claim that the above assumption is true for all case but the most common use of cls_fw is static marks set by netfilter to values from 0..255. > When linux's QoS control capability is widely used, such web interface > sooner or later comes into being. That might be true but I will never ack on something that makes zero collision use of cls_fw impossible. I'm all for improving this but not at the cost of reduced performance for the most obvious use case of cls_fw. > Your suggestion is very considerable. But that needs some more work. And, > isn't that some bloated? The shift + bitmask might be bloated and can be deferred a bit until someone comes up with this need. I can cook up a patch for this if you want, it's not much work. From hadi@cyberus.ca Tue Apr 5 05:54:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 05:55:02 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Csu0M024169 for ; Tue, 5 Apr 2005 05:54:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIna1-0001hi-Ll for netdev@oss.sgi.com; Tue, 05 Apr 2005 08:54:53 -0400 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DInZz-0003sq-JD; Tue, 05 Apr 2005 08:54:51 -0400 Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: Thomas Graf , netdev In-Reply-To: <20050405202039.0250.LARK@linux.net.cn> References: <20050405190024.024D.LARK@linux.net.cn> <20050405121605.GM26731@postel.suug.ch> <20050405202039.0250.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112705689.1088.209.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 08:54:49 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1417 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 Tue, 2005-04-05 at 08:39, Wang Jian wrote: > Hi Thomas Graf, > > > On Tue, 5 Apr 2005 14:16:05 +0200, Thomas Graf wrote: > > > > > What I'm worried about is that we lose the zero collisions behaviour > > for the most popular use case. > > If a web interface is used to generate netfilter/tc rules that use > nfmark, then the above assumption is false. nfmark will be used > incrementally and wrapped back to 0 somewhere like process id. So zero > collision is not likely. > Yes, but the distribution is still very good even in that case. If you have 257 entries then all except for two will be in separate buckets. > When linux's QoS control capability is widely used, such web interface > sooner or later comes into being. > > > New idea: we make this configureable and allow 3 types of hash functions: > > 1) default as-is, perfect for marks 0..255 > > 2) all bits taken into account (your patch) > > 3) bitmask + shift provided by the user just like > > dsmark. > > > > Thoughts? > > Your suggestion is very considerable. But that needs some more work. And, > isn't that some bloated? > Why dont you run a quick test? Very easy to do in user space. Enter two sets of values using the two different approaches; yours and the current way tc uses nfmark (incremental). And then apply the jenkins approach you had to see how well it looks like? I thinkw e know how it will look with current hash - but if you can show its not so bad in the case of jenkins as well it may be an acceptable approach, cheers, jamal From herbert@gondor.apana.org.au Tue Apr 5 06:05:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 06:05:46 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35D5ago025358 for ; Tue, 5 Apr 2005 06:05:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DInjw-0005xw-00; Tue, 05 Apr 2005 23:05:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DInjV-0001Sk-00; Tue, 05 Apr 2005 23:04:41 +1000 Date: Tue, 5 Apr 2005 23:04:41 +1000 To: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: [IPV4] Disable MULTIPATH_CACHED on input path Message-ID: <20050405130441.GA5604@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Since we're not doing multipath selection on the input path yet, we should disable the code that inserts the multipath route entries for the input path. As it is we are inserting a whole bunch of useless entries as well as breaking multipath routing for the input path (forwarded packets) completely. I left the code around since we're planning to do this at some point. Signed-off-by: Herbert Xu As this code is going to stick around, I'm going to fix it :) Expect more patches soon. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/route.c 1.108 vs edited ===== --- 1.108/net/ipv4/route.c 2005-03-23 15:06:23 +11:00 +++ edited/net/ipv4/route.c 2005-04-05 23:00:28 +10:00 @@ -1720,7 +1720,7 @@ } rth->u.dst.flags= DST_HOST; -#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +#if 0 if (res->fi->fib_nhs > 1) rth->u.dst.flags |= DST_BALANCED; #endif @@ -1792,7 +1792,7 @@ struct in_device *in_dev, u32 daddr, u32 saddr, u32 tos) { -#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +#if 0 struct rtable* rth; unsigned char hop, hopcount, lasthop; int err = -EINVAL; --NzB8fVQJ5HfG6fxh-- From lark@linux.net.cn Tue Apr 5 06:30:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 06:30:09 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35DTxJH027860 for ; Tue, 5 Apr 2005 06:30:01 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 232473EE29; Tue, 5 Apr 2005 21:29:55 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 05481-01-4; Tue, 5 Apr 2005 21:29:50 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id CFCD13EC0B; Tue, 5 Apr 2005 21:29:50 +0800 (CST) Date: Tue, 05 Apr 2005 21:29:50 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: netdev@oss.sgi.com, jamal In-Reply-To: <20050405125237.GN26731@postel.suug.ch> References: <20050405202039.0250.LARK@linux.net.cn> <20050405125237.GN26731@postel.suug.ch> Message-Id: <20050405212711.0253.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Hi Thomas Graf, On Tue, 5 Apr 2005 14:52:37 +0200, Thomas Graf wrote: > > > When linux's QoS control capability is widely used, such web interface > > sooner or later comes into being. > > That might be true but I will never ack on something that makes zero > collision use of cls_fw impossible. I'm all for improving this but > not at the cost of reduced performance for the most obvious use case > of cls_fw. Agree. > > > Your suggestion is very considerable. But that needs some more work. And, > > isn't that some bloated? > > The shift + bitmask might be bloated and can be deferred a bit until > someone comes up with this need. I can cook up a patch for this > if you want, it's not much work. I am glad that you are willing to help to hook them up. I really need the new hashing way. -- lark From lark@linux.net.cn Tue Apr 5 07:19:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 07:19:12 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35EIxet031872 for ; Tue, 5 Apr 2005 07:19:01 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id C2CE03EE29; Tue, 5 Apr 2005 22:18:57 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 06147-01-4; Tue, 5 Apr 2005 22:18:53 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 2572F3EC0B; Tue, 5 Apr 2005 22:18:53 +0800 (CST) Date: Tue, 05 Apr 2005 22:18:53 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: Thomas Graf , netdev In-Reply-To: <1112705689.1088.209.camel@jzny.localdomain> References: <20050405202039.0250.LARK@linux.net.cn> <1112705689.1088.209.camel@jzny.localdomain> Message-Id: <20050405213023.0256.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Hi jamal, On 05 Apr 2005 08:54:49 -0400, jamal wrote: > > Why dont you run a quick test? Very easy to do in user space. > Enter two sets of values using the two different approaches; yours and > the current way tc uses nfmark (incremental). And then apply the jenkins > approach you had to see how well it looks like? I thinkw e know how it > will look with current hash - but if you can show its not so bad in the > case of jenkins as well it may be an acceptable approach, > I am not saying that we must use jenkins. We may use a less expensive hash function than jenkins, but better than & 0xFF. Anyway, I have done userspace test for jhash. The following test is done in a AMD Athlon 800MHz without other CPU load. -- snip jhash_test.c -- typedef unsigned long u32; typedef unsigned char u8; #include #include int main(void) { u32 i; u32 h; for (i = 0; i < 10000000; i++) { h = jhash_1word(i, 0xF30A7129) & 0xFFL; // printf("h is %u\n", h); } return 0; } -- snip -- [root@qos ~]# gcc jhash_test.c [root@qos ~]# time ./a.out 0.77user 0.00system 0:00.77elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+81minor)pagefaults 0swaps --snip simple_hash.c -- typedef unsigned long u32; typedef unsigned char u8; #include int main(void) { u32 i; u32 h; for (i = 0; i < 10000000; i++) { h = i & 0xFF; // printf("h is %u\n", h); } return 0; } -- snip -- [root@qos ~]# gcc simple_hash.c [root@qos ~]# time ./a.out 0.02user 0.00system 0:00.02elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+81minor)pagefaults 0swaps The simple method is far better in performance. For extreme situation, 100Mbps ethernet has about 148800 pps for TCP. Replace 10000000 with 150000. [root@qos ~]# time ./a.out 0.01user 0.00system 0:00.01elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+81minor)pagefaults 0swaps So use jhash is not big deal at 100Mbps. For 1000Mbps ethernet, replace 10000000 with 1489000. [root@qos ~]# time ./a.out 0.11user 0.00system 0:00.11elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+81minor)pagefaults 0swaps It's expected that a more hot CPU is used for GE, for example, 2.4GHz CPU. So 0.11 / (2.4/0.8) = 0.04. This is still not a big problem for a dedicated linux box for qos control. We know that 500Mbps is already a bottleneck here. -- lark From riel@redhat.com Tue Apr 5 08:05:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 08:05:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35F5ZfK002456 for ; Tue, 5 Apr 2005 08:05:35 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j35F5D1j000498; Tue, 5 Apr 2005 11:05:14 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j35F57O16884; Tue, 5 Apr 2005 11:05:07 -0400 Received: from chimarrao.boston.redhat.com (chimarrao.boston.redhat.com [172.16.80.75]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j35F56v8001627; Tue, 5 Apr 2005 11:05:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by chimarrao.boston.redhat.com (8.13.1/8.12.10) with ESMTP id j35F4nhj019134; Tue, 5 Apr 2005 11:04:59 -0400 Date: Tue, 5 Apr 2005 11:04:48 -0400 (EDT) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: jaganav@us.ibm.com cc: Greg KH , Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) In-Reply-To: <1112426991.424e49ef57e2b@imap.linux.ibm.com> Message-ID: References: <1112426991.424e49ef57e2b@imap.linux.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: riel@redhat.com Precedence: bulk X-list: netdev On Sat, 2 Apr 2005 jaganav@us.ibm.com wrote: > If this dual license is a concern to other kernel developers as well > from contributing to OpenRDMA, we would seriously consider this and > discuss with the adapter vendors. It could be a problem when trying to reuse existing GPL code, eg. to hook into locking mechanisms. It could also be a problem if you touch data structures that are protected by RCU. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From lark@linux.net.cn Tue Apr 5 08:25:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 08:25:50 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35FPZT4007710 for ; Tue, 5 Apr 2005 08:25:37 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 3C6603EE29 for ; Tue, 5 Apr 2005 23:25:33 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 06907-03-2 for ; Tue, 5 Apr 2005 23:25:28 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id B8A6D3EC0B for ; Tue, 5 Apr 2005 23:25:28 +0800 (CST) Date: Tue, 05 Apr 2005 23:25:28 +0800 From: Wang Jian To: netdev@oss.sgi.com Subject: [RFC] QoS: new per flow queue Message-Id: <20050405224956.0258.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4252A594050B033D6C20_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev --------_4252A594050B033D6C20_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I write a per flow rate control qdisc. I posted it to LARTC list. Some discussion about it is here http://mailman.ds9a.nl/pipermail/lartc/2005q2/015381.html I think I need more feedback and suggestion on it so I repost the patch here. Please read the thread and get a picture about why and how. The kernel patch is agains kernel 2.6.11, the iproute2 patch is against iproute2-2.6.11-050314. The test scenario is like this www server <- [ eth0 eth1 ] -> www clients The attached t.sh is used to generate test rules. Clients download a big ISO file from www server, so flows' rate can be estimated by view progress. I have some test on it and it works well. It provides good fairness. When all slot being used, in most time, the real rate can keep at specified guaranteed rate. But I know it should receive more test. I have some consideration though 1. In the test sometimes there a pair of unbalanced stream and don't get balanced quickly. One stream get 8.4kbps and another get 11.5kbps. How to find the flow with highest traffic and punish it most? 2. The default ceil equals to rate. Should I calculate it as ceil = rate * 1.05 * limit, or ceil = rate * 1.05? 3. when flow slots are full, optionally reclassify untraceable traffic into another specified class, instead of dropping it? TODO: 1. rtnetlink related code should be improved; 2. dump() and dump_stat(); Regards -- lark --------_4252A594050B033D6C20_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="t.sh" Content-Disposition: attachment; filename="t.sh" Content-Transfer-Encoding: base64 Li90YyBxZGlzYyBkZWwgZGV2IGV0aDEgcm9vdAouL3RjIHFkaXNjIGFkZCBkZXYgZXRoMSByb290 IGhhbmRsZSAxOiBodGIgZGVmYXVsdCAxMAouL3RjIGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJlbnQg MTogY2xhc3NpZCAxOjEgaHRiIHJhdGUgMTAwTWJpdCBjZWlsIDEwME1iaXQKCi4vdGMgY2xhc3Mg YWRkIGRldiBldGgxIHBhcmVudCAxOjEgY2xhc3NpZCAxOjEwIGh0YiByYXRlIDgwa2JwcyBjZWls IDgwa2JwcwoKLi90YyBjbGFzcyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6MSBjbGFzc2lkIDE6MTIg aHRiIHJhdGUgODBrYnBzIGNlaWwgODBrYnBzCi4vdGMgcWRpc2MgYWRkIGRldiBldGgxIHBhcmVu dCAxOjEyIGhhbmRsZSAyMDogcGVyZmxvdyByYXRlIDEwa2JwcyBjZWlsIDE1a2JwcyBsaW1pdCA3 Ci4vdGMgZmlsdGVyIGFkZCBkZXYgZXRoMSBwYXJlbnQgMTowIHByb3RvY29sIGlwIHUzMiBtYXRj aCBpcCBzcG9ydCA4MCAweGZmZmYgZmxvd2lkIDE6MTIK --------_4252A594050B033D6C20_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="iproute2-2.6.11-050314-perflow.diff" Content-Disposition: attachment; filename="iproute2-2.6.11-050314-perflow.diff" Content-Transfer-Encoding: base64 SW5kZXg6IGlwcm91dGUyLTIuNi4xMS13L2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gaXByb3V0ZTItMi42LjExLXcvaW5jbHVkZS9saW51eC9wa3Rfc2NoZWQuaAkocmV2 aXNpb24gMSkKKysrIGlwcm91dGUyLTIuNi4xMS13L2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgJ KHdvcmtpbmcgY29weSkKQEAgLTI3Miw2ICsyNzIsMjggQEAKIAlfX3UzMiBjdG9rZW5zOwogfTsK IAorCisvKiBQRVJGTE9XIHNlY3Rpb24gKi8KKworI2RlZmluZSBUQ19QRVJGTE9XX0RFRkFVTFRM SU1JVAkxMDI0CisKK3N0cnVjdCB0Y19wZXJmbG93X3FvcHQKK3sKKwlzdHJ1Y3QgdGNfcmF0ZXNw ZWMgCXJhdGU7CisJc3RydWN0IHRjX3JhdGVzcGVjIAljZWlsOworCV9fdTMyICBsaW1pdDsKKwlf X3UzMiAgcWxlbjsKK307CitlbnVtCit7CisJVENBX1BFUkZMT1dfVU5TUEVDLAorCVRDQV9QRVJG TE9XX1BBUk1TLAorCV9fVENBX1BFUkZMT1dfTUFYLAorfTsKKworI2RlZmluZSBUQ0FfUEVSRkxP V19NQVgJKF9fVENBX1BFUkZMT1dfTUFYIC0gMSkKKworCiAvKiBIRlNDIHNlY3Rpb24gKi8KIAog c3RydWN0IHRjX2hmc2NfcW9wdApJbmRleDogaXByb3V0ZTItMi42LjExLXcvdGMvcV9wZXJmbG93 LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gaXByb3V0ZTItMi42LjExLXcvdGMvcV9wZXJmbG93LmMJKHJldmlz aW9uIDApCisrKyBpcHJvdXRlMi0yLjYuMTEtdy90Yy9xX3BlcmZsb3cuYwkocmV2aXNpb24gMCkK QEAgLTAsMCArMSwxNTMgQEAKKy8qCisgKiBxX3BlcmZsb3cuYwkJUEVSRkxPVy4KKyAqCisgKgkJ VGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu ZC9vcgorICoJCW1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlCisgKgkJYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k YXRpb247IGVpdGhlciB2ZXJzaW9uCisgKgkJMiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIg b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiBBdXRob3JzOglXYW5nIEppYW4gPGxh cmtAbGludXgubmV0LmNuPiwgMjAwNQorICoKKyAqLworCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNp bmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDx1bmlzdGQuaD4KKyNpbmNsdWRlIDxzeXNsb2cu aD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRl IDxuZXRpbmV0L2luLmg+CisjaW5jbHVkZSA8YXJwYS9pbmV0Lmg+CisjaW5jbHVkZSA8c3RyaW5n Lmg+CisKKyNpbmNsdWRlICJ1dGlscy5oIgorI2luY2x1ZGUgInRjX3V0aWwuaCIKKworc3RhdGlj IHZvaWQgZXhwbGFpbih2b2lkKQoreworCWZwcmludGYoc3RkZXJyLAorIlVzYWdlOiAuLi4gcGVy ZmxvdyByYXRlIFJBVEUgWyBjZWlsIENFSUwgXSBbIGxpbWl0IExJTUlUIF0gWyBxbGVuIFFMRU4g XVxuIgorIlxuIgorInJhdGUgICAgcmF0ZSBhbGxvY2F0ZWQgdG8gZWFjaCBmbG93IChmbG93IGNh biBzdGlsbCBib3Jyb3cpXG4iCisiY2VpbCAgICB1cHBlciBsaW1pdCBmb3IgZWFjaCBmbG93IChm bG93IGNhbiBub3QgYm9ycm93KVxuIgorImxpbWl0ICAgbWF4aW11bSBjb25jdXJyZW50IGZsb3dz XG4iCisicWxlbiAgICBtYXhpbXVtIHF1ZXVlIGxlbmd0aFxuIgorCSk7Cit9CisKKyNkZWZpbmUg dXNhZ2UoKSByZXR1cm4oLTEpCisKK3N0YXRpYyBpbnQgcGVyZmxvd19wYXJzZV9vcHQoc3RydWN0 IHFkaXNjX3V0aWwgKnF1LCBpbnQgYXJnYywgY2hhciAqKmFyZ3YsIHN0cnVjdCBubG1zZ2hkciAq bikKK3sKKwlzdHJ1Y3QgdGNfcGVyZmxvd19xb3B0IG9wdDsKKwlzdHJ1Y3QgcnRhdHRyICp0YWls OworCWludCBvayA9IDA7CisKKwltZW1zZXQoJm9wdCwgMCwgc2l6ZW9mKG9wdCkpOworCisJd2hp bGUgKGFyZ2MgPiAwKSB7CisJCWlmIChzdHJjbXAoKmFyZ3YsICJyYXRlIikgPT0gMCkgeworCQkJ TkVYVF9BUkcoKTsKKwkJCWlmIChvcHQucmF0ZS5yYXRlKSB7CisJCQkJZnByaW50ZihzdGRlcnIs ICJEb3VibGUgXCJjZWlsXCIgc3BlY1xuIik7CisJCQkJcmV0dXJuIC0xOworCQkJfQorCQkJaWYg KGdldF9yYXRlKCZvcHQucmF0ZS5yYXRlLCAqYXJndikpIHsKKwkJCQlmcHJpbnRmKHN0ZGVyciwg IklsbGVnYWwgXCJyYXRlXCJcbiIpOworCQkJCXJldHVybiAtMTsKKwkJCX0KKwkJCW9rKys7CisJ CX0gZWxzZSBpZiAoc3RyY21wKCphcmd2LCAiY2VpbCIpID09IDApIHsKKwkJCU5FWFRfQVJHKCk7 CisJCQlpZiAob3B0LmNlaWwucmF0ZSkgeworCQkJCWZwcmludGYoc3RkZXJyLCAiRG91YmxlIFwi Y2VpbFwiIHNwZWNcbiIpOworCQkJCXJldHVybiAtMTsKKwkJCX0KKwkJCWlmIChnZXRfcmF0ZSgm b3B0LmNlaWwucmF0ZSwgKmFyZ3YpKSB7CisJCQkJZnByaW50ZihzdGRlcnIsICJJbGxlZ2FsIFwi Y2VpbFwiXG4iKTsKKwkJCQlyZXR1cm4gLTE7CisJCQl9CisJCQlvaysrOworCQl9IGVsc2UgaWYg KHN0cmNtcCgqYXJndiwgImxpbWl0IikgPT0gMCkgeworCQkJTkVYVF9BUkcoKTsKKwkJCWlmIChn ZXRfc2l6ZSgmb3B0LmxpbWl0LCAqYXJndikpIHsKKwkJCQlmcHJpbnRmKHN0ZGVyciwgIklsbGVn YWwgXCJsaW1pdFwiXG4iKTsKKwkJCQlyZXR1cm4gLTE7CisJCQl9CisJCQlvaysrOworCQl9IGVs c2UgaWYgKHN0cmNtcCgqYXJndiwgInFsZW4iKSA9PSAwKSB7CisJCQlORVhUX0FSRygpOworCQkJ aWYgKGdldF9zaXplKCZvcHQucWxlbiwgKmFyZ3YpKSB7CisJCQkJZnByaW50ZihzdGRlcnIsICJJ bGxlZ2FsIFwibGltaXRcIlxuIik7CisJCQkJcmV0dXJuIC0xOworCQkJfQorCQkJb2srKzsKKwkJ fSBlbHNlIGlmIChzdHJjbXAoKmFyZ3YsICJoZWxwIikgPT0gMCkgeworCQkJZXhwbGFpbigpOwor CQkJcmV0dXJuIC0xOworCQl9IGVsc2UgeworCQkJZnByaW50ZihzdGRlcnIsICJXaGF0IGlzIFwi JXNcIj9cbiIsICphcmd2KTsKKwkJCWV4cGxhaW4oKTsKKwkJCXJldHVybiAtMTsKKwkJfQorCQlh cmdjLS07IGFyZ3YrKzsKKwl9CisKKwlpZiAoIW9rKQorCQlyZXR1cm4gMDsKKworCWlmIChvcHQu cmF0ZS5yYXRlID09IDApIHsKKwkJZnByaW50ZihzdGRlcnIsICJcInJhdGVcIiBpcyByZXF1aXJl ZC5cbiIpOworCQlyZXR1cm4gLTE7CisJfQorCisJaWYgKG9wdC5jZWlsLnJhdGUgPT0gMCkKKwkJ b3B0LmNlaWwgPSBvcHQucmF0ZTsKKworCWlmIChvcHQuY2VpbC5yYXRlIDwgb3B0LnJhdGUucmF0 ZSkgeworCQlmcHJpbnRmKHN0ZGVyciwgIlwiY2VpbFwiIG11c3QgYmUgPj0gXCJyYXRlXCIuXG4i KTsKKwkJcmV0dXJuIC0xOworCX0KKworCWlmIChvcHQubGltaXQgPT0gMCkKKwkJb3B0LmxpbWl0 ID0gVENfUEVSRkxPV19ERUZBVUxUTElNSVQ7CisKKwlpZiAob3B0LnFsZW4gPiAwICYmIG9wdC5x bGVuIDwgNSkgeworCQlmcHJpbnRmKHN0ZGVyciwgIlwicWxlblwiIG11c3QgYmUgPj0gNS5cbiIp OworCQlyZXR1cm4gLTE7CisJfQorCisJdGFpbCA9IE5MTVNHX1RBSUwobik7CisJLy9hZGRhdHRy X2wobiwgMTAyNCwgVENBX09QVElPTlMsIE5VTEwsIDApOworCS8vYWRkYXR0cl9sKG4sIDEwMjQs IFRDQV9QRVJGTE9XX1BBUk1TLCAmb3B0LCBzaXplb2Yob3B0KSk7CisJYWRkYXR0cl9sKG4sIDEw MjQsIFRDQV9PUFRJT05TLCAmb3B0LCBzaXplb2Yob3B0KSk7CisJdGFpbC0+cnRhX2xlbiA9ICh2 b2lkICopIE5MTVNHX1RBSUwobikgLSAodm9pZCAqKSB0YWlsOworCisJcmV0dXJuIDA7Cit9CisK K3N0YXRpYyBpbnQgcGVyZmxvd19wcmludF9vcHQoc3RydWN0IHFkaXNjX3V0aWwgKnF1LCBGSUxF ICpmLCBzdHJ1Y3QgcnRhdHRyICpvcHQpCit7CisJc3RydWN0IHRjX3BlcmZsb3dfcW9wdCAqcW9w dDsKKworCWlmIChvcHQgPT0gTlVMTCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoUlRBX1BBWUxPQUQo b3B0KSA8IHNpemVvZigqcW9wdCkpCisJCXJldHVybiAtMTsKKworCXFvcHQgPSBSVEFfREFUQShv cHQpOworCisJU1BSSU5UX0JVRihiMSk7CisJZnByaW50ZihmLCAicmF0ZSAlcyAiLCBzcHJpbnRf cmF0ZShxb3B0LT5yYXRlLnJhdGUsIGIxKSk7CisJZnByaW50ZihmLCAiY2VpbCAlcyAiLCBzcHJp bnRfcmF0ZShxb3B0LT5jZWlsLnJhdGUsIGIxKSk7CisJZnByaW50ZihmLCAibGltaXQgJXMgIiwg c3ByaW50X3NpemUocW9wdC0+cmF0ZS5yYXRlLCBiMSkpOworCisJcmV0dXJuIDA7Cit9CisKK3N0 cnVjdCBxZGlzY191dGlsIHBlcmZsb3dfcWRpc2NfdXRpbCA9IHsKKwkuaWQJCT0gInBlcmZsb3ci LAorCS5wYXJzZV9xb3B0CT0gcGVyZmxvd19wYXJzZV9vcHQsCisJLnByaW50X3FvcHQJPSBwZXJm bG93X3ByaW50X29wdCwKK307CkluZGV4OiBpcHJvdXRlMi0yLjYuMTEtdy90Yy9NYWtlZmlsZQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBpcHJvdXRlMi0yLjYuMTEtdy90Yy9NYWtlZmlsZQkocmV2aXNpb24gMSkK KysrIGlwcm91dGUyLTIuNi4xMS13L3RjL01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC03LDYg KzcsNyBAQAogVENNT0RVTEVTICs9IHFfZmlmby5vCiBUQ01PRFVMRVMgKz0gcV9zZnEubwogVENN T0RVTEVTICs9IHFfcmVkLm8KK1RDTU9EVUxFUyArPSBxX3BlcmZsb3cubwogVENNT0RVTEVTICs9 IHFfcHJpby5vCiBUQ01PRFVMRVMgKz0gcV90YmYubwogVENNT0RVTEVTICs9IHFfY2JxLm8K --------_4252A594050B033D6C20_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="linux-2.6.11-perflow-r3.diff" Content-Disposition: attachment; filename="linux-2.6.11-perflow-r3.diff" Content-Transfer-Encoding: base64 SW5kZXg6IGxpbnV4LTIuNi4xMS13L2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gbGludXgtMi42LjExLXcvaW5jbHVkZS9saW51eC9wa3Rfc2NoZWQuaAkocmV2aXNpb24g MikKKysrIGxpbnV4LTIuNi4xMS13L2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgJKHJldmlzaW9u IDMpCkBAIC0yNzIsNiArMjcyLDI4IEBACiAJX191MzIgY3Rva2VuczsKIH07CiAKKworLyogUEVS RkxPVyBzZWN0aW9uICovCisKKyNkZWZpbmUgVENfUEVSRkxPV19ERUZBVUxUTElNSVQJMTAyNAor CitzdHJ1Y3QgdGNfcGVyZmxvd19xb3B0Cit7CisJc3RydWN0IHRjX3JhdGVzcGVjIAlyYXRlOwor CXN0cnVjdCB0Y19yYXRlc3BlYyAJY2VpbDsKKwlfX3UzMiAgbGltaXQ7CisJX191MzIgIHFsZW47 Cit9OworZW51bQoreworCVRDQV9QRVJGTE9XX1VOU1BFQywKKwlUQ0FfUEVSRkxPV19QQVJNUywK KwlfX1RDQV9QRVJGTE9XX01BWCwKK307CisKKyNkZWZpbmUgVENBX1BFUkZMT1dfTUFYCShfX1RD QV9QRVJGTE9XX01BWCAtIDEpCisKKwogLyogSEZTQyBzZWN0aW9uICovCiAKIHN0cnVjdCB0Y19o ZnNjX3FvcHQKSW5kZXg6IGxpbnV4LTIuNi4xMS13L25ldC9zY2hlZC9LY29uZmlnCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIGxpbnV4LTIuNi4xMS13L25ldC9zY2hlZC9LY29uZmlnCShyZXZpc2lvbiAyKQorKysg bGludXgtMi42LjExLXcvbmV0L3NjaGVkL0tjb25maWcJKHJldmlzaW9uIDMpCkBAIC0xOTIsNiAr MTkyLDE1IEBACiAJICBUbyBjb21waWxlIHRoaXMgY29kZSBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g aGVyZTogdGhlCiAJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc2NoX2dyZWQuCiAKK2NvbmZpZyBO RVRfU0NIX1BFUkZMT1cKKwl0cmlzdGF0ZSAiUEVSRkxPVyBxdWV1ZSIKKwlkZXBlbmRzIG9uIE5F VF9TQ0hFRAorCS0tLWhlbHAtLS0KKwkgIFNheSBZIGhlcmUgaWYgeW91IHdhbnQgdG8gdXNlIHBl ciBmbG93IHJhdGUgY29udHJvbC4KKworCSAgVG8gY29tcGlsZSB0aGlzIGNvZGUgYXMgYSBtb2R1 bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHNjaF9wZXJm bG93LgorCiBjb25maWcgTkVUX1NDSF9EU01BUksKIAl0cmlzdGF0ZSAiRGlmZnNlcnYgZmllbGQg bWFya2VyIgogCWRlcGVuZHMgb24gTkVUX1NDSEVECkluZGV4OiBsaW51eC0yLjYuMTEtdy9uZXQv c2NoZWQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbGludXgtMi42LjExLXcvbmV0L3NjaGVkL01h a2VmaWxlCShyZXZpc2lvbiAyKQorKysgbGludXgtMi42LjExLXcvbmV0L3NjaGVkL01ha2VmaWxl CShyZXZpc2lvbiAzKQpAQCAtMTksNiArMTksNyBAQAogb2JqLSQoQ09ORklHX05FVF9TQ0hfSEZT QykJKz0gc2NoX2hmc2Mubwogb2JqLSQoQ09ORklHX05FVF9TQ0hfUkVEKQkrPSBzY2hfcmVkLm8K IG9iai0kKENPTkZJR19ORVRfU0NIX0dSRUQpCSs9IHNjaF9ncmVkLm8KK29iai0kKENPTkZJR19O RVRfU0NIX1BFUkZMT1cpCSs9IHNjaF9wZXJmbG93Lm8KIG9iai0kKENPTkZJR19ORVRfU0NIX0lO R1JFU1MpCSs9IHNjaF9pbmdyZXNzLm8gCiBvYmotJChDT05GSUdfTkVUX1NDSF9EU01BUkspCSs9 IHNjaF9kc21hcmsubwogb2JqLSQoQ09ORklHX05FVF9TQ0hfU0ZRKQkrPSBzY2hfc2ZxLm8KSW5k ZXg6IGxpbnV4LTIuNi4xMS13L25ldC9zY2hlZC9zY2hfcGVyZmxvdy5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IGxpbnV4LTIuNi4xMS13L25ldC9zY2hlZC9zY2hfcGVyZmxvdy5jCShyZXZpc2lvbiAwKQorKysg bGludXgtMi42LjExLXcvbmV0L3NjaGVkL3NjaF9wZXJmbG93LmMJKHJldmlzaW9uIDMpCkBAIC0w LDAgKzEsNTU1IEBACisvKgorICogbmV0L3NjaGVkL3NjaF9wZXJmbG93LmMJUGVyIGZsb3cgcmF0 ZSBjb250cm9sIHF1ZXVlLgorICoKKyAqCVRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5 b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKKyAqCW1vZGlmeSBpdCB1bmRlciB0aGUgdGVy bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKglhcyBwdWJsaXNoZWQgYnkg dGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24KKyAqCTIgb2YgdGhl IExpY2Vuc2UsIG9yIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICog QXV0aG9yczoJV2FuZyBKaWFuIDxsYXJrQGxpbnV4Lm5ldC5jbj4sIDIwMDUKKyAqCisgKi8KKwor I2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgorI2lu Y2x1ZGUgPGFzbS91YWNjZXNzLmg+CisjaW5jbHVkZSA8bGludXgvYml0b3BzLmg+CisjaW5jbHVk ZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNpbmNsdWRlIDxs aW51eC9zY2hlZC5oPgorI2luY2x1ZGUgPGxpbnV4L3N0cmluZy5oPgorI2luY2x1ZGUgPGxpbnV4 L21tLmg+CisjaW5jbHVkZSA8bGludXgvc29ja2V0Lmg+CisjaW5jbHVkZSA8bGludXgvc29ja2lv cy5oPgorI2luY2x1ZGUgPGxpbnV4L2luLmg+CisjaW5jbHVkZSA8bGludXgvZXJybm8uaD4KKyNp bmNsdWRlIDxsaW51eC9pbnRlcnJ1cHQuaD4KKyNpbmNsdWRlIDxsaW51eC9pZl9ldGhlci5oPgor I2luY2x1ZGUgPGxpbnV4L2luZXQuaD4KKyNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4KKyNp bmNsdWRlIDxsaW51eC9ldGhlcmRldmljZS5oPgorI2luY2x1ZGUgPGxpbnV4L25vdGlmaWVyLmg+ CisjaW5jbHVkZSA8bGludXgvamhhc2guaD4KKyNpbmNsdWRlIDxsaW51eC90aW1lci5oPgorI2lu Y2x1ZGUgPG5ldC9pcC5oPgorI2luY2x1ZGUgPG5ldC9yb3V0ZS5oPgorI2luY2x1ZGUgPGxpbnV4 L3NrYnVmZi5oPgorI2luY2x1ZGUgPG5ldC9zb2NrLmg+CisjaW5jbHVkZSA8bmV0L3BrdF9zY2hl ZC5oPgorI2luY2x1ZGUgPG5ldC9pbmV0X2Vjbi5oPgorI2luY2x1ZGUgPG5ldC9kc2ZpZWxkLmg+ CisKKy8qIFBlciBmbG93IHJhdGUgY29udHJvbCBhbGdvcml0aG0KKworRGVzY3JpcHRpb24KKy0t LS0tLS0tLS0tCisKKwlXaGVuIGEgbmV3IHBhY2tldCBhcnJpdmVzLCB3ZSBsb29rdXAgaW4gdGhl IHRhYmxlIHRvIHNlZSBpZiBpdAorCWJlbG9uZ3MgdG8gYSBmbG93IGJlaW5nIHRyYWNlZC4gSWYg bm90LCB3ZSBjcmVhdGUgbmV3IGVudHJ5IGZvciBpdC4KKworCUZvciBhIHBhY2tldCBiZWxvbmdz IHRvIGEgZmxvdyBiZWluZyB0cmFjZWQsIHdlIHNlZSBpZiBpdCBoYXMKKwlhdmFpbGFibGUgdG9r ZW4gdG8gc2VuZCBpdCBvdXQuCisKKwlUaGUgJ3JhdGUnIGFuZCAnY2VpbCcgaGF2ZSBzYW1lIG1l YW5pbmcgb2YgSFRCIHFkaXNjLiBUaGUgJ2xpbWl0JworCXBhcmFtZXRlciBkZWZpbmVkIGhvdyBt YW55IGZsb3dzIHdlIHdpbGwgdHJhY2UsIHdoaWNoIGRlZmF1bHRzIHRvCisJMTAyNC4KKworCUFu eSBmbG93IGVudHJ5IHdpdGhvdXQgdHJhZmZpYyBpbiBMSUZFVElNRSBzZWNvbmRzIHdpbGwgYmUg d2lwZWQKKwl0byBmcmVlIHNsb3QuCisKKworQWxnb3JpdGhtCistLS0tLS0tLS0KKworCVRoZSBh bGdvcml0aG0gaXMgc2ltcGxlIGFuZCBuYWl2ZS4gV2UgaGF2ZSBhIHRva2VuIGJ1Y2tldCwgd2hp Y2gKKwlnZW5lcmF0ZSBncmF0ZS8xMCAoPSByYXRlICogbGltaXQgLyAxMCkgdG9rZW4gaW4gMS8x MCBzZWNvbmRzLgorCisJQSBmbG93IGNhbiBhbHdheXMgc2VuZCB3aGVuIGl0IGlzIHVuZGVyIHJh dGUuIFdoZW4gYSBmbG93IGlzIG92ZXIKKwlyYXRlIGJ1dCB1bmRlciBjZWlsLCBldmVyeSB0aW1l IGl0IGJvcnJvd3MsIGl0IGlzIHB1dCBpbnRvIGJvcnJvdworCWxpc3QsIHNvIGl0IG1heSByZWNl aXZlIHBlbmFsdHkuCisKKwlXaGVuIGEgdW5kZXItcmF0ZSBmbG93IHNlbmRzIGJ1dCB0b2tlbiBp cyBzaG9ydCwgcGVuYWx0eSBpcyBhZGRlZAorCXRvIG9uZSBvZiBmbG93cyBpbiBib3Jyb3cgbGlz dCwgYW5kIHRoaXMgcHVuaXNoZWQgZmxvdyBpcworCXJlbW92ZWQgZnJvbSBib3Jyb3cgbGlzdC4K KworCVdoZW4gYSBmbG93IGNhcnJ5aW5nIHBlbmFsdHkgaGFzIHBhY2tldCwgdGhlIHBlbmFsdHkg aXMKKwlhZGRlZCB0byB1c2VkIHRva2VuLiBUaGlzIG1lYW5zLCB0aGlzIGZsb3cgY2FuIGJvcnJv dyBsZXNzIHRoYW4KKwlsYXN0IHRpbWUgKGlmIGluIGEgbmV3IHRpbWUgc2xvdCksIG9yIGNhbiBi b3Jyb3cgbGVzcyAKKwkoY2VpbCAtIHJhdGUgLSBwZW5hbHR5KS4KKworCVRoZXJlIGFyZSBvdGhl ciBydWxlcyB0aGF0IGhhbmRsZSBmYWlybmVzcyBhbmQgbG93IHJhdGUgc2l0dWF0aW9uLgorCVNl ZSBjb2RlIGZvciBkZXRhaWxzLgorCisJTk9URTogdGhlIGltcGxlbWVudGF0aW9uIG9mIGFsZ29y aXRobSBpcyBub3QgdGltZXIgZHJpdmVuLCBidXQKKwlwYWNrZXQgZHJpdmVuLgorCisJVGhlIGlk ZWFzIGJlaGluZCB0aGlzIGFsZ29yaXRobSBhcmUKKworCTEuIFdlIGFzc3VtZSB0aGF0IHBlcmZs b3cgcWRpc2MgaGFzIHJhdGUgKiBsaW1pdCBndWFyYW50ZWVkLgorCTIuIFdlIGNhbid0IGFmZmVj dCBwYXN0LiBXZSBjYW4gb25seSBhZmZlY3QgZnV0dXJlLgorCTMuIElmIGEgZmxvdydzIGJvcnJv d2luZyBsZWFkcyB0byBvdmVybGltaXQsIHdlIGxldCB0aGlzIGZsb3cKKwkgICBib3Jyb3cgbGVz cyBpbiBmdXR1cmUuCisJNC4gV2l0aCBhIHJvdW5kIHJvYmluIHB1bmlzaG1lbnQgc3R5bGUsIGEg ZmxvdyBib3Jyb3dzIG1vcmUgdGltZXMsCisJICAgaXQgc3RheXMgaW4gYm9ycm93IGxpc3QgbW9y ZSB0aW1lcywgYW5kIHNvIHJlY2VpdmVzIG1vcmUgcGVuYWx0eS4KKwkgICAoQnV0IHdlIHNob3Vs ZCBjb25zaWRlciBtb3JlIGFib3V0IHRoaXMsIEkgdGhpbmsgdGhlIGZhaXJuZXNzCisJICAgc2hv dWxkIGJlIGltcHJvdmVkIGJ5IHNvcnQgYm9ycm93IGxpc3QuKQorCisKK1NlY3VyaXR5IENvbnNp ZGVyYXRpb24KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKworCUl0J3MgZGFuZ2Vyb3VzIHRvIGNy ZWF0ZSBuZXcgZW50cnkgZm9yIGFueSBuZXcgcGFja2V0cyBub3QgYmVsb25ncworCXRvIGEgZmxv dyBiZWluZyB0cmFjZWQuIEZvciBleGFtcGxlLCBzeW4gZmxvb2QgYXR0YWNrIG9uIGEgc2luZ2xl CisJcG9ydCBtYXkgY2F1c2UgdGhvdXNhbmRzIG9mIGVudHJpZXMgY3JlYXRlZC4gVGhlICdsaW1p dCcgcGFyYW1ldGVyCisJaXMgdXNlZCB0byBzZXQgbGltaXQgb24gbWF4aW11bSBlbnRyaWVzIHdl IHdpbGwgY3JlYXRlLgorCisJQnV0IGV2ZW4gd2l0aCAnbGltaXQnLCBwb3J0IHNjYW4gY2FuIGZp bGwgdGhlIHNsb3RzIGFuZCBtYWtlIHZhbGlkCisJbmV3IGZsb3cgaGFzIG5vIHNsb3QgYXZhaWxh YmxlIGFuZCBub3QgYmUgdHJhY2VkLgorCisJT25lIG9mIHNvbHV0aW9uIGlzIHRvIHVzZSBuZXRm aWx0ZXIgTUFSSyBmb3IgY2xhc3NpZmljYXRpb24gCisJKGEuay5hLiBjbHNfZncuYykuIE9ubHkg ZXN0YWJsaXNoZWQgc2Vzc2lvbiBpcyBnaXZlbiBhIGZ3IG1hcmssIGFuZAorCXRoZW4sIGlmIHBv cnQgc2NhbiB1c2UgYSBzcG9vZmluZyBzb3VyY2UgYWRkcmVzcywgbm8gZncgbWFyayBnb3R0ZW4u CisKKworQXBwbGljYXRpb24KKy0tLS0tLS0tLS0tCisKKwlZb3Ugc2hvdWxkIHVzZSBIVEIgb3Ig b3RoZXIgY2xhc3NmdWwgcWRpc2MgdG8gZW5jbG9zZSB0aGlzIHFkaXNjLgorCisgKi8KKworCisj ZGVmaW5lIFBFUkZMT1dfSFNJWkUJCTI1MQorI2RlZmluZSBQRVJGTE9XX0xJRkVUSU1FCSgxMCpI WikKKworc3RydWN0IHBlcmZsb3dfZW50cnkKK3sKKwl1MzIJc3JjOworCXUzMglkc3Q7CisJdTE2 CXNwb3J0OworCXUxNglkcG9ydDsKKworCXN0cnVjdAlsaXN0X2hlYWQgaGxpc3Q7CisJc3RydWN0 CWxpc3RfaGVhZCBib3Jyb3c7IAorCXN0cnVjdAl0aW1lcl9saXN0IHRpbWVyOworCXN0cnVjdAlw ZXJmbG93X3NjaGVkX2RhdGEgKnE7CisJdTMyCWppZmZpZXM7CisJdTMyCXVzZWQ7CisJdTMyCXBl bmFsdHk7CisKKwl1OAlwcm90b2NvbDsKK307CisKK3N0cnVjdCBwZXJmbG93X3NjaGVkX2RhdGEK K3sKKwkvKiBwYXJhbWV0ZXJzICovCisJdTMyCXJhdGU7CQkJLyogZ3VhcmFudGVkIHJhdGUgKi8K Kwl1MzIJY2VpbDsJCQkvKiB1cHBlciBib3VuZCAqLworCXUzMglsaW1pdDsJCQkvKiBtYXhpbXVt IGZsb3dzIHdlIHRyYWNlICovCisJdTMyCXFsZW47CQkJLyogbWF4aW11bSBxdWV1ZSBsZW5ndGgg Ki8KKworCS8qIHZhcmlhYmxlcyAqLworCXUzMglncmF0ZTsJCQkvKiBhZ2dyZWdhdGl2ZSByYXRl ICovCisKKwl1MzIJamlmZmllczsKKwl1MzIJdG9rZW47CisJdTMyCWZsb3dfY291bnQ7CQkvKiBo b3cgbWFueSBmbG93cyB3ZSBhcmUgdHJhY2luZyAqLworCXN0cnVjdAlsaXN0X2hlYWQgaHRbUEVS RkxPV19IU0laRV07CS8qIGhhc2ggdGFibGUgKi8KKwlzdHJ1Y3QJbGlzdF9oZWFkIGJvcnJvdzsJ LyogbGlzdHMgb2YgYm9ycm93aW5nIGZsb3cgKi8KK307CisKK3N0cnVjdCBjb21tb25oZHIKK3sK Kwl1MTYJc291cmNlOworCXUxNglkZXN0OworfTsKKworc3RhdGljIF9faW5saW5lX18gdTMyIHBl cmZsb3dfaGFzaChzdHJ1Y3QgcGVyZmxvd19lbnRyeSAqdHVwbGUpCit7CisJcmV0dXJuIChqaGFz aF8zd29yZHModHVwbGUtPnNyYyBeIHR1cGxlLT5wcm90b2NvbCwKKwkJCQl0dXBsZS0+ZHN0LAor CQkJCSh0dXBsZS0+c3BvcnQgPDwgMTYgfCB0dXBsZS0+ZHBvcnQpLAorCQkJCTB4NUU4M0FEMDMp ICUgUEVSRkxPV19IU0laRSk7Cit9CisKK3N0YXRpYyBfX2lubGluZV9fIGludCBwZXJmbG93X2lz X3ZhbGlkKHN0cnVjdCBza19idWZmICpza2IpCit7CisJc3RydWN0IGlwaGRyICppcGggPSBza2It Pm5oLmlwaDsKKworCWlmIChza2ItPnByb3RvY29sICE9IF9fY29uc3RhbnRfaHRvbnMoRVRIX1Bf SVApKQorCQlyZXR1cm4gMDsKKworCWlmIChpcGgtPnByb3RvY29sICE9IElQUFJPVE9fVENQICYm IGlwaC0+cHJvdG9jb2wgIT0gSVBQUk9UT19UQ1AKKwkJCSYmIGlwaC0+cHJvdG9jb2wgIT0gSVBQ Uk9UT19TQ1RQKQorCQlyZXR1cm4gMDsKKworCXJldHVybiAxOworfQorCitzdGF0aWMgX19pbmxp bmVfXyB2b2lkIHBlcmZsb3dfZmxvd190aW1lcih1bnNpZ25lZCBsb25nIGFyZykKK3sKKwlzdHJ1 Y3QgcGVyZmxvd19lbnRyeSAqZSA9IChzdHJ1Y3QgcGVyZmxvd19lbnRyeSAqKSBhcmc7CisKKwll LT5xLT5mbG93X2NvdW50LS07CisJbGlzdF9kZWxfaW5pdCgmZS0+aGxpc3QpOworCWlmICghbGlz dF9lbXB0eSgmZS0+Ym9ycm93KSkKKwkJbGlzdF9kZWxfaW5pdCgmZS0+Ym9ycm93KTsKKwlrZnJl ZShlKTsKK30KKworc3RhdGljIF9faW5saW5lX18gc3RydWN0IHBlcmZsb3dfZW50cnkgKgorcGVy Zmxvd19uZXdfZmxvdyh1MzIgaGFzaCwgc3RydWN0IHBlcmZsb3dfZW50cnkgKnR1cGxlLCBzdHJ1 Y3QgUWRpc2MgKnNjaCkKK3sKKwlzdHJ1Y3QgcGVyZmxvd19zY2hlZF9kYXRhICpxID0gcWRpc2Nf cHJpdihzY2gpOworCXN0cnVjdCBwZXJmbG93X2VudHJ5ICplOworCisJaWYgKHEtPmZsb3dfY291 bnQgPj0gcS0+bGltaXQpCisJCXJldHVybiBOVUxMOworCisJZSA9IGttYWxsb2Moc2l6ZW9mKCpl KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFlKQorCQlyZXR1cm4gTlVMTDsKKworCXEtPmZsb3dfY291 bnQrKzsKKworCW1lbXNldChlLCAwLCBzaXplb2YoKmUpKTsKKworCWUtPnNyYyA9IHR1cGxlLT5z cmM7CisJZS0+ZHN0ID0gdHVwbGUtPmRzdDsKKwllLT5zcG9ydCA9IHR1cGxlLT5zcG9ydDsKKwll LT5kcG9ydCA9IHR1cGxlLT5kcG9ydDsKKwllLT5wcm90b2NvbCA9IHR1cGxlLT5wcm90b2NvbDsK KworCUlOSVRfTElTVF9IRUFEKCZlLT5obGlzdCk7CisJSU5JVF9MSVNUX0hFQUQoJmUtPmJvcnJv dyk7CisJaW5pdF90aW1lcigmZS0+dGltZXIpOworCWUtPnRpbWVyLmZ1bmN0aW9uID0gcGVyZmxv d19mbG93X3RpbWVyOworCWUtPnRpbWVyLmRhdGEgPSAodW5zaWduZWQgbG9uZykgZTsKKwkvKiBz eW5jIGZsb3cncyB0aWNrIHRvIHF1ZXVlJ3MgdGljayAqLworCWUtPmppZmZpZXMgPSBxLT5qaWZm aWVzOworCWUtPnEgPSBxOworCisJbGlzdF9hZGQoJmUtPmhsaXN0LCBxLT5odCArIGhhc2gpOwor CisJcmV0dXJuIGU7Cit9CisKK3N0YXRpYyBfX2lubGluZV9fIHZvaWQKK3BlcmZsb3dfZmlsbF90 dXBsZShzdHJ1Y3QgcGVyZmxvd19lbnRyeSAqdHVwbGUsIHN0cnVjdCBza19idWZmICpza2IpCit7 CisJc3RydWN0IGlwaGRyICppcGggPSBza2ItPm5oLmlwaDsKKwlzdHJ1Y3QgY29tbW9uaGRyICpj aDsKKworCW1lbXNldCh0dXBsZSwgMCwgc2l6ZW9mKHN0cnVjdCBwZXJmbG93X2VudHJ5KSk7Cisj aWYgMQorCS8qIG5vdCBhIHRyYWNlYWJsZSBmbG93LCBkbyBub3RoaW5nICovCisJaWYgKCFwZXJm bG93X2lzX3ZhbGlkKHNrYikpCisJCXJldHVybjsKKyNlbmRpZgorCisJY2ggPSAoc3RydWN0IGNv bW1vbmhkciAqKSgodm9pZCAqKWlwaCArIChpcGgtPmlobCA8PCAyKSk7CisJdHVwbGUtPnNyYyA9 IGlwaC0+c2FkZHI7CisJdHVwbGUtPmRzdCA9IGlwaC0+ZGFkZHI7CisJdHVwbGUtPnNwb3J0ID0g Y2gtPnNvdXJjZTsKKwl0dXBsZS0+ZHBvcnQgPSBjaC0+ZGVzdDsKKwl0dXBsZS0+cHJvdG9jb2wg PSBpcGgtPnByb3RvY29sOworfQorCitzdGF0aWMgc3RydWN0IHBlcmZsb3dfZW50cnkgKgorcGVy Zmxvd19maW5kX2Zsb3codTMyICpoYXNoLCBzdHJ1Y3QgcGVyZmxvd19lbnRyeSAqZmxvdywgc3Ry dWN0IFFkaXNjICpzY2gpCit7CisJc3RydWN0IHBlcmZsb3dfc2NoZWRfZGF0YSAqcSA9IHFkaXNj X3ByaXYoc2NoKTsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpoLCAqaGVhZDsKKwlzdHJ1Y3QgcGVyZmxv d19lbnRyeSAqZTsKKyAgICAgICAKKwkqaGFzaCA9IHBlcmZsb3dfaGFzaChmbG93KTsKKwloZWFk ID0gcS0+aHQgKyAoKmhhc2gpOworCisJbGlzdF9mb3JfZWFjaChoLCBoZWFkKSB7CisJCWUgPSBs aXN0X2VudHJ5KGgsIHN0cnVjdCBwZXJmbG93X2VudHJ5LCBobGlzdCk7CisJCWlmIChlLT5zcmMg PT0gZmxvdy0+c3JjCisJCQkJJiYgZS0+ZHN0ID09IGZsb3ctPmRzdAorCQkJCSYmIGUtPnNwb3J0 ID09IGZsb3ctPnNwb3J0CisJCQkJJiYgZS0+ZHBvcnQgPT0gZmxvdy0+ZHBvcnQKKwkJCQkmJiBl LT5wcm90b2NvbCA9PSBmbG93LT5wcm90b2NvbCkKKwkJCWRlbF90aW1lcigmZS0+dGltZXIpOwor CQkJcmV0dXJuIGU7CisJfQorCXJldHVybiBOVUxMOworfQorCitzdGF0aWMgdm9pZCBwZXJmbG93 X3B1bmlzaChpbnQgcGVuYWx0eSwgc3RydWN0IGxpc3RfaGVhZCAqYm9ycm93KQoreworCXN0cnVj dCBwZXJmbG93X2VudHJ5ICplOworCXN0cnVjdCBsaXN0X2hlYWQgKmg7CisKKwlpZiAoIWxpc3Rf ZW1wdHkoYm9ycm93KSkgeworCQloID0gYm9ycm93LT5uZXh0OworCQlsaXN0X2RlbF9pbml0KGgp OworCQllID0gbGlzdF9lbnRyeShoLCBzdHJ1Y3QgcGVyZmxvd19lbnRyeSwgaGxpc3QpOworCQll LT5wZW5hbHR5ICs9IHBlbmFsdHk7CisJfQorfQorCitzdGF0aWMgX19pbmxpbmVfXyB2b2lkCitw ZXJmbG93X2FkanVzdF91c2VkKHN0cnVjdCBwZXJmbG93X2VudHJ5ICpmbG93LCB1MzIgcmF0ZSwg dTMyIGNlaWwpCit7CisJaW50IGN5Y2xlczsKKworCS8qIHN0aWxsIGluIHRoaXMgdGltZSBzbG90 ICovCisJaWYgKChqaWZmaWVzIC0gZmxvdy0+amlmZmllcykgPD0gSFopIHsKKwkJaWYgKChjZWls IC0gZmxvdy0+dXNlZCkgPiBmbG93LT5wZW5hbHR5KSB7CisJCQlmbG93LT51c2VkICs9IGZsb3ct PnBlbmFsdHk7CisJCQlmbG93LT5wZW5hbHR5ID0gMDsKKwkJfSBlbHNlIHsKKwkJCWZsb3ctPnVz ZWQgPSBjZWlsOworCQkJZmxvdy0+cGVuYWx0eSAtPSBjZWlsIC0gZmxvdy0+dXNlZDsKKwkJfQor CQlyZXR1cm47CisJfQorCisJLyogdGhlIHBhY2tldCBhcnJpdmVzIGFmdGVyIGN5Y2xlcyBzbG90 cyAqLworCWN5Y2xlcyA9IChqaWZmaWVzIC0gZmxvdy0+amlmZmllcykgLyBIWjsKKwlmbG93LT5q aWZmaWVzICs9IGN5Y2xlcyAqIEhaOworCisJaWYgKChjeWNsZXMgKiBjZWlsIC0gZmxvdy0+dXNl ZCkgPiBmbG93LT5wZW5hbHR5KSB7CisJCWZsb3ctPnVzZWQgPSAwOworCQlmbG93LT5wZW5hbHR5 ID0gMDsKKwl9IGVsc2UgeworCQlmbG93LT51c2VkID0gZmxvdy0+cGVuYWx0eSArIGZsb3ctPnVz ZWQgLSBjeWNsZXMgKiBjZWlsOworCQlpZiAoZmxvdy0+dXNlZCA+IGNlaWwpIHsKKwkJCWZsb3ct PnVzZWQgPSBjZWlsOworCQkJZmxvdy0+cGVuYWx0eSAtPSBjZWlsOworCQl9CisJfQorfQorCitz dGF0aWMgaW50IHBlcmZsb3dfZW5xdWV1ZShzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgUWRp c2MgKnNjaCkKK3sKKwlzdHJ1Y3QgcGVyZmxvd19zY2hlZF9kYXRhICpxID0gcWRpc2NfcHJpdihz Y2gpOworCXN0cnVjdCBwZXJmbG93X2VudHJ5IHR1cGxlLCAqZmxvdzsKKwl1MzIgaGFzaDsKKwor CS8qIG5vdCBhIHRyYWNlYWJsZSBmbG93ICovCisJaWYgKCFwZXJmbG93X2lzX3ZhbGlkKHNrYikp CisJCWdvdG8gZHJvcDsKKworCS8qIGlmIG1heCBxbGVuIGlzIHNldCBhbmQgY3VycmVudCBxdWV1 ZSBpcyBmdWxsLCBkcm9wICovCisJaWYgKHEtPnFsZW4gJiYgc2NoLT5xLnFsZW4gPj0gcS0+cWxl bikgeworCQlwcmludGsoS0VSTl9XQVJOSU5HICJxbGVuIG92ZXJsaW1pdCBkcm9wXG4iKTsKKwkJ Z290byBkcm9wOworCX0KKworCXBlcmZsb3dfZmlsbF90dXBsZSgmdHVwbGUsIHNrYik7CisJZmxv dyA9IHBlcmZsb3dfZmluZF9mbG93KCZoYXNoLCAmdHVwbGUsIHNjaCk7CisKKwlpZiAoZmxvdyA9 PSBOVUxMKSB7CisJCWZsb3cgPSBwZXJmbG93X25ld19mbG93KGhhc2gsICZ0dXBsZSwgc2NoKTsK KwkJaWYgKGZsb3cgPT0gTlVMTCkKKwkJCWdvdG8gZHJvcDsKKwl9CisKKwkvKiByZW5ldyB0aW1l ciBmb3IgZmxvdyAqLworCWZsb3ctPnRpbWVyLmV4cGlyZXMgPSBqaWZmaWVzICsgUEVSRkxPV19M SUZFVElNRTsKKwlhZGRfdGltZXIoJmZsb3ctPnRpbWVyKTsKKworCWlmICgoamlmZmllcyAtIHEt PmppZmZpZXMpID4gSFopIHsKKwkJcS0+dG9rZW4gPSBxLT5ncmF0ZTsKKwkJcS0+amlmZmllcyAr PSAoamlmZmllcyAtIHEtPmppZmZpZXMpIC8gSFogKiBIWjsKKwl9CisKKwkvKiByZW5ldyB1c2Vk IGZvciB0aGlzIGZsb3cgKi8KKwlwZXJmbG93X2FkanVzdF91c2VkKGZsb3csIHEtPnJhdGUsIHEt PmNlaWwpOworCisJLyogd2UgYWx3YXlzIHNhdGlzZnkgZmxvdyB1bmRlciByYXRlICovCisJaWYg KGZsb3ctPnVzZWQgPCBxLT5yYXRlKSB7CisJCWZsb3ctPnVzZWQgKz0gc2tiLT5sZW47CisJCWlm IChmbG93LT51c2VkID4gcS0+cmF0ZSkgeworCQkJLyogaWYgd2UgYm9ycm93LCB3ZSBtYXkgcmVj ZWl2ZSBwZW5hbHR5ICovCisJCQlpZiAobGlzdF9lbXB0eSgmZmxvdy0+Ym9ycm93KSkKKwkJCQls aXN0X2FkZF90YWlsKCZmbG93LT5ib3Jyb3csICZxLT5ib3Jyb3cpOworCQl9CisJCWlmIChmbG93 LT51c2VkID4gcS0+Y2VpbCkKKwkJCWZsb3ctPnBlbmFsdHkgKz0gZmxvdy0+dXNlZCAtIHEtPmNl aWw7CisJCWlmIChxLT50b2tlbiA8IHNrYi0+bGVuKSB7CisJCQlxLT50b2tlbiA9IDA7CisJCQlw ZXJmbG93X3B1bmlzaChza2ItPmxlbiAtIHEtPnRva2VuLCAmcS0+Ym9ycm93KTsKKwkJfSBlbHNl IHsKKwkJCXEtPnRva2VuIC09IHNrYi0+bGVuOworCQl9CisJfSBlbHNlIHsKKwkJaWYgKHEtPnRv a2VuIDwgc2tiLT5sZW4gfHwgZmxvdy0+dXNlZCA+PSBxLT5jZWlsKQorCQkJZ290byBkcm9wOwor CisJCWZsb3ctPnVzZWQgKz0gc2tiLT5sZW47CisJCXEtPnRva2VuIC09IHNrYi0+bGVuOworCisJ CWlmIChsaXN0X2VtcHR5KCZmbG93LT5ib3Jyb3cpKQorCQkJbGlzdF9hZGRfdGFpbCgmZmxvdy0+ Ym9ycm93LCAmcS0+Ym9ycm93KTsKKwkJZWxzZQorCQkJbGlzdF9tb3ZlKCZmbG93LT5ib3Jyb3cs ICZxLT5ib3Jyb3cpOworCisJCWlmIChmbG93LT51c2VkID4gcS0+Y2VpbCkKKwkJCWZsb3ctPnBl bmFsdHkgKz0gZmxvdy0+dXNlZCAtIHEtPmNlaWw7CisJfQorCitlbnF1ZXVlOgorCXNjaC0+cXN0 YXRzLmJhY2tsb2cgKz0gc2tiLT5sZW47CisJc2NoLT5ic3RhdHMuYnl0ZXMgKz0gc2tiLT5sZW47 CisJc2NoLT5ic3RhdHMucGFja2V0cysrOworCV9fc2tiX3F1ZXVlX3RhaWwoJnNjaC0+cSwgc2ti KTsKKwlyZXR1cm4gTkVUX1hNSVRfU1VDQ0VTUzsKKworZHJvcDoKKwlzY2gtPnFzdGF0cy5vdmVy bGltaXRzKys7CisJa2ZyZWVfc2tiKHNrYik7CisJc2NoLT5xc3RhdHMuZHJvcHMrKzsKKwlyZXR1 cm4gTkVUX1hNSVRfQ047Cit9CisKK3N0YXRpYyBpbnQgcGVyZmxvd19yZXF1ZXVlKHN0cnVjdCBz a19idWZmICpza2IsIHN0cnVjdCBRZGlzYyAqc2NoKQoreworCV9fc2tiX3F1ZXVlX2hlYWQoJnNj aC0+cSwgc2tiKTsKKwlzY2gtPnFzdGF0cy5iYWNrbG9nICs9IHNrYi0+bGVuOworCXNjaC0+cXN0 YXRzLnJlcXVldWVzKys7CisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBzdHJ1Y3Qgc2tfYnVmZiAq cGVyZmxvd19kZXF1ZXVlKHN0cnVjdCBRZGlzYyAqc2NoKQoreworCXN0cnVjdCBza19idWZmICpz a2I7CisKKwlza2IgPSBfX3NrYl9kZXF1ZXVlKCZzY2gtPnEpOworCWlmIChza2IpIHsKKwkJc2No LT5xc3RhdHMuYmFja2xvZyAtPSBza2ItPmxlbjsKKwl9CisJcmV0dXJuIHNrYjsKK30KKworc3Rh dGljIHVuc2lnbmVkIGludCBwZXJmbG93X2Ryb3Aoc3RydWN0IFFkaXNjICpzY2gpCit7CisJc3Ry dWN0IHNrX2J1ZmYgKnNrYjsKKworCXNrYiA9IF9fc2tiX2RlcXVldWVfdGFpbCgmc2NoLT5xKTsK KwlpZiAoc2tiKSB7CisJCXVuc2lnbmVkIGludCBsZW4gPSBza2ItPmxlbjsKKwkJc2NoLT5xc3Rh dHMuYmFja2xvZyAtPSBsZW47CisJCXNjaC0+cXN0YXRzLmRyb3BzKys7CisJCWtmcmVlX3NrYihz a2IpOworCQlyZXR1cm4gbGVuOworCX0KKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgcGVy Zmxvd19yZXNldChzdHJ1Y3QgUWRpc2MgKnNjaCkKK3sKKwlza2JfcXVldWVfcHVyZ2UoJnNjaC0+ cSk7CisJc2NoLT5xc3RhdHMuYmFja2xvZyA9IDA7Cit9CisKK3N0YXRpYyBpbnQgcGVyZmxvd19j aGFuZ2Uoc3RydWN0IFFkaXNjICpzY2gsIHN0cnVjdCBydGF0dHIgKm9wdCkKK3sKKwlzdHJ1Y3Qg cGVyZmxvd19zY2hlZF9kYXRhICpxID0gcWRpc2NfcHJpdihzY2gpOworCXN0cnVjdCB0Y19wZXJm bG93X3FvcHQgKmN0bDsKKworCS8qIGlmIGxpbWl0IGFuZCBxbGVuIGFyZSBsb3dlcmVkLCBhbmQg d2UgYXJlIGluIGEgb3ZlciBsaW1pdAorCSAqIHN0YXRlLCB3ZSBzdGlsbCBkb24ndCBkcm9wIGZs b3cgb3IgZHJvcCBwYWNrZXQuCisJICogc2NoLT5xIHdpbGwgZGVjcmVhc2UgdG8gYWxsb3dlZCBs ZW5ndGgKKwkgKiBxLT5mbG93X2NvdW50IHdpbGwgZGVjcmVhc2UgYmVjYXVzZSBubyBuZXcgZmxv dyBpcyB0cmFjZWQKKwkgKi8KKwlpZiAob3B0ID09IE5VTEwpIHsKKwkJcmV0dXJuIC1FSU5WQUw7 CisJfSBlbHNlIHsKKwkJY3RsID0gUlRBX0RBVEEob3B0KTsKKwkJaWYgKG9wdC0+cnRhX2xlbiA8 IFJUQV9MRU5HVEgoc2l6ZW9mKCpjdGwpKSkKKwkJCXJldHVybiAtRUlOVkFMOworCisJCXEtPnJh dGUgPSBjdGwtPnJhdGUucmF0ZTsKKwkJcS0+Y2VpbCA9IGN0bC0+Y2VpbC5yYXRlOworCQlxLT5s aW1pdCA9IGN0bC0+bGltaXQ7CisJCXEtPnFsZW4gPSBjdGwtPnFsZW47CisKKwkJaWYgKHEtPmxp bWl0ID09IDApCisJCQlxLT5saW1pdCA9IDEwMjQ7CisJCS8qIGFnZ3JlZ2F0aXZlIHJhdGUgaXMg KHJhdGUgKiAxLjA1ICogbGltaXQpICovCisJCXEtPmdyYXRlID0gKHEtPnJhdGUgKyBxLT5yYXRl LzIwKSAqIHEtPmxpbWl0OworCisJCXEtPmppZmZpZXMgPSBqaWZmaWVzOworCX0KKworCXJldHVy biAwOworfQorCitzdGF0aWMgaW50IHBlcmZsb3dfaW5pdChzdHJ1Y3QgUWRpc2MgKnNjaCwgc3Ry dWN0IHJ0YXR0ciAqb3B0KQoreworCXN0cnVjdCBwZXJmbG93X3NjaGVkX2RhdGEgKnEgPSBxZGlz Y19wcml2KHNjaCk7CisJaW50IGksIHJldDsKKworCXJldCA9IHBlcmZsb3dfY2hhbmdlKHNjaCwg b3B0KTsKKwlpZiAocmV0KQorCQlyZXR1cm4gcmV0OworCisJSU5JVF9MSVNUX0hFQUQoJnEtPmJv cnJvdyk7CisKKwlmb3IgKGkgPSAwOyBpIDwgUEVSRkxPV19IU0laRTsgaSsrKQorCQlJTklUX0xJ U1RfSEVBRChxLT5odCArIGkpOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHBlcmZs b3dfZGVzdHJveShzdHJ1Y3QgUWRpc2MgKnNjaCkKK3sKKwlzdHJ1Y3QgcGVyZmxvd19zY2hlZF9k YXRhICpxID0gcWRpc2NfcHJpdihzY2gpOworCXN0cnVjdCBsaXN0X2hlYWQgKmgsICpuOworCXN0 cnVjdCBwZXJmbG93X2VudHJ5ICplOworCWludCBpOworCisJZm9yIChpID0gMDsgaSA8IFBFUkZM T1dfSFNJWkU7IGkrKykgeworCQlsaXN0X2Zvcl9lYWNoX3NhZmUgKGgsIG4sIHEtPmh0ICsgaSkg eworCQkJZSA9IGxpc3RfZW50cnkoaCwgc3RydWN0IHBlcmZsb3dfZW50cnksIGhsaXN0KTsKKwkJ CWRlbF90aW1lcigmZS0+dGltZXIpOworCQkJaWYgKCFsaXN0X2VtcHR5KCZlLT5ib3Jyb3cpKQor CQkJCWxpc3RfZGVsX2luaXQoJmUtPmJvcnJvdyk7CisJCQlsaXN0X2RlbChoKTsKKwkJCWtmcmVl KGUpOworCQl9CisJfQorfQorCitzdGF0aWMgaW50IHBlcmZsb3dfZHVtcChzdHJ1Y3QgUWRpc2Mg KnNjaCwgc3RydWN0IHNrX2J1ZmYgKnNrYikKK3sKKwlyZXR1cm4gLTE7Cit9CisKK3N0YXRpYyBz dHJ1Y3QgUWRpc2Nfb3BzIHBlcmZsb3dfcWRpc2Nfb3BzID0geworCS5uZXh0CQk9IE5VTEwsCisJ LmNsX29wcwkJPSBOVUxMLAorCS5pZAkJPSAicGVyZmxvdyIsCisJLnByaXZfc2l6ZQk9IHNpemVv ZihzdHJ1Y3QgcGVyZmxvd19zY2hlZF9kYXRhKSwKKwkuZW5xdWV1ZQk9IHBlcmZsb3dfZW5xdWV1 ZSwKKwkuZGVxdWV1ZQk9IHBlcmZsb3dfZGVxdWV1ZSwKKwkucmVxdWV1ZQk9IHBlcmZsb3dfcmVx dWV1ZSwKKwkuZHJvcAkJPSBwZXJmbG93X2Ryb3AsCisJLmluaXQJCT0gcGVyZmxvd19pbml0LAor CS5yZXNldAkJPSBwZXJmbG93X3Jlc2V0LAorCS5kZXN0cm95CT0gcGVyZmxvd19kZXN0cm95LAor CS5jaGFuZ2UJCT0gcGVyZmxvd19jaGFuZ2UsCisJLmR1bXAJCT0gcGVyZmxvd19kdW1wLAorCS5v d25lcgkJPSBUSElTX01PRFVMRSwKK307CisKK3N0YXRpYyBpbnQgX19pbml0IHBlcmZsb3dfbW9k dWxlX2luaXQodm9pZCkKK3sKKwlyZXR1cm4gcmVnaXN0ZXJfcWRpc2MoJnBlcmZsb3dfcWRpc2Nf b3BzKTsKK30KKworc3RhdGljIHZvaWQgX19leGl0IHBlcmZsb3dfbW9kdWxlX2V4aXQodm9pZCkK K3sKKwl1bnJlZ2lzdGVyX3FkaXNjKCZwZXJmbG93X3FkaXNjX29wcyk7Cit9CisKK21vZHVsZV9p bml0KHBlcmZsb3dfbW9kdWxlX2luaXQpOworbW9kdWxlX2V4aXQocGVyZmxvd19tb2R1bGVfZXhp dCk7CisKK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsKK01PRFVMRV9BVVRIT1IoIldhbmcgSmlhbiA8 bGFya0BsaW51eC5uZXQuY24+Iik7Cg== --------_4252A594050B033D6C20_MULTIPART_MIXED_-- From vda@ilport.com.ua Tue Apr 5 08:37:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 08:38:03 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j35FbtTh008889 for ; Tue, 5 Apr 2005 08:37:57 -0700 Received: (qmail 14600 invoked by alias); 5 Apr 2005 15:37:48 -0000 Received: from unknown (195.66.192.167) by 0 (195.66.192.168) with ESMTP; 05 Apr 2005 15:37:48 -0000 From: Denis Vlasenko To: Jesper Juhl , Maciej Soltysiak Subject: Re: [2.6.12-rc1-mm4] swapped memset arguments Date: Tue, 5 Apr 2005 18:37:39 +0300 User-Agent: KMail/1.5.4 Cc: "James P. Ketrenos" , netdev@oss.sgi.com, "David S. Miller" , linux-kernel@vger.kernel.org References: <74334709.20050402233007@dns.toxicfilms.tv> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_DDrUCrdYI+wi3NI" Message-Id: <200504051837.39561.vda@ilport.com.ua> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@ilport.com.ua Precedence: bulk X-list: netdev --Boundary-00=_DDrUCrdYI+wi3NI Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sunday 03 April 2005 01:38, Jesper Juhl wrote: > On Sat, 2 Apr 2005, Maciej Soltysiak wrote: > > > Hi, > > > > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. > > I found one: > > > > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * > > net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); > > > And here's a patch : > > > Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c > found by Maciej Soltysiak. This one will stop these from happening again. (Well, at least on i386)... -- vda --Boundary-00=_DDrUCrdYI+wi3NI Content-Type: text/x-diff; charset="koi8-r"; name="string.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="string.diff" --- linux-2.6.11.src/include/asm-i386/string.h.orig Thu Mar 3 09:31:08 2005 +++ linux-2.6.11.src/include/asm-i386/string.h Tue Apr 5 18:34:28 2005 @@ -316,8 +345,16 @@ __asm__ __volatile__( return s; } -/* we might want to write optimized versions of these later */ -#define __constant_count_memset(s,c,count) __memset_generic((s),(c),(count)) +/* + * we might want to write optimized versions of this later + * for mow, just prevent common mistake of memset(a,c,0) + */ +void BUG_memset_with_zero_length(void); +static inline void * __constant_count_memset(void * s, int c, size_t count) +{ + if(!count) BUG_memset_with_zero_length(); + return __memset_generic(s,c,count); +} /* * memset(x,0,y) is a reasonably common thing to do, so we want to fill @@ -376,6 +413,7 @@ static inline void * __constant_c_and_co { switch (count) { case 0: + BUG_memset_with_zero_length(); return s; case 1: *(unsigned char *)s = pattern; --Boundary-00=_DDrUCrdYI+wi3NI-- From sam@ravnborg.org Tue Apr 5 08:45:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 08:46:04 -0700 (PDT) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Fjq5q009884 for ; Tue, 5 Apr 2005 08:45:52 -0700 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepb.post.tele.dk (Postfix) with ESMTP id A23B45EE0B6; Tue, 5 Apr 2005 17:45:38 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 9648C6AC01D; Tue, 5 Apr 2005 17:45:38 +0200 (CEST) Date: Tue, 5 Apr 2005 17:45:38 +0200 From: Sam Ravnborg To: "Randy.Dunlap" Cc: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers Message-ID: <20050405154538.GA9130@mars.ravnborg.org> References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> <4251A830.5030905@osdl.org> <20050404215554.GA29170@mars.ravnborg.org> <4251C9A5.3020704@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4251C9A5.3020704@osdl.org> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: netdev On Mon, Apr 04, 2005 at 04:11:33PM -0700, Randy.Dunlap wrote: > > - in Networking support, move Network testing and Netpoll > support to the end of the menu (basically put the devel. > tools toward the bottom of the menu) Done > - I would rather not "hide" Amateur Radio, IrDA, and > Bluetooth in the Networking protocols area, but have them > near 802.1x and ATM in the top-level Networking support > menu. How does that sound to you? Done I've made them with separate menu's that you have to enter to enable them. Also pushed out xfrm stuff to net/xfrm/Kconfig Several other small adjustments. In the Networking menu the submenu's are grouped in beginning and in the end now. I thought of creating a Kconfig.netfilter for the common netfilter stuff. But in the end did not do it - felt there was plenty of new small files being created already. Comments welcome. Sam drivers/Kconfig | 4 drivers/net/Kconfig | 5 net/Kconfig | 541 ++----------------------------------------- net/ax25/Kconfig | 5 net/bluetooth/Kconfig | 6 net/bridge/netfilter/Kconfig | 1 net/decnet/Kconfig | 24 + net/ipv4/netfilter/Kconfig | 5 net/ipv6/Kconfig | 20 + net/ipx/Kconfig | 33 ++ net/irda/Kconfig | 5 net/sched/Kconfig | 40 +++ net/sctp/Kconfig | 5 net/xfrm/Kconfig | 14 + v2.6/net/8021q/Kconfig | 21 + v2.6/net/appletalk/Kconfig | 33 ++ v2.6/net/atm/Kconfig | 79 ++++++ v2.6/net/bridge/Kconfig | 32 ++ v2.6/net/core/Kconfig | 67 +++++ v2.6/net/econet/Kconfig | 34 ++ v2.6/net/lapb/Kconfig | 24 + v2.6/net/packet/Kconfig | 26 ++ v2.6/net/unix/Kconfig | 22 + v2.6/net/wanrouter/Kconfig | 31 ++ v2.6/net/x25/Kconfig | 35 ++ 25 files changed, 590 insertions(+), 522 deletions(-) ===== drivers/Kconfig 1.7 vs edited ===== --- 1.7/drivers/Kconfig 2004-12-28 07:01:46 +01:00 +++ edited/drivers/Kconfig 2005-04-04 23:49:50 +02:00 @@ -1,5 +1,7 @@ # drivers/Kconfig +source "net/Kconfig" + menu "Device Drivers" source "drivers/base/Kconfig" @@ -28,7 +30,7 @@ source "drivers/macintosh/Kconfig" -source "net/Kconfig" +source "drivers/net/Kconfig" source "drivers/isdn/Kconfig" ===== drivers/net/Kconfig 1.113 vs edited ===== --- 1.113/drivers/net/Kconfig 2005-03-29 22:48:24 +02:00 +++ edited/drivers/net/Kconfig 2005-04-04 22:06:34 +02:00 @@ -1,8 +1,9 @@ - # # Network device configuration # +menu "Network device support" + config NETDEVICES depends on NET bool "Network device support" @@ -2535,4 +2536,6 @@ ---help--- If you want to log kernel messages over the network, enable this. See for details. + +endmenu ===== net/Kconfig 1.43 vs edited ===== --- 1.43/net/Kconfig 2005-03-23 04:20:04 +01:00 +++ edited/net/Kconfig 2005-04-05 17:03:51 +02:00 @@ -2,7 +2,7 @@ # Network configuration # -menu "Networking support" +menu "Networking" config NET bool "Networking support" @@ -10,7 +10,9 @@ Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even when running on a stand-alone machine that isn't connected to any - other computer. If you are upgrading from an older kernel, you + other computer. + + If you are upgrading from an older kernel, you should consider updating your networking tools too because changes in the kernel and the tools often go hand in hand. The tools are contained in the package net-tools, the location and version number @@ -20,57 +22,9 @@ recommended to read the NET-HOWTO, available from . -menu "Networking options" - depends on NET - -config PACKET - tristate "Packet socket" - ---help--- - The Packet protocol is used by applications which communicate - directly with network devices without an intermediate network - protocol implemented in the kernel, e.g. tcpdump. If you want them - to work, choose Y. - - To compile this driver as a module, choose M here: the module will - be called af_packet. - - If unsure, say Y. - -config PACKET_MMAP - bool "Packet socket: mmapped IO" - depends on PACKET - help - If you say Y here, the Packet protocol driver will use an IO - mechanism that results in faster communication. - - If unsure, say N. - -config UNIX - tristate "Unix domain sockets" - ---help--- - If you say Y here, you will include support for Unix domain sockets; - sockets are the standard Unix mechanism for establishing and - accessing network connections. Many commonly used programs such as - the X Window system and syslog use these sockets even if your - machine is not connected to any network. Unless you are working on - an embedded system or something similar, you therefore definitely - want to say Y here. - - To compile this driver as a module, choose M here: the module will be - called unix. Note that several important services won't work - correctly if you say M here and then neglect to load the module. - - Say Y unless you know what you are doing. - -config NET_KEY - tristate "PF_KEY sockets" - select XFRM - ---help--- - PF_KEYv2 socket family, compatible to KAME ones. - They are required if you are going to use IPsec tools ported - from KAME. +if NET - Say Y unless you know what you are doing. +menu "Networking protocols" config INET bool "TCP/IP networking" @@ -94,31 +48,26 @@ Short answer: say Y. +if INET source "net/ipv4/Kconfig" +source "net/ipv6/Kconfig" +source "net/sctp/Kconfig" +endif -# IPv6 as module will cause a CRASH if you try to unload it -config IPV6 - tristate "The IPv6 protocol" - depends on INET - default m - select CRYPTO if IPV6_PRIVACY - select CRYPTO_MD5 if IPV6_PRIVACY - ---help--- - This is complemental support for the IP version 6. - You will still be able to do traditional IPv4 networking as well. - - For general information about IPv6, see - . - For Linux IPv6 development information, see . - For specific information about IPv6 under Linux, read the HOWTO at - . +source "net/decnet/Kconfig" +source "net/llc/Kconfig" +source "net/ipx/Kconfig" +source "net/appletalk/Kconfig" +source "net/x25/Kconfig" +source "net/lapb/Kconfig" +source "net/econet/Kconfig" - To compile this protocol support as a module, choose M here: the - module will be called ipv6. +endmenu +# end options and protocols -source "net/ipv6/Kconfig" +menu "Network packet filtering" -menuconfig NETFILTER +config NETFILTER bool "Network packet filtering (replaces ipchains)" ---help--- Netfilter is a framework for filtering and mangling network packets @@ -181,14 +130,13 @@ config NETFILTER_DEBUG bool "Network packet filtering debugging" - depends on NETFILTER help You can say Y here if you want to get additional messages useful in debugging the netfilter code. config BRIDGE_NETFILTER bool "Bridged IP/ARP packets filtering" - depends on BRIDGE && NETFILTER && INET + depends on BRIDGE && INET default y ---help--- Enabling this option will let arptables resp. iptables see bridged @@ -204,443 +152,22 @@ source "net/decnet/netfilter/Kconfig" source "net/bridge/netfilter/Kconfig" -endif - -config XFRM - bool - depends on NET - -source "net/xfrm/Kconfig" - -source "net/sctp/Kconfig" - -config ATM - tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - ATM is a high-speed networking technology for Local Area Networks - and Wide Area Networks. It uses a fixed packet size and is - connection oriented, allowing for the negotiation of minimum - bandwidth requirements. - - In order to participate in an ATM network, your Linux box needs an - ATM networking card. If you have that, say Y here and to the driver - of your ATM card below. - - Note that you need a set of user-space programs to actually make use - of ATM. See the file for - further details. - -config ATM_CLIP - tristate "Classical IP over ATM (EXPERIMENTAL)" - depends on ATM && INET - help - Classical IP over ATM for PVCs and SVCs, supporting InARP and - ATMARP. If you want to communication with other IP hosts on your ATM - network, you will typically either say Y here or to "LAN Emulation - (LANE)" below. - -config ATM_CLIP_NO_ICMP - bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" - depends on ATM_CLIP - help - Normally, an "ICMP host unreachable" message is sent if a neighbour - cannot be reached because there is no VC to it in the kernel's - ATMARP table. This may cause problems when ATMARP table entries are - briefly removed during revalidation. If you say Y here, packets to - such neighbours are silently discarded instead. - -config ATM_LANE - tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" - depends on ATM - help - LAN Emulation emulates services of existing LANs across an ATM - network. Besides operating as a normal ATM end station client, Linux - LANE client can also act as an proxy client bridging packets between - ELAN and Ethernet segments. You need LANE if you want to try MPOA. - -config ATM_MPOA - tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" - depends on ATM && INET && ATM_LANE!=n - help - Multi-Protocol Over ATM allows ATM edge devices such as routers, - bridges and ATM attached hosts establish direct ATM VCs across - subnetwork boundaries. These shortcut connections bypass routers - enhancing overall network performance. - -config ATM_BR2684 - tristate "RFC1483/2684 Bridged protocols" - depends on ATM && INET - help - ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) - This device will act like an ethernet from the kernels point of view, - with the traffic being carried by ATM PVCs (currently 1 PVC/device). - This is sometimes used over DSL lines. If in doubt, say N. - -config ATM_BR2684_IPFILTER - bool "Per-VC IP filter kludge" - depends on ATM_BR2684 - help - This is an experimental mechanism for users who need to terminating a - large number of IP-only vcc's. Do not enable this unless you are sure - you know what you are doing. - -config BRIDGE - tristate "802.1d Ethernet Bridging" - ---help--- - If you say Y here, then your Linux box will be able to act as an - Ethernet bridge, which means that the different Ethernet segments it - is connected to will appear as one Ethernet to the participants. - Several such bridges can work together to create even larger - networks of Ethernets using the IEEE 802.1 spanning tree algorithm. - As this is a standard, Linux bridges will cooperate properly with - other third party bridge products. - - In order to use the Ethernet bridge, you'll need the bridge - configuration tools; see - for location. Please read the Bridge mini-HOWTO for more - information. - - If you enable iptables support along with the bridge support then you - turn your bridge into a bridging IP firewall. - iptables will then see the IP packets being bridged, so you need to - take this into account when setting up your firewall rules. - Enabling arptables support when bridging will let arptables see - bridged ARP traffic in the arptables FORWARD chain. - - To compile this code as a module, choose M here: the module - will be called bridge. - - If unsure, say N. - -config VLAN_8021Q - tristate "802.1Q VLAN Support" - ---help--- - Select this and you will be able to create 802.1Q VLAN interfaces - on your ethernet interfaces. 802.1Q VLAN supports almost - everything a regular ethernet interface does, including - firewalling, bridging, and of course IP traffic. You will need - the 'vconfig' tool from the VLAN project in order to effectively - use VLANs. See the VLAN web page for more information: - - - To compile this code as a module, choose M here: the module - will be called 8021q. - - If unsure, say N. - -config DECNET - tristate "DECnet Support" - ---help--- - The DECnet networking protocol was used in many products made by - Digital (now Compaq). It provides reliable stream and sequenced - packet communications over which run a variety of services similar - to those which run over TCP/IP. - - To find some tools to use with the kernel layer support, please - look at Patrick Caulfield's web site: - . - - More detailed documentation is available in - . - - Be sure to say Y to "/proc file system support" and "Sysctl support" - below when using DECnet, since you will need sysctl support to aid - in configuration at run time. - - The DECnet code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module is called decnet. - -source "net/decnet/Kconfig" - -source "net/llc/Kconfig" - -config IPX - tristate "The IPX protocol" - select LLC - ---help--- - This is support for the Novell networking protocol, IPX, commonly - used for local networks of Windows machines. You need it if you - want to access Novell NetWare file or print servers using the Linux - Novell client ncpfs (available from - ) or from - within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, - available from ). In order - to do the former, you'll also have to say Y to "NCP file system - support", below. - - IPX is similar in scope to IP, while SPX, which runs on top of IPX, - is similar to TCP. There is also experimental support for SPX in - Linux (see "SPX networking", below). - - To turn your Linux box into a fully featured NetWare file server and - IPX router, say Y here and fetch either lwared from - or - mars_nwe from . For more - information, read the IPX-HOWTO available from - . - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . - - The IPX driver would enlarge your kernel by about 16 KB. To compile - this driver as a module, choose M here: the module will be called ipx. - Unless you want to integrate your Linux box with a local Novell - network, say N. - -source "net/ipx/Kconfig" - -config ATALK - tristate "Appletalk protocol support" - select LLC - ---help--- - AppleTalk is the protocol that Apple computers can use to communicate - on a network. If your Linux box is connected to such a network and you - wish to connect to it, say Y. You will need to use the netatalk package - so that your Linux box can act as a print and file server for Macs as - well as access AppleTalk printers. Check out - on the WWW for details. - EtherTalk is the name used for AppleTalk over Ethernet and the - cheaper and slower LocalTalk is AppleTalk over a proprietary Apple - network using serial links. EtherTalk and LocalTalk are fully - supported by Linux. - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . The - NET-3-HOWTO, available from - , contains valuable - information as well. - - To compile this driver as a module, choose M here: the module will be - called appletalk. You almost certainly want to compile it as a - module so you can restart your AppleTalk stack without rebooting - your machine. I hear that the GNU boycott of Apple is over, so - even politically correct people are allowed to say Y here. - -source "drivers/net/appletalk/Kconfig" - -config X25 - tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - X.25 is a set of standardized network protocols, similar in scope to - frame relay; the one physical line from your box to the X.25 network - entry point can carry several logical point-to-point connections - (called "virtual circuits") to other computers connected to the X.25 - network. Governments, banks, and other organizations tend to use it - to connect to each other or to form Wide Area Networks (WANs). Many - countries have public X.25 networks. X.25 consists of two - protocols: the higher level Packet Layer Protocol (PLP) (say Y here - if you want that) and the lower level data link layer protocol LAPB - (say Y to "LAPB Data Link Driver" below if you want that). - - You can read more about X.25 at and - . - Information about X.25 for Linux is contained in the files - and - . - - One connects to an X.25 network either with a dedicated network card - using the X.21 protocol (not yet supported by Linux) or one can do - X.25 over a standard telephone line using an ordinary modem (say Y - to "X.25 async driver" below) or over Ethernet using an ordinary - Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link - Driver" and "LAPB over Ethernet driver" below). - - To compile this driver as a module, choose M here: the module - will be called x25. If unsure, say N. - -config LAPB - tristate "LAPB Data Link Driver (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. - the lower) part of the X.25 protocol. It offers a reliable - connection service to exchange data frames with one other host, and - it is used to transport higher level protocols (mostly X.25 Packet - Layer, the higher part of X.25, but others are possible as well). - Usually, LAPB is used with specialized X.21 network cards, but Linux - currently supports LAPB only over Ethernet connections. If you want - to use LAPB connections over Ethernet, say Y here and to "LAPB over - Ethernet driver" below. Read - for technical - details. - - To compile this driver as a module, choose M here: the - module will be called lapb. If unsure, say N. - -config NET_DIVERT - bool "Frame Diverter (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - The Frame Diverter allows you to divert packets from the - network, that are not aimed at the interface receiving it (in - promisc. mode). Typically, a Linux box setup as an Ethernet bridge - with the Frames Diverter on, can do some *really* transparent www - caching using a Squid proxy for example. - - This is very useful when you don't want to change your router's - config (or if you simply don't have access to it). - - The other possible usages of diverting Ethernet Frames are - numberous: - - reroute smtp traffic to another interface - - traffic-shape certain network streams - - transparently proxy smtp connections - - etc... - - For more informations, please refer to: - - - - If unsure, say N. - -config ECONET - tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" - depends on EXPERIMENTAL && INET - ---help--- - Econet is a fairly old and slow networking protocol mainly used by - Acorn computers to access file and print servers. It uses native - Econet network cards. AUN is an implementation of the higher level - parts of Econet that runs over ordinary Ethernet connections, on - top of the UDP packet protocol, which in turn runs on top of the - Internet protocol IP. - - If you say Y here, you can choose with the next two options whether - to send Econet/AUN traffic over a UDP Ethernet connection or over - a native Econet network card. - - To compile this driver as a module, choose M here: the module - will be called econet. - -config ECONET_AUNUDP - bool "AUN over UDP" - depends on ECONET - help - Say Y here if you want to send Econet/AUN traffic over a UDP - connection (UDP is a packet based protocol that runs on top of the - Internet protocol IP) using an ordinary Ethernet network card. - -config ECONET_NATIVE - bool "Native Econet" - depends on ECONET - help - Say Y here if you have a native Econet network card installed in - your computer. - -config WAN_ROUTER - tristate "WAN router" - depends on EXPERIMENTAL - ---help--- - Wide Area Networks (WANs), such as X.25, frame relay and leased - lines, are used to interconnect Local Area Networks (LANs) over vast - distances with data transfer rates significantly higher than those - achievable with commonly used asynchronous modem connections. - Usually, a quite expensive external device called a `WAN router' is - needed to connect to a WAN. - - As an alternative, WAN routing can be built into the Linux kernel. - With relatively inexpensive WAN interface cards available on the - market, a perfectly usable router can be built for less than half - the price of an external router. If you have one of those cards and - wish to use your Linux box as a WAN router, say Y here and also to - the WAN driver for your card, below. You will then need the - wan-tools package which is available from . - Read for more - information. - - To compile WAN routing support as a module, choose M here: the - module will be called wanrouter. - - If unsure, say N. - -menu "QoS and/or fair queueing" - -config NET_SCHED - bool "QoS and/or fair queueing" - ---help--- - When the kernel has several packets to send out over a network - device, it has to decide which ones to send first, which ones to - delay, and which ones to drop. This is the job of the packet - scheduler, and several different algorithms for how to do this - "fairly" have been proposed. - - If you say N here, you will get the standard packet scheduler, which - is a FIFO (first come, first served). If you say Y here, you will be - able to choose from among several alternative algorithms which can - then be attached to different network devices. This is useful for - example if some of your network devices are real time devices that - need a certain minimum data flow rate, or if you need to limit the - maximum data flow rate for traffic which matches specified criteria. - This code is considered to be experimental. - - To administer these schedulers, you'll need the user-level utilities - from the package iproute2+tc at . - That package also contains some documentation; for more, check out - . - - This Quality of Service (QoS) support will enable you to use - Differentiated Services (diffserv) and Resource Reservation Protocol - (RSVP) on your Linux router if you also say Y to "QoS support", - "Packet classifier API" and to some classifiers below. Documentation - and software is at . - - If you say Y here and to "/proc file system" below, you will be able - to read status information about packet schedulers from the file - /proc/net/psched. - - The available schedulers are listed in the following questions; you - can say Y to as many as you like. If unsure, say N now. +endif # if NETFILTER +endmenu # "Network packet filtering" source "net/sched/Kconfig" - -endmenu - -menu "Network testing" - -config NET_PKTGEN - tristate "Packet Generator (USE WITH CAUTION)" - depends on PROC_FS - ---help--- - This module will inject preconfigured packets, at a configurable - rate, out of a given interface. It is used for network interface - stress testing and performance analysis. If you don't understand - what was just said, you don't need it: say N. - - Documentation on how to use the packet generator can be found - at . - - To compile this code as a module, choose M here: the - module will be called pktgen. - -endmenu - -endmenu - -config NETPOLL - def_bool NETCONSOLE - -config NETPOLL_RX - bool "Netpoll support for trapping incoming packets" - default n - depends on NETPOLL - -config NETPOLL_TRAP - bool "Netpoll traffic trapping" - default n - depends on NETPOLL - -config NET_POLL_CONTROLLER - def_bool NETPOLL - +source "net/xfrm/Kconfig" +source "net/packet/Kconfig" +source "net/unix/Kconfig" +source "net/bridge/Kconfig" +source "net/8021q/Kconfig" source "net/ax25/Kconfig" - source "net/irda/Kconfig" - source "net/bluetooth/Kconfig" +source "net/atm/Kconfig" +source "net/wanrouter/Kconfig" +source "net/core/Kconfig" -source "drivers/net/Kconfig" - -endmenu +endif # if NET +endmenu # "Networking" ===== net/ax25/Kconfig 1.5 vs edited ===== --- 1.5/net/ax25/Kconfig 2004-04-06 00:22:50 +02:00 +++ edited/net/ax25/Kconfig 2005-04-05 06:26:26 +02:00 @@ -6,7 +6,9 @@ # Joerg Reuter DL1BKE # 19980129 Moved to net/ax25/Config.in, sourcing device drivers. -menuconfig HAMRADIO +menu "Amateur Radio support" + +config HAMRADIO depends on NET bool "Amateur Radio support" help @@ -107,4 +109,5 @@ source "drivers/net/hamradio/Kconfig" endmenu +endmenu # "Amateur Radio support" ===== net/bluetooth/Kconfig 1.8 vs edited ===== --- 1.8/net/bluetooth/Kconfig 2004-07-16 13:25:28 +02:00 +++ edited/net/bluetooth/Kconfig 2005-04-05 06:28:35 +02:00 @@ -2,7 +2,9 @@ # Bluetooth subsystem configuration # -menuconfig BT +menu "Bluetooth subsystem support" + +config BT depends on NET tristate "Bluetooth subsystem support" help @@ -60,4 +62,6 @@ source "net/bluetooth/hidp/Kconfig" source "drivers/bluetooth/Kconfig" + +endmenu # "Bluetooth subsystem support" ===== net/bridge/netfilter/Kconfig 1.12 vs edited ===== --- 1.12/net/bridge/netfilter/Kconfig 2004-11-24 08:46:46 +01:00 +++ edited/net/bridge/netfilter/Kconfig 2005-04-04 22:06:36 +02:00 @@ -139,6 +139,7 @@ config BRIDGE_EBT_ARPREPLY tristate "ebt: arp reply target support" depends on BRIDGE_NF_EBTABLES + depends on INET help This option adds the arp reply target, which allows automatically sending arp replies to arp requests. ===== net/decnet/Kconfig 1.5 vs edited ===== --- 1.5/net/decnet/Kconfig 2004-11-18 22:42:11 +01:00 +++ edited/net/decnet/Kconfig 2005-04-04 22:06:37 +02:00 @@ -1,6 +1,30 @@ # # DECnet configuration # + +config DECNET + tristate "DECnet Support" + ---help--- + The DECnet networking protocol was used in many products made by + Digital (now Compaq). It provides reliable stream and sequenced + packet communications over which run a variety of services similar + to those which run over TCP/IP. + + To find some tools to use with the kernel layer support, please + look at Patrick Caulfield's web site: + . + + More detailed documentation is available in + . + + Be sure to say Y to "/proc file system support" and "Sysctl support" + below when using DECnet, since you will need sysctl support to aid + in configuration at run time. + + The DECnet code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called decnet. + config DECNET_ROUTER bool "DECnet: router support (EXPERIMENTAL)" depends on DECNET && EXPERIMENTAL ===== net/ipv4/netfilter/Kconfig 1.35 vs edited ===== --- 1.35/net/ipv4/netfilter/Kconfig 2005-01-15 23:31:06 +01:00 +++ edited/net/ipv4/netfilter/Kconfig 2005-04-04 22:06:38 +02:00 @@ -2,9 +2,6 @@ # IP netfilter configuration # -menu "IP: Netfilter Configuration" - depends on INET && NETFILTER - # connection tracking, helpers and protocols config IP_NF_CONNTRACK tristate "Connection tracking (required for masq/NAT)" @@ -691,6 +688,4 @@ help Allows altering the ARP packet payload: source and destination hardware and network addresses. - -endmenu ===== net/ipv6/Kconfig 1.12 vs edited ===== --- 1.12/net/ipv6/Kconfig 2004-10-26 21:32:29 +02:00 +++ edited/net/ipv6/Kconfig 2005-04-04 22:06:38 +02:00 @@ -1,6 +1,26 @@ # # IPv6 configuration # + +# IPv6 as module will cause a CRASH if you try to unload it +config IPV6 + tristate "The IPv6 protocol" + default m + select CRYPTO if IPV6_PRIVACY + select CRYPTO_MD5 if IPV6_PRIVACY + ---help--- + This is complemental support for the IP version 6. + You will still be able to do traditional IPv4 networking as well. + + For general information about IPv6, see + . + For Linux IPv6 development information, see . + For specific information about IPv6 under Linux, read the HOWTO at + . + + To compile this protocol support as a module, choose M here: the + module will be called ipv6. + config IPV6_PRIVACY bool "IPv6: Privacy Extensions (RFC 3041) support" depends on IPV6 ===== net/ipx/Kconfig 1.2 vs edited ===== --- 1.2/net/ipx/Kconfig 2003-04-20 21:56:51 +02:00 +++ edited/net/ipx/Kconfig 2005-04-04 22:06:39 +02:00 @@ -1,6 +1,39 @@ # # IPX configuration # +config IPX + tristate "The IPX protocol" + select LLC + ---help--- + This is support for the Novell networking protocol, IPX, commonly + used for local networks of Windows machines. You need it if you + want to access Novell NetWare file or print servers using the Linux + Novell client ncpfs (available from + ) or from + within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, + available from ). In order + to do the former, you'll also have to say Y to "NCP file system + support", below. + + IPX is similar in scope to IP, while SPX, which runs on top of IPX, + is similar to TCP. There is also experimental support for SPX in + Linux (see "SPX networking", below). + + To turn your Linux box into a fully featured NetWare file server and + IPX router, say Y here and fetch either lwared from + or + mars_nwe from . For more + information, read the IPX-HOWTO available from + . + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . + + The IPX driver would enlarge your kernel by about 16 KB. To compile + this driver as a module, choose M here: the module will be called ipx. + Unless you want to integrate your Linux box with a local Novell + network, say N. + config IPX_INTERN bool "IPX: Full internal IPX network" depends on IPX ===== net/irda/Kconfig 1.7 vs edited ===== --- 1.7/net/irda/Kconfig 2004-07-11 10:54:26 +02:00 +++ edited/net/irda/Kconfig 2005-04-05 06:27:43 +02:00 @@ -1,8 +1,9 @@ # # IrDA protocol configuration # +menu "IrDA (infrared) subsystem support" -menuconfig IRDA +config IRDA depends on NET tristate "IrDA (infrared) subsystem support" select CRC_CCITT @@ -93,4 +94,6 @@ If unsure, say Y (since it makes it easier to find the bugs). source "drivers/net/irda/Kconfig" + +endmenu # "IrDA (infrared) subsystem support" ===== net/sched/Kconfig 1.33 vs edited ===== --- 1.33/net/sched/Kconfig 2005-02-15 21:20:47 +01:00 +++ edited/net/sched/Kconfig 2005-04-05 17:34:38 +02:00 @@ -1,6 +1,45 @@ # # Traffic control configuration. # + +menu "QoS and/or fair queueing" + +config NET_SCHED + bool "QoS and/or fair queueing" + ---help--- + When the kernel has several packets to send out over a network + device, it has to decide which ones to send first, which ones to + delay, and which ones to drop. This is the job of the packet + scheduler, and several different algorithms for how to do this + "fairly" have been proposed. + + If you say N here, you will get the standard packet scheduler, which + is a FIFO (first come, first served). If you say Y here, you will be + able to choose from among several alternative algorithms which can + then be attached to different network devices. This is useful for + example if some of your network devices are real time devices that + need a certain minimum data flow rate, or if you need to limit the + maximum data flow rate for traffic which matches specified criteria. + This code is considered to be experimental. + + To administer these schedulers, you'll need the user-level utilities + from the package iproute2+tc at . + That package also contains some documentation; for more, check out + . + + This Quality of Service (QoS) support will enable you to use + Differentiated Services (diffserv) and Resource Reservation Protocol + (RSVP) on your Linux router if you also say Y to "QoS support", + "Packet classifier API" and to some classifiers below. Documentation + and software is at . + + If you say Y here and to "/proc file system" below, you will be able + to read status information about packet schedulers from the file + /proc/net/psched. + + The available schedulers are listed in the following questions; you + can say Y to as many as you like. If unsure, say N now. + choice prompt "Packet scheduler clock source" depends on NET_SCHED @@ -506,3 +545,4 @@ Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. +endmenu ===== net/sctp/Kconfig 1.13 vs edited ===== --- 1.13/net/sctp/Kconfig 2004-07-30 00:48:33 +02:00 +++ edited/net/sctp/Kconfig 2005-04-04 22:06:40 +02:00 @@ -2,12 +2,8 @@ # SCTP configuration # -menu "SCTP Configuration (EXPERIMENTAL)" - depends on INET && EXPERIMENTAL - config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" - depends on IPV6 || IPV6=n select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 select CRYPTO_SHA1 if SCTP_HMAC_SHA1 @@ -86,4 +82,3 @@ advised to use either HMAC-MD5 or HMAC-SHA1. endchoice -endmenu ===== net/xfrm/Kconfig 1.3 vs edited ===== --- 1.3/net/xfrm/Kconfig 2004-11-02 02:15:57 +01:00 +++ edited/net/xfrm/Kconfig 2005-04-05 17:01:24 +02:00 @@ -1,6 +1,10 @@ # # XFRM configuration # + +config XFRM + bool + config XFRM_USER tristate "IPsec user configuration interface" depends on INET && XFRM @@ -9,4 +13,14 @@ by native Linux tools. If unsure, say Y. + +config NET_KEY + tristate "PF_KEY sockets" + select XFRM + ---help--- + PF_KEYv2 socket family, compatible to KAME ones. + They are required if you are going to use IPsec tools ported + from KAME. + + Say Y unless you know what you are doing. --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/8021q/Kconfig 2005-04-04 22:06:34.000000000 +0200 @@ -0,0 +1,21 @@ +# +# Configuration for 802.1Q VLAN support +# + +config VLAN_8021Q + tristate "802.1Q VLAN Support" + ---help--- + Select this and you will be able to create 802.1Q VLAN interfaces + on your ethernet interfaces. 802.1Q VLAN supports almost + everything a regular ethernet interface does, including + firewalling, bridging, and of course IP traffic. You will need + the 'vconfig' tool from the VLAN project in order to effectively + use VLANs. See the VLAN web page for more information: + + + To compile this code as a module, choose M here: the module + will be called 8021q. + + If unsure, say N. + + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/appletalk/Kconfig 2005-04-04 22:09:15.000000000 +0200 @@ -0,0 +1,33 @@ +# +# Appletalk configuration +# + +config ATALK + tristate "Appletalk protocol support" + depends on NET + select LLC + ---help--- + AppleTalk is the protocol that Apple computers can use to communicate + on a network. If your Linux box is connected to such a network and you + wish to connect to it, say Y. You will need to use the netatalk package + so that your Linux box can act as a print and file server for Macs as + well as access AppleTalk printers. Check out + on the WWW for details. + EtherTalk is the name used for AppleTalk over Ethernet and the + cheaper and slower LocalTalk is AppleTalk over a proprietary Apple + network using serial links. EtherTalk and LocalTalk are fully + supported by Linux. + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . The + NET-3-HOWTO, available from + , contains valuable + information as well. + + To compile this driver as a module, choose M here: the module will be + called appletalk. You almost certainly want to compile it as a + module so you can restart your AppleTalk stack without rebooting + your machine. I hear that the GNU boycott of Apple is over, so + even politically correct people are allowed to say Y here. + +source "drivers/net/appletalk/Kconfig" --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/atm/Kconfig 2005-04-05 17:32:12.000000000 +0200 @@ -0,0 +1,79 @@ +# +# ATM Configarition +# + +menu "Asynchronous Transfer Mode (ATM)" + +config ATM + tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + ATM is a high-speed networking technology for Local Area Networks + and Wide Area Networks. It uses a fixed packet size and is + connection oriented, allowing for the negotiation of minimum + bandwidth requirements. + + In order to participate in an ATM network, your Linux box needs an + ATM networking card. If you have that, say Y here and to the driver + of your ATM card below. + + Note that you need a set of user-space programs to actually make use + of ATM. See the file for + further details. + +config ATM_CLIP + tristate "Classical IP over ATM (EXPERIMENTAL)" + depends on ATM && INET + help + Classical IP over ATM for PVCs and SVCs, supporting InARP and + ATMARP. If you want to communication with other IP hosts on your ATM + network, you will typically either say Y here or to "LAN Emulation + (LANE)" below. + +config ATM_CLIP_NO_ICMP + bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" + depends on ATM_CLIP + help + Normally, an "ICMP host unreachable" message is sent if a neighbour + cannot be reached because there is no VC to it in the kernel's + ATMARP table. This may cause problems when ATMARP table entries are + briefly removed during revalidation. If you say Y here, packets to + such neighbours are silently discarded instead. + +config ATM_LANE + tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" + depends on ATM + help + LAN Emulation emulates services of existing LANs across an ATM + network. Besides operating as a normal ATM end station client, Linux + LANE client can also act as an proxy client bridging packets between + ELAN and Ethernet segments. You need LANE if you want to try MPOA. + +config ATM_MPOA + tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" + depends on ATM && INET && ATM_LANE!=n + help + Multi-Protocol Over ATM allows ATM edge devices such as routers, + bridges and ATM attached hosts establish direct ATM VCs across + subnetwork boundaries. These shortcut connections bypass routers + enhancing overall network performance. + +config ATM_BR2684 + tristate "RFC1483/2684 Bridged protocols" + depends on ATM && INET + help + ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) + This device will act like an ethernet from the kernels point of view, + with the traffic being carried by ATM PVCs (currently 1 PVC/device). + This is sometimes used over DSL lines. If in doubt, say N. + +config ATM_BR2684_IPFILTER + bool "Per-VC IP filter kludge" + depends on ATM_BR2684 + help + This is an experimental mechanism for users who need to terminating a + large number of IP-only vcc's. Do not enable this unless you are sure + you know what you are doing. + +endmenu # "Asynchronous Transfer Mode (ATM)" + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/bridge/Kconfig 2005-04-04 22:06:35.000000000 +0200 @@ -0,0 +1,32 @@ +# +# Configuration for Ethernet bridging +# + +config BRIDGE + tristate "802.1d Ethernet Bridging" + ---help--- + If you say Y here, then your Linux box will be able to act as an + Ethernet bridge, which means that the different Ethernet segments it + is connected to will appear as one Ethernet to the participants. + Several such bridges can work together to create even larger + networks of Ethernets using the IEEE 802.1 spanning tree algorithm. + As this is a standard, Linux bridges will cooperate properly with + other third party bridge products. + + In order to use the Ethernet bridge, you'll need the bridge + configuration tools; see + for location. Please read the Bridge mini-HOWTO for more + information. + + If you enable iptables support along with the bridge support then you + turn your bridge into a bridging IP firewall. + iptables will then see the IP packets being bridged, so you need to + take this into account when setting up your firewall rules. + Enabling arptables support when bridging will let arptables see + bridged ARP traffic in the arptables FORWARD chain. + + To compile this code as a module, choose M here: the module + will be called bridge. + + If unsure, say N. + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/core/Kconfig 2005-04-04 22:06:36.000000000 +0200 @@ -0,0 +1,67 @@ +# +# Core configuration +# + +menu "Network testing" + +config NET_PKTGEN + tristate "Packet Generator (USE WITH CAUTION)" + depends on PROC_FS + depends on INET + ---help--- + This module will inject preconfigured packets, at a configurable + rate, out of a given interface. It is used for network interface + stress testing and performance analysis. If you don't understand + what was just said, you don't need it: say N. + + Documentation on how to use the packet generator can be found + at . + + To compile this code as a module, choose M here: the + module will be called pktgen. + +endmenu + +config NETPOLL + def_bool NETCONSOLE + +config NETPOLL_RX + bool "Netpoll support for trapping incoming packets" + default n + depends on NETPOLL + +config NETPOLL_TRAP + bool "Netpoll traffic trapping" + default n + depends on NETPOLL + +config NET_POLL_CONTROLLER + def_bool NETPOLL + +config NET_DIVERT + bool "Frame Diverter (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + The Frame Diverter allows you to divert packets from the + network, that are not aimed at the interface receiving it (in + promisc. mode). Typically, a Linux box setup as an Ethernet bridge + with the Frames Diverter on, can do some *really* transparent www + caching using a Squid proxy for example. + + This is very useful when you don't want to change your router's + config (or if you simply don't have access to it). + + The other possible usages of diverting Ethernet Frames are + numberous: + - reroute smtp traffic to another interface + - traffic-shape certain network streams + - transparently proxy smtp connections + - etc... + + For more informations, please refer to: + + + + If unsure, say N. + + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/econet/Kconfig 2005-04-04 22:06:37.000000000 +0200 @@ -0,0 +1,34 @@ + +config ECONET + tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" + depends on EXPERIMENTAL && INET + ---help--- + Econet is a fairly old and slow networking protocol mainly used by + Acorn computers to access file and print servers. It uses native + Econet network cards. AUN is an implementation of the higher level + parts of Econet that runs over ordinary Ethernet connections, on + top of the UDP packet protocol, which in turn runs on top of the + Internet protocol IP. + + If you say Y here, you can choose with the next two options whether + to send Econet/AUN traffic over a UDP Ethernet connection or over + a native Econet network card. + + To compile this driver as a module, choose M here: the module + will be called econet. + +config ECONET_AUNUDP + bool "AUN over UDP" + depends on ECONET + help + Say Y here if you want to send Econet/AUN traffic over a UDP + connection (UDP is a packet based protocol that runs on top of the + Internet protocol IP) using an ordinary Ethernet network card. + +config ECONET_NATIVE + bool "Native Econet" + depends on ECONET + help + Say Y here if you have a native Econet network card installed in + your computer. + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/lapb/Kconfig 2005-04-04 22:06:39.000000000 +0200 @@ -0,0 +1,24 @@ +# +# LAPB Configuration +# + +config LAPB + tristate "LAPB Data Link Driver (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. + the lower) part of the X.25 protocol. It offers a reliable + connection service to exchange data frames with one other host, and + it is used to transport higher level protocols (mostly X.25 Packet + Layer, the higher part of X.25, but others are possible as well). + Usually, LAPB is used with specialized X.21 network cards, but Linux + currently supports LAPB only over Ethernet connections. If you want + to use LAPB connections over Ethernet, say Y here and to "LAPB over + Ethernet driver" below. Read + for technical + details. + + To compile this driver as a module, choose M here: the + module will be called lapb. If unsure, say N. + + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/packet/Kconfig 2005-04-04 22:06:39.000000000 +0200 @@ -0,0 +1,26 @@ +# +# Packet configuration +# + +config PACKET + tristate "Packet socket" + ---help--- + The Packet protocol is used by applications which communicate + directly with network devices without an intermediate network + protocol implemented in the kernel, e.g. tcpdump. If you want them + to work, choose Y. + + To compile this driver as a module, choose M here: the module will + be called af_packet. + + If unsure, say Y. + +config PACKET_MMAP + bool "Packet socket: mmapped IO" + depends on PACKET + help + If you say Y here, the Packet protocol driver will use an IO + mechanism that results in faster communication. + + If unsure, say N. + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/unix/Kconfig 2005-04-04 22:06:40.000000000 +0200 @@ -0,0 +1,22 @@ +# +# Configuration for Unix domain sockets +# + +config UNIX + tristate "Unix domain sockets" + ---help--- + If you say Y here, you will include support for Unix domain sockets; + sockets are the standard Unix mechanism for establishing and + accessing network connections. Many commonly used programs such as + the X Window system and syslog use these sockets even if your + machine is not connected to any network. Unless you are working on + an embedded system or something similar, you therefore definitely + want to say Y here. + + To compile this driver as a module, choose M here: the module will be + called unix. Note that several important services won't work + correctly if you say M here and then neglect to load the module. + + Say Y unless you know what you are doing. + + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/wanrouter/Kconfig 2005-04-04 22:06:40.000000000 +0200 @@ -0,0 +1,31 @@ +# +# Configuration for WAN Router +# + +config WAN_ROUTER + tristate "WAN router" + depends on EXPERIMENTAL + ---help--- + Wide Area Networks (WANs), such as X.25, frame relay and leased + lines, are used to interconnect Local Area Networks (LANs) over vast + distances with data transfer rates significantly higher than those + achievable with commonly used asynchronous modem connections. + Usually, a quite expensive external device called a `WAN router' is + needed to connect to a WAN. + + As an alternative, WAN routing can be built into the Linux kernel. + With relatively inexpensive WAN interface cards available on the + market, a perfectly usable router can be built for less than half + the price of an external router. If you have one of those cards and + wish to use your Linux box as a WAN router, say Y here and also to + the WAN driver for your card, below. You will then need the + wan-tools package which is available from . + Read for more + information. + + To compile WAN routing support as a module, choose M here: the + module will be called wanrouter. + + If unsure, say N. + + --- /dev/null 2004-06-15 23:54:05.000000000 +0200 +++ v2.6/net/x25/Kconfig 2005-04-04 22:06:40.000000000 +0200 @@ -0,0 +1,35 @@ +# +# X25 Configuration +# + +config X25 + tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + X.25 is a set of standardized network protocols, similar in scope to + frame relay; the one physical line from your box to the X.25 network + entry point can carry several logical point-to-point connections + (called "virtual circuits") to other computers connected to the X.25 + network. Governments, banks, and other organizations tend to use it + to connect to each other or to form Wide Area Networks (WANs). Many + countries have public X.25 networks. X.25 consists of two + protocols: the higher level Packet Layer Protocol (PLP) (say Y here + if you want that) and the lower level data link layer protocol LAPB + (say Y to "LAPB Data Link Driver" below if you want that). + + You can read more about X.25 at and + . + Information about X.25 for Linux is contained in the files + and + . + + One connects to an X.25 network either with a dedicated network card + using the X.21 protocol (not yet supported by Linux) or one can do + X.25 over a standard telephone line using an ordinary modem (say Y + to "X.25 async driver" below) or over Ethernet using an ordinary + Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link + Driver" and "LAPB over Ethernet driver" below). + + To compile this driver as a module, choose M here: the module + will be called x25. If unsure, say N. + From hadi@cyberus.ca Tue Apr 5 09:11:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 09:11:49 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35GBicw011901 for ; Tue, 5 Apr 2005 09:11:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DIqeQ-0001Sq-9c for netdev@oss.sgi.com; Tue, 05 Apr 2005 10:11:38 -0600 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIqeQ-0007hQ-FQ; Tue, 05 Apr 2005 12:11:38 -0400 Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: Thomas Graf , netdev In-Reply-To: <20050405213023.0256.LARK@linux.net.cn> References: <20050405202039.0250.LARK@linux.net.cn> <1112705689.1088.209.camel@jzny.localdomain> <20050405213023.0256.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112717495.1076.22.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 12:11:35 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi Wang, On Tue, 2005-04-05 at 10:18, Wang Jian wrote: > I am not saying that we must use jenkins. We may use a less expensive > hash function than jenkins, but better than & 0xFF. > Sure; point is as long as it doesnt destroy the common use in place. >Anyway, I have done userspace test for jhash. The following test > is done in a AMD Athlon 800MHz without other CPU load. > No, the test i was asking for is to show distribution of the hash not how long it took (which is also an ok test). i.e if you fed the jenkins hash with 256 buckets - lets pick the number 1024 samples of the data you showed earlier for how fwmark looks like, how well would the result look like. And what if you fed it with something like 1024 incremental fwmark from say 1..1024? cheers, jamal From greg@kroah.com Tue Apr 5 09:48:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 09:49:02 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35GmtNj014432 for ; Tue, 5 Apr 2005 09:48:55 -0700 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j35Gmfi13787; Tue, 5 Apr 2005 09:48:41 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DIrD5-4WY-00; Tue, 05 Apr 2005 09:47:27 -0700 Date: Tue, 5 Apr 2005 09:47:27 -0700 From: Greg KH To: linux-kernel@vger.kernel.org, stable@kernel.org Cc: kaber@trash.net, davem@davemloft.net, netdev@oss.sgi.com Subject: [05/08] [IPSEC]: Do not hold state lock while checking size Message-ID: <20050405164726.GF17299@kroah.com> References: <20050405164539.GA17299@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405164539.GA17299@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gregkh@suse.de Precedence: bulk X-list: netdev -stable review patch. If anyone has any objections, please let us know. ------------------ This patch from Herbert Xu fixes a deadlock with IPsec. When an ICMP frag. required is sent and the ICMP message needs the same SA as the packet that caused it the state will be locked twice. [IPSEC]: Do not hold state lock while checking size. This can elicit ICMP message output and thus result in a deadlock. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman diff -Nru a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c --- a/net/ipv4/xfrm4_output.c 2005-03-20 16:53:05 +01:00 +++ b/net/ipv4/xfrm4_output.c 2005-03-20 16:53:05 +01:00 @@ -103,16 +103,16 @@ goto error_nolock; } - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, skb); - if (err) - goto error; - if (x->props.mode) { err = xfrm4_tunnel_check_size(skb); if (err) - goto error; + goto error_nolock; } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; xfrm4_encap(skb); diff -Nru a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c --- a/net/ipv6/xfrm6_output.c 2005-03-20 16:53:05 +01:00 +++ b/net/ipv6/xfrm6_output.c 2005-03-20 16:53:05 +01:00 @@ -103,16 +103,16 @@ goto error_nolock; } - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, skb); - if (err) - goto error; - if (x->props.mode) { err = xfrm6_tunnel_check_size(skb); if (err) - goto error; + goto error_nolock; } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; xfrm6_encap(skb); From greg@kroah.com Tue Apr 5 09:48:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 09:48:56 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [69.55.234.183]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35GmoCk014422 for ; Tue, 5 Apr 2005 09:48:50 -0700 Received: from [192.168.0.10] (c-24-22-118-199.hsd1.or.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j35GmXi13766; Tue, 5 Apr 2005 09:48:33 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1DIrDb-4Ww-00; Tue, 05 Apr 2005 09:47:59 -0700 Date: Tue, 5 Apr 2005 09:47:59 -0700 From: Greg KH To: linux-kernel@vger.kernel.org, stable@kernel.org Cc: davem@davemloft.net, shemminger@osdl.org, netdev@oss.sgi.com Subject: [07/08] [TCP] Fix BIC congestion avoidance algorithm error Message-ID: <20050405164758.GH17299@kroah.com> References: <20050405164539.GA17299@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405164539.GA17299@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gregkh@suse.de Precedence: bulk X-list: netdev -stable review patch. If anyone has any objections, please let us know. ------------------ Since BIC is the default congestion control algorithm enabled in every 2.6.x kernel out there, fixing errors in it becomes quite critical. A flaw in the loss handling caused it to not perform the binary search regimen of the BIC algorithm properly. The fix below from Stephen Hemminger has been heavily verified. [TCP]: BIC not binary searching correctly While redoing BIC for the split up version, I discovered that the existing 2.6.11 code doesn't really do binary search. It ends up being just a slightly modified version of Reno. See attached graphs to see the effect over simulated 1mbit environment. The problem is that BIC is supposed to reset the cwnd to the last loss value rather than ssthresh when loss is detected. The correct code (from the BIC TCP code for Web100) is in this patch. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman --- 1.92/net/ipv4/tcp_input.c 2005-02-22 10:45:31 -08:00 +++ edited/net/ipv4/tcp_input.c 2005-03-23 10:55:18 -08:00 @@ -1653,7 +1653,10 @@ static void tcp_undo_cwr(struct tcp_sock *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tcp_is_bic(tp)) + tp->snd_cwnd = max(tp->snd_cwnd, tp->bictcp.last_max_cwnd); + else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; From jmorris@redhat.com Tue Apr 5 09:54:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 09:54:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35GslLE015841 for ; Tue, 5 Apr 2005 09:54:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j35Gs7jK002497; Tue, 5 Apr 2005 12:54:07 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j35Gs6O25304; Tue, 5 Apr 2005 12:54:06 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j35Gs5v9012552; Tue, 5 Apr 2005 12:54:06 -0400 Date: Tue, 5 Apr 2005 12:54:05 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Evgeniy Polyakov cc: linux-kernel@vger.kernel.org, , "David S. Miller" , Herbert Xu , , Greg KH , Andrew Morton Subject: Re: Netlink Connector / CBUS In-Reply-To: <1112684596.28858.4.camel@uganda> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1428 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, 5 Apr 2005, Evgeniy Polyakov wrote: > On Tue, 2005-04-05 at 01:05 -0400, James Morris wrote: > > Evgeniy, > > > > Please send networking patches to netdev@oss.sgi.com. > > It was sent there two times. I googled around quite a lot to track the origin of the patches down but didn't do the obvious and look in the netdev archives, sorry. - James -- James Morris From sri@us.ibm.com Tue Apr 5 10:42:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 10:42:45 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35HgXMv018992 for ; Tue, 5 Apr 2005 10:42:40 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j35HgSUk029996 for ; Tue, 5 Apr 2005 13:42:28 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j35HgRkS088134 for ; Tue, 5 Apr 2005 13:42:28 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j35HgRDq009501 for ; Tue, 5 Apr 2005 12:42:27 -0500 Received: from IBM-2RI44RCU0TC.beaverton.ibm.com (IBM-2RI44RCU0TC.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j35HgP33009392; Tue, 5 Apr 2005 12:42:26 -0500 Date: Tue, 5 Apr 2005 10:42:25 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: Sam Ravnborg cc: "Randy.Dunlap" , ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers In-Reply-To: <20050404195051.GA12364@mars.ravnborg.org> Message-ID: References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev On Mon, 4 Apr 2005, Sam Ravnborg wrote: > > Only bit that I am worried about is the statement in SCTP: > depends on IPV6 || IPV6=n > > That looked like a noop to me. It had the sideeffect that SCTP > menu entries where idented an extra level which was not desireable > with currect layout. > No. This is not a noop. This is required to restrict SCTP configured as static when IPV6 is configured as module. Thanks Sridhar From davem@davemloft.net Tue Apr 5 10:48:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 10:48:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Hmdtv019698 for ; Tue, 5 Apr 2005 10:48:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIs8Q-0004Vo-00; Tue, 05 Apr 2005 10:46:42 -0700 Date: Tue, 5 Apr 2005 10:46:41 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, nakam@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events Message-Id: <20050405104641.11bdbbfb.davem@davemloft.net> In-Reply-To: <1112702303.1095.107.camel@jzny.localdomain> References: <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> <1112696301.1089.30.camel@jzny.localdomain> <20050405102238.GC23226@gondor.apana.org.au> <1112702303.1095.107.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On 05 Apr 2005 07:58:23 -0400 jamal wrote: > On Tue, 2005-04-05 at 06:22, Herbert Xu wrote: > > > Signed-off-by: Herbert Xu > > I have a feeling that Dave is not following this thread. Believe it or not I have been :-) From hadi@cyberus.ca Tue Apr 5 10:57:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 10:57:53 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35HvkCd020849 for ; Tue, 5 Apr 2005 10:57:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DIsJ8-00084t-1t for netdev@oss.sgi.com; Tue, 05 Apr 2005 13:57:46 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIsJ3-0006C1-Tl; Tue, 05 Apr 2005 13:57:42 -0400 Subject: Re: [RFC] QoS: new per flow queue From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050405224956.0258.LARK@linux.net.cn> References: <20050405224956.0258.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112723858.1076.46.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 13:57:38 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1431 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 quickly scanned the kernel portion. I dont think this is the best way to achieve this - your qdisc is both a classifier and scheduler. I think this is the major drwback. And if you take out the classifier - whats left in your qdisc cant beat htb or hfsc or cbq in terms of being proven to be accurate. If you could write a meta action instead which is a simple dynamic setter of something like fwmark that would suffice i.e something along the lines of: example: ---- tc filter ip u32 match ip sport 80 0xffff flowid 1:12 \ action dynfwmark continue tc filter fwmark 0x1 .. classid aaaa tc filter fwmark 0x2 .. classid bbbb .. .. tc qdisc htb/hfsc/cbq .... your rate parameters here. --- dynfwmark will maintain your state table which gets deleted when timers expire and will hash based on the current jenkins hash Do you have to queue the packets? if not you could instead have the police action (attached to fwmark) drop the packet once it exceeds certain rate and then use any enqueueing scheme you want. The drawback with above scheme is you will have as many entries for fwmark as you want to have queues - each selecting its own queue. cheers, jamal On Tue, 2005-04-05 at 11:25, Wang Jian wrote: > Hi, > > I write a per flow rate control qdisc. I posted it to LARTC list. Some > discussion about it is here > > http://mailman.ds9a.nl/pipermail/lartc/2005q2/015381.html > > I think I need more feedback and suggestion on it so I repost the patch > here. Please read the thread and get a picture about why and how. > > The kernel patch is agains kernel 2.6.11, the iproute2 patch is against > iproute2-2.6.11-050314. > > The test scenario is like this > > www server <- [ eth0 eth1 ] -> www clients > > The attached t.sh is used to generate test rules. Clients download a > big ISO file from www server, so flows' rate can be estimated by view > progress. > > I have some test on it and it works well. It provides good fairness. > When all slot being used, in most time, the real rate can keep at > specified guaranteed rate. But I know it should receive more test. > > I have some consideration though > > 1. In the test sometimes there a pair of unbalanced stream and don't get > balanced quickly. One stream get 8.4kbps and another get 11.5kbps. How > to find the flow with highest traffic and punish it most? > > 2. The default ceil equals to rate. Should I calculate it as > ceil = rate * 1.05 * limit, or > ceil = rate * 1.05? > > 3. when flow slots are full, optionally reclassify untraceable traffic > into another specified class, instead of dropping it? > > TODO: > > 1. rtnetlink related code should be improved; > 2. dump() and dump_stat(); > > > Regards From hadi@cyberus.ca Tue Apr 5 11:06:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:06:14 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35I64s4021854 for ; Tue, 5 Apr 2005 11:06:05 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DIsR8-0005Xx-R3 for netdev@oss.sgi.com; Tue, 05 Apr 2005 14:06:02 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DIsR4-0007E5-88; Tue, 05 Apr 2005 14:05:58 -0400 Subject: Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: herbert@gondor.apana.org.au, nakam@linux-ipv6.org, kaber@trash.net, netdev In-Reply-To: <20050405104641.11bdbbfb.davem@davemloft.net> References: <20050404121641.GA12103@gondor.apana.org.au> <1112619096.1088.473.camel@jzny.localdomain> <20050404130224.GA12546@gondor.apana.org.au> <1112620614.1088.489.camel@jzny.localdomain> <20050404213149.GA15222@gondor.apana.org.au> <1112653217.1088.2.camel@jzny.localdomain> <20050404152506.15e1404b.davem@davemloft.net> <1112654575.1089.17.camel@jzny.localdomain> <42523FD3.8010400@linux-ipv6.org> <1112696301.1089.30.camel@jzny.localdomain> <20050405102238.GC23226@gondor.apana.org.au> <1112702303.1095.107.camel@jzny.localdomain> <20050405104641.11bdbbfb.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112724355.1076.49.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2005 14:05:55 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1433 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 Tue, 2005-04-05 at 13:46, David S. Miller wrote: > On 05 Apr 2005 07:58:23 -0400 > jamal wrote: > > > On Tue, 2005-04-05 at 06:22, Herbert Xu wrote: > > > > > Signed-off-by: Herbert Xu > > > > I have a feeling that Dave is not following this thread. > > Believe it or not I have been :-) Impressive ;-> After the 10th email it seemed to me only Herbert and myself would still be reading this ;-> Did you see the bit about Elvis? ;-> cheers, jamal From damm@opensource.se Tue Apr 5 11:06:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:06:09 -0700 (PDT) Received: from mail-slave.dataphone.se (ns3.dataphone.se [212.37.0.170]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35I600E021844 for ; Tue, 5 Apr 2005 11:06:01 -0700 Received: from clementine.local (unknown [213.80.72.14]) by mail-slave.dataphone.se (Postfix) with ESMTP id 00E626D7E0; Tue, 5 Apr 2005 20:05:50 +0200 (CEST) From: Magnus Damm To: netdev@oss.sgi.com Cc: Magnus Damm Message-Id: <20050405173419.10402.34298.66044@clementine.local> Subject: [PATCH] arlan: module parameter fixes Date: Tue, 5 Apr 2005 20:05:50 +0200 (CEST) X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: damm@opensource.se Precedence: bulk X-list: netdev Make sure the code compiles with and without ARLAN_ENTRY_EXIT_DEBUGGING. Only provide parameter descriptions when parameters are defined. Remove "arlan_"-prefix to shape up built-in parameter names: arlan.arlan_debug -> arlan.debug arlan.arlan_EEPROM_bad -> arlan.EEPROM_bad arlan.arlan_entry_and_exit_debug -> arlan.entry_and_exit_debug arlan.arlan_entry_debug -> arlan.entry_debug arlan.arlan_exit_debug -> arlan.exit_debug Signed-off-by: Magnus Damm --- linux-2.6.12-rc2/drivers/net/wireless/arlan-main.c 2005-04-05 16:57:26.000000000 +0200 +++ linux-2.6.12-rc2-autoparam/drivers/net/wireless/arlan-main.c 2005-04-05 19:21:54.223472976 +0200 @@ -33,8 +33,6 @@ #ifdef ARLAN_DEBUGGING -static int arlan_entry_debug; -static int arlan_exit_debug; static int testMemory = testMemoryUNKNOWN; static int irq = irqUNKNOWN; static int txScrambled = 1; @@ -43,15 +41,13 @@ module_param(irq, int, 0); module_param(mdebug, int, 0); module_param(testMemory, int, 0); -module_param(arlan_entry_debug, int, 0); -module_param(arlan_exit_debug, int, 0); module_param(txScrambled, int, 0); MODULE_PARM_DESC(irq, "(unused)"); MODULE_PARM_DESC(testMemory, "(unused)"); MODULE_PARM_DESC(mdebug, "Arlan multicast debugging (0-1)"); #endif -module_param(arlan_debug, int, 0); +module_param_named(debug, arlan_debug, int, 0); module_param(spreadingCode, int, 0); module_param(channelNumber, int, 0); module_param(channelSet, int, 0); @@ -63,17 +59,19 @@ module_param(tx_delay_ms, int, 0); module_param(retries, int, 0); module_param(tx_queue_len, int, 0); -module_param(arlan_EEPROM_bad, int, 0); -MODULE_PARM_DESC(arlan_debug, "Arlan debug enable (0-1)"); +module_param_named(EEPROM_bad, arlan_EEPROM_bad, int, 0); +MODULE_PARM_DESC(debug, "Arlan debug enable (0-1)"); MODULE_PARM_DESC(retries, "Arlan maximum packet retransmisions"); #ifdef ARLAN_ENTRY_EXIT_DEBUGGING -MODULE_PARM_DESC(arlan_entry_debug, "Arlan driver function entry debugging"); -MODULE_PARM_DESC(arlan_exit_debug, "Arlan driver function exit debugging"); -MODULE_PARM_DESC(arlan_entry_and_exit_debug, "Arlan driver function entry and exit debugging"); -#else -MODULE_PARM_DESC(arlan_entry_debug, "(ignored)"); -MODULE_PARM_DESC(arlan_exit_debug, "(ignored)"); -MODULE_PARM_DESC(arlan_entry_and_exit_debug, "(ignored)"); +static int arlan_entry_debug; +static int arlan_exit_debug; +static int arlan_entry_and_exit_debug; +module_param_named(entry_debug, arlan_entry_debug, int, 0); +module_param_named(exit_debug, arlan_exit_debug, int, 0); +module_param_named(entry_and_exit_debug, arlan_entry_and_exit_debug, int, 0); +MODULE_PARM_DESC(entry_debug, "Arlan driver function entry debugging"); +MODULE_PARM_DESC(exit_debug, "Arlan driver function exit debugging"); +MODULE_PARM_DESC(entry_and_exit_debug, "Arlan driver function entry and exit debugging"); #endif struct arlan_conf_stru arlan_conf[MAX_ARLANS]; From arnaldo.melo@gmail.com Tue Apr 5 11:11:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:11:45 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IBaPP023333 for ; Tue, 5 Apr 2005 11:11:37 -0700 Received: by wproxy.gmail.com with SMTP id 68so1990064wri for ; Tue, 05 Apr 2005 11:11:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Ey9VsjOYD0KbdkKsYkm1L4ytiRWQd+ual5Ptucih7ZVO8lNlPU042JzYiSmOJU/H6xnqH35Jk8YCn29SQcwjlU2+96EF1Fcwp2P6btWYV3ILUzAn1634064V86tNQ1DjbI2V+Ybd2Y4lt2JHyQFB41POGbYbwsra28WYUDcI/lI= Received: by 10.54.41.70 with SMTP id o70mr1682208wro; Tue, 05 Apr 2005 11:11:30 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Tue, 5 Apr 2005 11:11:30 -0700 (PDT) Message-ID: <39e6f6c705040511115b28b575@mail.gmail.com> Date: Tue, 5 Apr 2005 15:11:30 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Marcel Holtmann Subject: Re: Some sleeping function called from invalid context Cc: Network Development Mailing List In-Reply-To: <39e6f6c705040505186c1c62ed@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1112693744.7960.2.camel@pegasus> <39e6f6c70504050413666ea29d@mail.gmail.com> <39e6f6c705040505186c1c62ed@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On Apr 5, 2005 9:18 AM, Arnaldo Carvalho de Melo wrote: > On Apr 5, 2005 8:13 AM, Arnaldo Carvalho de Melo wrote: > > On Apr 5, 2005 6:35 AM, Marcel Holtmann wrote: > > > Hi, > > > > > > while testing the latest kernel from the Bitkeeper repository, I got > > > some sleeping functions called from invalid context: > > > > > > Freeing unused kernel memory: 180k freed > > > Debug: sleeping function called from invalid context at mm/slab.c:2090 > > > in_atomic():1, irqs_disabled():0 > > > [] __might_sleep+0xa6/0xb0 > > > [] kmem_cache_alloc+0x73/0x80 > > > [] kmem_cache_create+0xfe/0x630 > > > [] proto_register+0x9d/0xc0 > > > [] af_unix_init+0x1c/0x7a [unix] > > > [] sys_init_module+0x1b2/0x290 > > > [] syscall_call+0x7/0xb > > > NET: Registered protocol family 1 > > > > Damn, thanks for reporting, looking at it now. > > Humm, recent changes in slab.[ch]... I'll try booting with a kernel without > proto_register to see if this is some bug introduced by this changeset or > if the problem would appear without it, that is my current guess, as we > were doing a kmem_cache_create at module __init time before, and it > uses SLAB_KERNEL at some point... > > I.e. with regards to per protocol slab cache creating at module init time > we are doing the same thing as before the proto_register changeset, > unless I'm missing some obvious thing... Yes, I was missing something, one should not call kmem_cache_create with a spinlock held, patch will be available shortly, thanks a lot Marcel for reporting this one! - Arnaldo From tytso@thunk.org Tue Apr 5 11:22:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:22:37 -0700 (PDT) Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IMU1P024453 for ; Tue, 5 Apr 2005 11:22:32 -0700 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1DIsgd-0007B6-00; Tue, 05 Apr 2005 14:22:03 -0400 Received: from tytso by thunk.org with local (Exim 4.50) id 1DIsgc-00037Y-W7; Tue, 05 Apr 2005 14:22:03 -0400 Date: Tue, 5 Apr 2005 14:22:02 -0400 From: "Theodore Ts'o" To: Greg KH Cc: linux-kernel@vger.kernel.org, stable@kernel.org, davem@davemloft.net, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [07/08] [TCP] Fix BIC congestion avoidance algorithm error Message-ID: <20050405182202.GA11979@thunk.org> Mail-Followup-To: Theodore Ts'o , Greg KH , linux-kernel@vger.kernel.org, stable@kernel.org, davem@davemloft.net, shemminger@osdl.org, netdev@oss.sgi.com References: <20050405164539.GA17299@kroah.com> <20050405164758.GH17299@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050405164758.GH17299@kroah.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 09:47:59AM -0700, Greg KH wrote: > > -stable review patch. If anyone has any objections, please let us know. > > While redoing BIC for the split up version, I discovered that the > existing 2.6.11 code doesn't really do binary search. It ends up > being just a slightly modified version of Reno. See attached graphs > to see the effect over simulated 1mbit environment. I hate to be a stickler for the rules, but does this really meet this criteria? - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) If the congestion control alogirthm is "Reno-like", what is user-visible impact to users? There are OS's out there with TCP/IP stacks that are still using Reno, aren't there? Knowing the answer to the question, "How does this bug `bother' either users or network administrators?" would probably be really helpful. - Ted From acme@ghostprotocols.net Tue Apr 5 11:25:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:25:44 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IPaJ7025132 for ; Tue, 5 Apr 2005 11:25:37 -0700 Received: from [200.138.131.177] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DIslC-0006tF-00; Tue, 05 Apr 2005 15:26:46 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id CE8191462D; Tue, 5 Apr 2005 15:25:17 -0300 (BRT) Date: Tue, 5 Apr 2005 15:25:17 -0300 To: davem@davemloft.net Cc: marcel@holtmann.org, netdev@oss.sgi.com Subject: [PATCH][NET] Don't call kmem_cache_create with a spinlock held Message-ID: <20050405182517.GR640@conectiva.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi David, Please pull from: bk://kernel.bkbits.net/acme/net-2.6 Best Regards, - Arnaldo --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="proto_register_lock_fix.patch" =================================================================== ChangeSet@1.2245, 2005-04-05 14:52:51-03:00, acme@toy.ghostprotocols.net [NET] Don't call kmem_cache_create with a spinlock held This fixes the warning reported by Marcel Holtmann (Thanks!). Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller sock.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c 2005-04-05 15:22:27 -03:00 +++ b/net/core/sock.c 2005-04-05 15:22:27 -03:00 @@ -1359,8 +1359,6 @@ { int rc = -ENOBUFS; - write_lock(&proto_list_lock); - if (alloc_slab) { prot->slab = kmem_cache_create(prot->name, prot->obj_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL); @@ -1368,14 +1366,15 @@ if (prot->slab == NULL) { printk(KERN_CRIT "%s: Can't create sock SLAB cache!\n", prot->name); - goto out_unlock; + goto out; } } + write_lock(&proto_list_lock); list_add(&prot->node, &proto_list); - rc = 0; -out_unlock: write_unlock(&proto_list_lock); + rc = 0; +out: return rc; } --T7mxYSe680VjQnyC-- From davem@davemloft.net Tue Apr 5 11:28:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:28:14 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IS8Gv025784 for ; Tue, 5 Apr 2005 11:28:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIska-0004jU-00; Tue, 05 Apr 2005 11:26:08 -0700 Date: Tue, 5 Apr 2005 11:26:08 -0700 From: "David S. Miller" To: "Theodore Ts'o" Cc: gregkh@suse.de, linux-kernel@vger.kernel.org, stable@kernel.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [07/08] [TCP] Fix BIC congestion avoidance algorithm error Message-Id: <20050405112608.0b3c07f0.davem@davemloft.net> In-Reply-To: <20050405182202.GA11979@thunk.org> References: <20050405164539.GA17299@kroah.com> <20050405164758.GH17299@kroah.com> <20050405182202.GA11979@thunk.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 5 Apr 2005 14:22:02 -0400 Theodore Ts'o wrote: > If the congestion control alogirthm is "Reno-like", what is > user-visible impact to users? There are OS's out there with TCP/IP > stacks that are still using Reno, aren't there? An incorrect implementation of any congestion control algorithm has ramifications not considered when the congestion control author verified the design of his algorithm. This has a large impact on every user on the internet, not just Linux machines. Perhaps on a microscopic scale "this" part of the BIC algorithm was just behaving Reno-like due to the bug, but what implications does that error have as applied to the other heuristics in BIC? This is what I'm talking about. BIC operates in several modes, one of which is a pseudo binary search mode, and another is a less aggressive slower increase mode. Therefore I think fixes to congestion control algorithms which are enabled by default always should take a high priority in the stable kernels. From shemminger@osdl.org Tue Apr 5 11:33:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:33:05 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IX0aY026572 for ; Tue, 5 Apr 2005 11:33:00 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j35IWgs4017471 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 11:32:42 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j35IWfau001235; Tue, 5 Apr 2005 11:32:41 -0700 Date: Tue, 5 Apr 2005 11:32:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: "Theodore Ts'o" , gregkh@suse.de, linux-kernel@vger.kernel.org, stable@kernel.org, netdev@oss.sgi.com Subject: Re: [07/08] [TCP] Fix BIC congestion avoidance algorithm error Message-ID: <20050405113241.3389c9b8@dxpl.pdx.osdl.net> In-Reply-To: <20050405112608.0b3c07f0.davem@davemloft.net> References: <20050405164539.GA17299@kroah.com> <20050405164758.GH17299@kroah.com> <20050405182202.GA11979@thunk.org> <20050405112608.0b3c07f0.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 5 Apr 2005 11:26:08 -0700 "David S. Miller" wrote: > On Tue, 5 Apr 2005 14:22:02 -0400 > Theodore Ts'o wrote: > > > If the congestion control alogirthm is "Reno-like", what is > > user-visible impact to users? There are OS's out there with TCP/IP > > stacks that are still using Reno, aren't there? > > An incorrect implementation of any congestion control algorithm > has ramifications not considered when the congestion control > author verified the design of his algorithm. > > This has a large impact on every user on the internet, not just > Linux machines. > > Perhaps on a microscopic scale "this" part of the BIC algorithm > was just behaving Reno-like due to the bug, but what implications > does that error have as applied to the other heuristics in BIC? > This is what I'm talking about. BIC operates in several modes, > one of which is a pseudo binary search mode, and another is a > less aggressive slower increase mode. > Therefore I think fixes to congestion control algorithms which > are enabled by default always should take a high priority in > the stable kernels. Also, hopefully distro vendors will pick up 2.6.11.X fixes and update their customers. From rddunlap@osdl.org Tue Apr 5 11:47:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:47:43 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35IldaO027749 for ; Tue, 5 Apr 2005 11:47:39 -0700 Received: from [172.20.1.49] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j35Ikjs4019131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 5 Apr 2005 11:46:45 -0700 Message-ID: <4252DD15.5020605@osdl.org> Date: Tue, 05 Apr 2005 11:46:45 -0700 From: "Randy.Dunlap" Organization: OSDL User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg CC: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> <4251A830.5030905@osdl.org> <20050404215554.GA29170@mars.ravnborg.org> <4251C9A5.3020704@osdl.org> <20050405154538.GA9130@mars.ravnborg.org> In-Reply-To: <20050405154538.GA9130@mars.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Sam Ravnborg wrote: > On Mon, Apr 04, 2005 at 04:11:33PM -0700, Randy.Dunlap wrote: > >>- in Networking support, move Network testing and Netpoll >>support to the end of the menu (basically put the devel. >>tools toward the bottom of the menu) > > Done > > >>- I would rather not "hide" Amateur Radio, IrDA, and >>Bluetooth in the Networking protocols area, but have them >>near 802.1x and ATM in the top-level Networking support >>menu. How does that sound to you? > > Done > > I've made them with separate menu's that you have to enter to enable > them. > Also pushed out xfrm stuff to net/xfrm/Kconfig > Several other small adjustments. > In the Networking menu the submenu's are grouped in beginning and in the > end now. > > I thought of creating a Kconfig.netfilter for the common netfilter > stuff. But in the end did not do it - felt there was plenty of new small > files being created already. It would make sense to isolate the netfilter options, but that can be done later. But you are right about "plenty of new small files." I would move Frame Diverter (NET_DIVERT) from the end of the net/core/Kconfig file to the top of the same file.... and then ship it. :) > Comments welcome. Thanks for doing this. -- ~Randy From christoph@graphe.net Tue Apr 5 11:55:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 11:55:59 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Itshs028771 for ; Tue, 5 Apr 2005 11:55:54 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DItDF-0003Zx-I4 for netdev@oss.sgi.com; Tue, 05 Apr 2005 11:55:46 -0700 Date: Tue, 5 Apr 2005 11:55:45 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@server.graphe.net To: netdev@oss.sgi.com Subject: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev It seems that the atomic_dec_and_test for the child dst in net/core/dst.c is really not needed since dst_destroy cannot be called simultanously for the same dst (frees dst unconditionally via kmem_cache_free). If a dst can only have one child then the dst may only be deleted from its parent dst. The refcnt is also incremented via dst_hold and decremented via dst_release elsewhere (seems that they may race with dst_destroy?) but there is no provisions to do something special if __refcnt would reach zero in dst_release. __refcnt is always expected to be always greater than zero there. However, it is checked without dec_and_test for zero in various other locations (dst_free, dst_run_gc, dn_dst_check_expire). Is the atomic_dec_and_test in dst_destroy just there to join two atomic operations into one without being necessary for the correctness of freeing dsts? Then we really would not need atomic_dec_and_test in dst_destroy() and the following patch would be safe (There are some ideas for optimizations that would not be able to preserve the atomic_dec_and_test). Index: linux-2.6.11/net/core/dst.c =================================================================== --- linux-2.6.11.orig/net/core/dst.c 2005-03-01 23:38:12.000000000 -0800 +++ linux-2.6.11/net/core/dst.c 2005-04-05 11:04:41.000000000 -0700 @@ -198,7 +198,8 @@ again: dst = child; if (dst) { - if (atomic_dec_and_test(&dst->__refcnt)) { + atomic_dec(&dst->__refcnt); + if (!atomic_read(&dst->__refcnt)) { /* We were real parent of this dst, so kill child. */ if (dst->flags&DST_NOHASH) goto again; From ravinandan.arakali@neterion.com Tue Apr 5 12:05:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:05:26 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35J5KZB029809 for ; Tue, 5 Apr 2005 12:05:21 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j35J56OC015917; Tue, 5 Apr 2005 15:05:06 -0400 (EDT) Received: from rarakali ([10.16.16.58]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j35J51DD010995; Tue, 5 Apr 2005 15:05:02 -0400 (EDT) From: "Ravinandan Arakali" To: "'Arthur Kepner'" Cc: , , "'Leonid. Grossman \(E-mail\)'" , "'Raghavendra. Koushik \(E-mail\)'" Subject: RE: High CPU utilization with Bonding driver ? Date: Tue, 5 Apr 2005 12:04:56 -0700 Message-ID: <002a01c53a12$5b876770$3a10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Arthur, The problem does not seem to be due to your patch because the bonding driver built without your patch crashes too on load. However, the pre-existing binary under /lib/modules/`uname -r`/... works fine. Any idea why this may be happening ? Given below is the output of trying to insmod the bonding driver. linux:/usr/src/linux-2.6.5-7.135/drivers/net/bonding # insmod bonding.ko mode=4 miimon=100 Killed linux:/usr/src/linux-2.6.5-7.135/drivers/net/bonding # Message from syslogd@linux at Tue Apr 5 03:28:53 2005 ... linux kernel: Oops: 0002 [1] SMP Message from syslogd@linux at Tue Apr 5 03:28:53 2005 ... linux kernel: CR2: ffffffffa0245000 linux:/usr/src/linux-2.6.5-7.135/drivers/net/bonding # dmesg|tail -25 Unable to handle kernel paging request at ffffffffa0245000 RIP: {sys_init_module+3388} PML4 103027 PGD 105027 PMD f988c067 PTE 0 Oops: 0002 [1] SMP CPU 2 Pid: 6608, comm: insmod Tainted: GF U (2.6.5-7.135-smp SLES9_SP1_BRANCH-20041215213001) RIP: 0010:[] {sys_init_module+3388} RSP: 0018:000001007e17bd88 EFLAGS: 00010207 RAX: ffffffffa0244f00 RBX: ffffff000080b2d8 RCX: ffffffffa0244580 RDX: 0000000000000014 RSI: ffffff000081362b RDI: ffffffffa0243de3 RBP: ffffffffa0242e40 R08: 0000000000000018 R09: ffffffffa0246000 R10: 0000000000000001 R11: 000001003fffeda8 R12: 0000000000000018 R13: 7fffffffffffffff R14: ffffffff803d46c0 R15: 0000000000000002 FS: 0000002a9588f6e0(0000) GS:ffffffff80552d00(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa0245000 CR3: 00000000bff90000 CR4: 00000000000006e0 Process insmod (pid: 6608, threadinfo 000001007e17a000, task 000001007ea17400) Stack: 000001007f136c00 8000000000106025 0000010001003950 000001003d7ec340 00000100bf5debe8 0000000000000246 000001007ea17400 ffffffff8013cb20 000001007e17bdc8 000001007e17bdc8 Call Trace:{autoremove_wake_function+0} {do_munmap+1249} {system_call+124} Code: c7 80 00 01 00 00 00 00 00 00 48 83 e8 80 83 fa 3f 76 eb 65 RIP {sys_init_module+3388} RSP <000001007e17bd88> CR2: ffffffffa0245000 -----Original Message----- From: Arthur Kepner [mailto:akepner@sgi.com] Sent: Monday, April 04, 2005 8:03 PM To: Ravinandan Arakali Cc: netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net; 'Leonid. Grossman (E-mail)'; 'Raghavendra. Koushik (E-mail)' Subject: RE: High CPU utilization with Bonding driver ? On Mon, 4 Apr 2005, Ravinandan Arakali wrote: > Arthur, > On what kernel version should your below mentioned patch be applied ? > We tried on one of the older kernels(2.6.5) and got an Oops while > loading the bonding driver. > ..... Hmmm, interesting. I've used it with 2.6.X for at least two values of X (one of them being 5) so I'm surprised. Can you provide details about the oops? -- Arthut From davem@davemloft.net Tue Apr 5 12:35:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:36:03 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35JZvCH015947 for ; Tue, 5 Apr 2005 12:35:57 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DItos-0005AO-00; Tue, 05 Apr 2005 12:34:38 -0700 Date: Tue, 5 Apr 2005 12:34:38 -0700 From: "David S. Miller" To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-Id: <20050405123438.28f02423.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 5 Apr 2005 11:55:45 -0700 (PDT) Christoph Lameter wrote: > Is the atomic_dec_and_test in dst_destroy just there to join two atomic > operations into one without being necessary for the correctness of freeing > dsts? Otimizing big SGI NUM systems again, are you? :-) atomic_dec() has no memory ordering guarentees, only the atomic routines returning values do the proper SMP memory barriers. So, based upon this alone I don't think your change is valid. I've even documented this fully, see Documentation/atomic_ops.txt From christoph@graphe.net Tue Apr 5 12:47:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:47:25 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35JlGb8017016 for ; Tue, 5 Apr 2005 12:47:20 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DIu0z-0003pE-7C; Tue, 05 Apr 2005 12:47:11 -0700 Date: Tue, 5 Apr 2005 12:47:09 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@server.graphe.net To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050405123438.28f02423.davem@davemloft.net> Message-ID: References: <20050405123438.28f02423.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev On Tue, 5 Apr 2005, David S. Miller wrote: > On Tue, 5 Apr 2005 11:55:45 -0700 (PDT) > Christoph Lameter wrote: > > > Is the atomic_dec_and_test in dst_destroy just there to join two atomic > > operations into one without being necessary for the correctness of freeing > > dsts? > atomic_dec() has no memory ordering guarentees, only the atomic > routines returning values do the proper SMP memory barriers. > So, based upon this alone I don't think your change is valid. Correct that applies in general. But what could go wrong if the atomic_dec is separated from the atomic_read in this specific location? I fail to see what the point of having a single instance of atomic_dec_and_test for __refcnt is. In particular since the upper layers guarantee that dst_destroy is not called multiple times for the same dst entry. From kaber@trash.net Tue Apr 5 12:49:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:49:06 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Jn1vB017493 for ; Tue, 5 Apr 2005 12:49:02 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DIu2Y-0006Ri-5B; Tue, 05 Apr 2005 21:48:46 +0200 Message-ID: <4252EB9D.9070305@trash.net> Date: Tue, 05 Apr 2005 21:48:45 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> In-Reply-To: <20050329152110.38d50653@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Netem has a private queue for delayed packets, and currently, packets > in this queue are not accounted for in the qdisc qlen statistics. > This is a problem if netem is used inside another qdisc doing rate > control that peeks at the qlen. > > This patch changes the statistics to include the packets held but > not ready to send. There is one troublesome spot left, netem_watchdog() decreases q.qlen when the packet couldn't be enqueued. I don't think it is possible to make netem useable as leaf-qdisc, it will always have to touch q.qlen from timer context and classful qdiscs can't deal with this since they all maintain their own q.qlen counters and expect changes only in the +-1 range in enqueue/dequeue/requeue/drop. Best thing IMO would be to refuse to work as anything but root qdisc. Regards Patrick From davem@davemloft.net Tue Apr 5 12:51:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:51:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35JpWGp018320 for ; Tue, 5 Apr 2005 12:51:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIu3y-0005Hf-00; Tue, 05 Apr 2005 12:50:14 -0700 Date: Tue, 5 Apr 2005 12:50:14 -0700 From: "David S. Miller" To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-Id: <20050405125014.1ce46c66.davem@davemloft.net> In-Reply-To: References: <20050405123438.28f02423.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 5 Apr 2005 12:47:09 -0700 (PDT) Christoph Lameter wrote: > Correct that applies in general. But what could go wrong if the atomic_dec > is separated from the atomic_read in this specific location? > > I fail to see what the point of having a single instance of > atomic_dec_and_test for __refcnt is. In particular since the upper layers > guarantee that dst_destroy is not called multiple times for the same dst > entry. If this is true, what performance improvement could you possibly be seeing from this change? I know you are making this change for performance reasons, yet you aren't mentioning any details about this. That information is part of what we need to know to judge this change. I've very hesistant to undo atomic operation memory barriers, after all of the weird problems we had in the neighbour cache. From dmitry_yus@yahoo.com Tue Apr 5 12:55:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:55:11 -0700 (PDT) Received: from smtp111.mail.sc5.yahoo.com (smtp111.mail.sc5.yahoo.com [66.163.170.9]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j35Jt5Mw019014 for ; Tue, 5 Apr 2005 12:55:06 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp111.mail.sc5.yahoo.com with SMTP; 5 Apr 2005 19:55:05 -0000 Subject: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: netdev@oss.sgi.com Cc: "David S. Miller" Content-Type: multipart/mixed; boundary="=-wt3BO+/wnxxAUXk5BZ75" Date: Tue, 05 Apr 2005 12:54:49 -0700 Message-Id: <1112730889.16753.17.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev --=-wt3BO+/wnxxAUXk5BZ75 Content-Type: text/plain Content-Transfer-Encoding: 7bit This patch provides: * new event for unicast connections NETLINK_UESTABLISHED. * netlink alloc_skb() now uses sk_allocation instead of hard-coded GFP_KERNEL * since netlink event described via proto and pid, netlink_getsockbypid() is exported, so netlink user can identify socket. Signed-off-by: Dmitry Yusupov --=-wt3BO+/wnxxAUXk5BZ75 Content-Disposition: attachment; filename=netlink_uestablish_event.patch Content-Type: text/x-patch; name=netlink_uestablish_event.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- linux-2.6.11-um/net/netlink/af_netlink.c 2005-04-05 12:40:33.000000000 -0700 +++ linux-2.6.11.orig/net/netlink/af_netlink.c 2005-03-01 23:38:09.000000000 -0800 @@ -467,14 +467,8 @@ return err; } - if (!nladdr->nl_groups && !nlk->groups) { - struct netlink_notify n = { - .protocol = sk->sk_protocol, - .pid = nladdr->nl_pid, - }; - notifier_call_chain(&netlink_chain, NETLINK_UESTABLISHED, &n); + if (!nladdr->nl_groups && !nlk->groups) return 0; - } netlink_table_grab(); if (nlk->groups && !nladdr->nl_groups) @@ -510,6 +504,7 @@ if (!nlk->pid) err = netlink_autobind(sock); + if (err == 0) { sk->sk_state = NETLINK_CONNECTED; nlk->dst_pid = nladdr->nl_pid; @@ -547,7 +542,7 @@ } } -struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid) +static struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid) { int protocol = ssk->sk_protocol; struct sock *sock; @@ -925,7 +920,7 @@ if (len > sk->sk_sndbuf - 32) goto out; err = -ENOBUFS; - skb = alloc_skb(len, sk->sk_allocation); + skb = alloc_skb(len, GFP_KERNEL); if (skb==NULL) goto out; @@ -1184,7 +1179,7 @@ else size = NLMSG_SPACE(4 + NLMSG_ALIGN(nlh->nlmsg_len)); - skb = alloc_skb(size, in_skb->sk->sk_allocation); + skb = alloc_skb(size, GFP_KERNEL); if (!skb) { struct sock *sk; @@ -1470,5 +1465,4 @@ EXPORT_SYMBOL(netlink_set_nonroot); EXPORT_SYMBOL(netlink_unicast); EXPORT_SYMBOL(netlink_unregister_notifier); -EXPORT_SYMBOL(netlink_getsockbypid); --- linux-2.6.11-um/include/linux/notifier.h 2005-04-05 12:30:10.000000000 -0700 +++ linux-2.6.11.orig/include/linux/notifier.h 2005-03-01 23:37:48.000000000 -0800 @@ -62,15 +62,14 @@ #define SYS_HALT 0x0002 /* Notify of system halt */ #define SYS_POWER_OFF 0x0003 /* Notify of system power off */ -#define NETLINK_UESTABLISHED 0x0001 /* Unicast netlink socket established */ -#define NETLINK_URELEASE 0x0002 /* Unicast netlink socket released */ +#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */ -#define CPU_ONLINE 0x0003 /* CPU (unsigned)v is up */ -#define CPU_UP_PREPARE 0x0004 /* CPU (unsigned)v coming up */ -#define CPU_UP_CANCELED 0x0005 /* CPU (unsigned)v NOT coming up */ -#define CPU_DOWN_PREPARE 0x0006 /* CPU (unsigned)v going down */ -#define CPU_DOWN_FAILED 0x0007 /* CPU (unsigned)v NOT going down */ -#define CPU_DEAD 0x0008 /* CPU (unsigned)v dead */ +#define CPU_ONLINE 0x0002 /* CPU (unsigned)v is up */ +#define CPU_UP_PREPARE 0x0003 /* CPU (unsigned)v coming up */ +#define CPU_UP_CANCELED 0x0004 /* CPU (unsigned)v NOT coming up */ +#define CPU_DOWN_PREPARE 0x0005 /* CPU (unsigned)v going down */ +#define CPU_DOWN_FAILED 0x0006 /* CPU (unsigned)v NOT going down */ +#define CPU_DEAD 0x0007 /* CPU (unsigned)v dead */ #endif /* __KERNEL__ */ #endif /* _LINUX_NOTIFIER_H */ --- linux-2.6.11-um/include/linux/netlink.h 2005-04-05 11:35:15.000000000 -0700 +++ linux-2.6.11.orig/include/linux/netlink.h 2005-03-01 23:38:25.000000000 -0800 @@ -124,7 +124,6 @@ extern void netlink_set_err(struct sock *ssk, __u32 pid, __u32 group, int code); extern int netlink_register_notifier(struct notifier_block *nb); extern int netlink_unregister_notifier(struct notifier_block *nb); -extern struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid); /* finegrained unicast helpers: */ struct sock *netlink_getsockbyfilp(struct file *filp); --=-wt3BO+/wnxxAUXk5BZ75-- From shemminger@osdl.org Tue Apr 5 12:58:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:58:31 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35JwMhD019675 for ; Tue, 5 Apr 2005 12:58:24 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j35JwFs4025930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Apr 2005 12:58:15 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j35JwF0f006745; Tue, 5 Apr 2005 12:58:15 -0700 Date: Tue, 5 Apr 2005 12:58:15 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen Message-ID: <20050405125815.152cdbbc@dxpl.pdx.osdl.net> In-Reply-To: <4252EB9D.9070305@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 05 Apr 2005 21:48:45 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Netem has a private queue for delayed packets, and currently, packets > > in this queue are not accounted for in the qdisc qlen statistics. > > This is a problem if netem is used inside another qdisc doing rate > > control that peeks at the qlen. > > > > This patch changes the statistics to include the packets held but > > not ready to send. > > There is one troublesome spot left, netem_watchdog() decreases q.qlen > when the packet couldn't be enqueued. I don't think it is possible > to make netem useable as leaf-qdisc, it will always have to touch > q.qlen from timer context and classful qdiscs can't deal with this > since they all maintain their own q.qlen counters and expect changes > only in the +-1 range in enqueue/dequeue/requeue/drop. Best thing IMO > would be to refuse to work as anything but root qdisc. But then it won't work as a leaf off of prio to handle a single flow. From christoph@graphe.net Tue Apr 5 12:58:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 12:58:28 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35JwLJV019674 for ; Tue, 5 Apr 2005 12:58:23 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DIuBj-0003sU-72; Tue, 05 Apr 2005 12:58:16 -0700 Date: Tue, 5 Apr 2005 12:58:15 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@server.graphe.net To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050405125014.1ce46c66.davem@davemloft.net> Message-ID: References: <20050405123438.28f02423.davem@davemloft.net> <20050405125014.1ce46c66.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev On Tue, 5 Apr 2005, David S. Miller wrote: > > I fail to see what the point of having a single instance of > > atomic_dec_and_test for __refcnt is. In particular since the upper layers > > guarantee that dst_destroy is not called multiple times for the same dst > > entry. > > If this is true, what performance improvement could you possibly be > seeing from this change? We could make refcnt into an array of pointers that point to node specific memory. This avoids cache line bouncing. However, you cannot atomically dec_and_test an array. This is the only location where a dec_and_test is used on dst->__refcnt. > I know you are making this change for performance reasons, yet you > aren't mentioning any details about this. That information is > part of what we need to know to judge this change. I figured that it is not worth posting the patch if there is a reason for the dec_and_test here. I was sure if my assessment of the role of this atomic_dec_and_test here is correct. > I've very hesistant to undo atomic operation memory barriers, after > all of the weird problems we had in the neighbour cache. We can put an explicit barier in if that is the only reason for the atomic_dec_and_test. From kaber@trash.net Tue Apr 5 13:02:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 13:02:46 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35K2ev1020962 for ; Tue, 5 Apr 2005 13:02:41 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DIuF0-0006tQ-5F; Tue, 05 Apr 2005 22:01:38 +0200 Message-ID: <4252EEA2.5020107@trash.net> Date: Tue, 05 Apr 2005 22:01:38 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel References: <20050214221607.GC18465@gondor.apana.org.au> <424864CE.5060802@trash.net> <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> In-Reply-To: <20050405103918.GA24863@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------020902000605070609010800" X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020902000605070609010800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > On Sun, Apr 03, 2005 at 06:48:17PM +0200, Patrick McHardy wrote: > >>Agreed. There is also a bug in my patch, tmpl->daddr can be 0 in which >>case the daddr passed as an argument to xfrm_state_find() will be used. >>My patch only checked tmpl->daddr, this patch fixes it. It also uses > > > Why not just use daddr? It's always guaranteed to be correct. Good idea, I didn't think of this. This patch is without replacement of xfrm_init_tempsel(), it caused an "unused function" warning and, as I mentioned before, I still need the function. Regards Patrick --------------020902000605070609010800 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/xfrm/xfrm_state.c 1.60 vs edited ===== --- 1.60/net/xfrm/xfrm_state.c 2005-04-01 07:19:54 +02:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-05 21:58:08 +02:00 @@ -357,7 +357,7 @@ x = best; if (!x && !error && !acquire_in_progress) { - x0 = afinfo->state_lookup(&tmpl->id.daddr, tmpl->id.spi, tmpl->id.proto); + x0 = afinfo->state_lookup(daddr, tmpl->id.spi, tmpl->id.proto); if (x0 != NULL) { xfrm_state_put(x0); error = -EEXIST; --------------020902000605070609010800-- From davem@davemloft.net Tue Apr 5 13:14:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 13:14:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35KEJxe022030 for ; Tue, 5 Apr 2005 13:14:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIuPz-0005QN-00; Tue, 05 Apr 2005 13:12:59 -0700 Date: Tue, 5 Apr 2005 13:12:59 -0700 From: "David S. Miller" To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-Id: <20050405131259.4b00b8de.davem@davemloft.net> In-Reply-To: References: <20050405123438.28f02423.davem@davemloft.net> <20050405125014.1ce46c66.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 5 Apr 2005 12:58:15 -0700 (PDT) Christoph Lameter wrote: > On Tue, 5 Apr 2005, David S. Miller wrote: > > > > I fail to see what the point of having a single instance of > > > atomic_dec_and_test for __refcnt is. In particular since the upper layers > > > guarantee that dst_destroy is not called multiple times for the same dst > > > entry. > > > > If this is true, what performance improvement could you possibly be > > seeing from this change? > > We could make refcnt into an array of pointers that point to node specific > memory. This avoids cache line bouncing. However, you cannot atomically > dec_and_test an array. This is the only location where a dec_and_test is > used on dst->__refcnt. The dst object is already too large. You have to show a serious performance improvement to justify bloating it up further. > We can put an explicit barier in if that is the only reason for the > atomic_dec_and_test. Then we lose the optimizations of those memory barriers that platforms do in their atomic_op assembly. Let me check out if your assertions about dst_destroy() usage are correct first, hold on for a bit. From fubar@us.ibm.com Tue Apr 5 13:31:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 13:31:49 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35KVare023615 for ; Tue, 5 Apr 2005 13:31:43 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j35KVVXk032126 for ; Tue, 5 Apr 2005 16:31:31 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j35KVUBG237562 for ; Tue, 5 Apr 2005 16:31:31 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j35KVUqW006790 for ; Tue, 5 Apr 2005 15:31:30 -0500 Received: from death.nxdomain.ibm.com (sig-9-65-52-46.mts.ibm.com [9.65.52.46]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j35KVTVt006758; Tue, 5 Apr 2005 15:31:30 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j35KVRNn027636; Tue, 5 Apr 2005 13:31:28 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j35KVQiR027629; Tue, 5 Apr 2005 13:31:27 -0700 Message-Id: <200504052031.j35KVQiR027629@death.nxdomain.ibm.com> To: "Ravinandan Arakali" cc: "'Arthur Kepner'" , netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net, "'Leonid. Grossman (E-mail)'" , "'Raghavendra. Koushik (E-mail)'" Subject: Re: High CPU utilization with Bonding driver ? In-Reply-To: Message from "Ravinandan Arakali" of "Tue, 05 Apr 2005 12:04:56 PDT." <002a01c53a12$5b876770$3a10100a@pc.s2io.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 05 Apr 2005 13:31:26 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Ravinandan Arakali wrote: >The problem does not seem to be due to your patch because >the bonding driver built without your patch crashes too on load. >However, the pre-existing binary under /lib/modules/`uname -r`/... >works fine. >Any idea why this may be happening ? > >Given below is the output of trying to insmod the bonding driver. > >linux:/usr/src/linux-2.6.5-7.135/drivers/net/bonding # insmod bonding.ko >mode=4 miimon=100 What's this kernel from, and do you have the config file available? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From sam@ravnborg.org Tue Apr 5 14:04:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:04:15 -0700 (PDT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35L4A4t025421 for ; Tue, 5 Apr 2005 14:04:11 -0700 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepc.post.tele.dk (Postfix) with ESMTP id 9E155262836; Tue, 5 Apr 2005 23:04:03 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 2EAAB6AC01D; Tue, 5 Apr 2005 23:04:07 +0200 (CEST) Date: Tue, 5 Apr 2005 23:04:06 +0200 From: Sam Ravnborg To: Sridhar Samudrala Cc: "Randy.Dunlap" , ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: Re: [PATCH] network configs: disconnect network options from drivers Message-ID: <20050405210406.GA10325@mars.ravnborg.org> References: <20050330234709.1868eee5.randy.dunlap@verizon.net> <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 10:42:25AM -0700, Sridhar Samudrala wrote: > On Mon, 4 Apr 2005, Sam Ravnborg wrote: > > > > >Only bit that I am worried about is the statement in SCTP: > > depends on IPV6 || IPV6=n > > > >That looked like a noop to me. It had the sideeffect that SCTP > >menu entries where idented an extra level which was not desireable > >with currect layout. > > > > No. This is not a noop. This is required to restrict SCTP configured as > static when IPV6 is configured as module. I see now - thanks. Sam From sam@ravnborg.org Tue Apr 5 14:11:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:11:43 -0700 (PDT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35LBUw1026379 for ; Tue, 5 Apr 2005 14:11:30 -0700 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepc.post.tele.dk (Postfix) with ESMTP id A46F6262841; Tue, 5 Apr 2005 23:11:16 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id DB0F26AC01D; Tue, 5 Apr 2005 23:11:20 +0200 (CEST) Date: Tue, 5 Apr 2005 23:11:20 +0200 From: Sam Ravnborg To: "Randy.Dunlap" , davem@davemloft.net Cc: ioe-lkml@axxeo.de, matthew@wil.cx, lkml , netdev@oss.sgi.com, hadi@cyberus.ca, cfriesen@nortel.com, tgraf@suug.ch Subject: [PATCH] networking: restructuring of net/ kconfig Message-ID: <20050405211120.GB10325@mars.ravnborg.org> References: <20050331185226.GA8146@mars.ravnborg.org> <424C5745.7020501@osdl.org> <20050331203010.GA8034@mars.ravnborg.org> <4250B4C5.2000200@osdl.org> <20050404195051.GA12364@mars.ravnborg.org> <4251A830.5030905@osdl.org> <20050404215554.GA29170@mars.ravnborg.org> <4251C9A5.3020704@osdl.org> <20050405154538.GA9130@mars.ravnborg.org> <4252DD15.5020605@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4252DD15.5020605@osdl.org> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: netdev Hi Rany et all. I have committed the following patch and it will be present in next -mm. It is present (as the only additional cset) in bk://linux-sam.bkbits.net/kconfig davem - any suggestion for next step. Preferably this goes to Linus via you - or? Sam # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/05 22:59:54+02:00 sam@mars.ravnborg.org # networking: restructure kconfig for net/ # # Based on patch and several rounds of comments from: # "Randy.Dunlap" # # Restructure Networking menu structure creating a separate menu # just before Device Drivers. # Device drivers for ordinary NIC's are still to be found # in the Device Drivers section, but Bluetooth, IrDA and ax25 # are located with their corresponding menu entries. # # The patch does the following: # o Create a new "Networking" menu just before "Device Drivers" # o push all config bits to relevant Kconfig files in net/ hirachy # o create new Kconfig files for some subsystem to further push config # bits out of net/Kconfig # o Make more consistent use of menu's avoiding the menuconfig statement # o Fix all menu indention for net/ # # No intentional functional changes introduced. # # Signed-off-by: Sam Ravnborg # # net/x25/Kconfig # 2005/04/05 22:59:31+02:00 sam@mars.ravnborg.org +35 -0 # # net/x25/Kconfig # 2005/04/05 22:59:31+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/x25/Kconfig # # net/wanrouter/Kconfig # 2005/04/05 22:59:30+02:00 sam@mars.ravnborg.org +31 -0 # # net/wanrouter/Kconfig # 2005/04/05 22:59:30+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/wanrouter/Kconfig # # net/unix/Kconfig # 2005/04/05 22:59:28+02:00 sam@mars.ravnborg.org +22 -0 # # net/unix/Kconfig # 2005/04/05 22:59:28+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/unix/Kconfig # # net/packet/Kconfig # 2005/04/05 22:59:26+02:00 sam@mars.ravnborg.org +26 -0 # # net/packet/Kconfig # 2005/04/05 22:59:26+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/packet/Kconfig # # net/lapb/Kconfig # 2005/04/05 22:59:24+02:00 sam@mars.ravnborg.org +24 -0 # # net/lapb/Kconfig # 2005/04/05 22:59:24+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/lapb/Kconfig # # net/econet/Kconfig # 2005/04/05 22:59:22+02:00 sam@mars.ravnborg.org +34 -0 # # net/econet/Kconfig # 2005/04/05 22:59:22+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/econet/Kconfig # # net/core/Kconfig # 2005/04/05 22:59:21+02:00 sam@mars.ravnborg.org +67 -0 # # net/core/Kconfig # 2005/04/05 22:59:21+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/core/Kconfig # # net/bridge/Kconfig # 2005/04/05 22:59:19+02:00 sam@mars.ravnborg.org +32 -0 # # net/bridge/Kconfig # 2005/04/05 22:59:19+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/bridge/Kconfig # # net/atm/Kconfig # 2005/04/05 22:59:17+02:00 sam@mars.ravnborg.org +79 -0 # # net/atm/Kconfig # 2005/04/05 22:59:17+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/atm/Kconfig # # net/appletalk/Kconfig # 2005/04/05 22:59:16+02:00 sam@mars.ravnborg.org +33 -0 # # net/appletalk/Kconfig # 2005/04/05 22:59:16+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/appletalk/Kconfig # # net/8021q/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +21 -0 # # net/xfrm/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +14 -0 # Move top-level config options from net/Kconfig # # net/sctp/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +6 -3 # Skip menu - no longer relevant # Added config option to fix indention in menuconfig # # net/sched/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +40 -0 # Move top-level config option from net/Kconfig # Wrap it in a menu # # net/irda/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +4 -1 # Use a real menu for IrDA" # # net/ipx/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +33 -0 # Move top-level config option from net/Kconfig # # net/ipv6/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +20 -0 # Move top-level config option from net/Kconfig # # net/ipv4/netfilter/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +0 -5 # Skip menu - no longer relevant # # net/decnet/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +24 -0 # Include high level config option from net/Kconfig # # net/bridge/netfilter/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +1 -0 # BRIDGE depends on INET # # net/bluetooth/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +5 -1 # Use a real menu for "Bluetooth" # # net/ax25/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +4 -1 # Use a real menu for "Amateur Radio Support" # # net/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +34 -507 # Push out all config bits to relevant Kconfig files. # Use if XXX / endif to make all depencies correct. # source a lot of new Kconfig files # # net/8021q/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +0 -0 # BitKeeper file /home/sam/bk/v2.6/net/8021q/Kconfig # # drivers/net/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +4 -1 # Add all net drivers in a new menu "Network device support" # # drivers/Kconfig # 2005/04/05 22:59:14+02:00 sam@mars.ravnborg.org +3 -1 # Move "Networking" menu up before "Device Drivers" # Explicit include net drivers # diff -Nru a/drivers/Kconfig b/drivers/Kconfig --- a/drivers/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/drivers/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,5 +1,7 @@ # drivers/Kconfig +source "net/Kconfig" + menu "Device Drivers" source "drivers/base/Kconfig" @@ -28,7 +30,7 @@ source "drivers/macintosh/Kconfig" -source "net/Kconfig" +source "drivers/net/Kconfig" source "drivers/isdn/Kconfig" diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/drivers/net/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,8 +1,9 @@ - # # Network device configuration # +menu "Network device support" + config NETDEVICES depends on NET bool "Network device support" @@ -2535,4 +2536,6 @@ ---help--- If you want to log kernel messages over the network, enable this. See for details. + +endmenu diff -Nru a/net/8021q/Kconfig b/net/8021q/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/8021q/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,21 @@ +# +# Configuration for 802.1Q VLAN support +# + +config VLAN_8021Q + tristate "802.1Q VLAN Support" + ---help--- + Select this and you will be able to create 802.1Q VLAN interfaces + on your ethernet interfaces. 802.1Q VLAN supports almost + everything a regular ethernet interface does, including + firewalling, bridging, and of course IP traffic. You will need + the 'vconfig' tool from the VLAN project in order to effectively + use VLANs. See the VLAN web page for more information: + + + To compile this code as a module, choose M here: the module + will be called 8021q. + + If unsure, say N. + + diff -Nru a/net/Kconfig b/net/Kconfig --- a/net/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/Kconfig 2005-04-05 23:02:06 +02:00 @@ -2,7 +2,7 @@ # Network configuration # -menu "Networking support" +menu "Networking" config NET bool "Networking support" @@ -10,7 +10,9 @@ Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even when running on a stand-alone machine that isn't connected to any - other computer. If you are upgrading from an older kernel, you + other computer. + + If you are upgrading from an older kernel, you should consider updating your networking tools too because changes in the kernel and the tools often go hand in hand. The tools are contained in the package net-tools, the location and version number @@ -20,57 +22,9 @@ recommended to read the NET-HOWTO, available from . -menu "Networking options" - depends on NET - -config PACKET - tristate "Packet socket" - ---help--- - The Packet protocol is used by applications which communicate - directly with network devices without an intermediate network - protocol implemented in the kernel, e.g. tcpdump. If you want them - to work, choose Y. - - To compile this driver as a module, choose M here: the module will - be called af_packet. - - If unsure, say Y. - -config PACKET_MMAP - bool "Packet socket: mmapped IO" - depends on PACKET - help - If you say Y here, the Packet protocol driver will use an IO - mechanism that results in faster communication. - - If unsure, say N. - -config UNIX - tristate "Unix domain sockets" - ---help--- - If you say Y here, you will include support for Unix domain sockets; - sockets are the standard Unix mechanism for establishing and - accessing network connections. Many commonly used programs such as - the X Window system and syslog use these sockets even if your - machine is not connected to any network. Unless you are working on - an embedded system or something similar, you therefore definitely - want to say Y here. - - To compile this driver as a module, choose M here: the module will be - called unix. Note that several important services won't work - correctly if you say M here and then neglect to load the module. - - Say Y unless you know what you are doing. - -config NET_KEY - tristate "PF_KEY sockets" - select XFRM - ---help--- - PF_KEYv2 socket family, compatible to KAME ones. - They are required if you are going to use IPsec tools ported - from KAME. +if NET - Say Y unless you know what you are doing. +menu "Networking protocols" config INET bool "TCP/IP networking" @@ -94,31 +48,26 @@ Short answer: say Y. +if INET source "net/ipv4/Kconfig" +source "net/ipv6/Kconfig" +source "net/sctp/Kconfig" +endif -# IPv6 as module will cause a CRASH if you try to unload it -config IPV6 - tristate "The IPv6 protocol" - depends on INET - default m - select CRYPTO if IPV6_PRIVACY - select CRYPTO_MD5 if IPV6_PRIVACY - ---help--- - This is complemental support for the IP version 6. - You will still be able to do traditional IPv4 networking as well. - - For general information about IPv6, see - . - For Linux IPv6 development information, see . - For specific information about IPv6 under Linux, read the HOWTO at - . +source "net/decnet/Kconfig" +source "net/llc/Kconfig" +source "net/ipx/Kconfig" +source "net/appletalk/Kconfig" +source "net/x25/Kconfig" +source "net/lapb/Kconfig" +source "net/econet/Kconfig" - To compile this protocol support as a module, choose M here: the - module will be called ipv6. +endmenu +# end options and protocols -source "net/ipv6/Kconfig" +menu "Network packet filtering" -menuconfig NETFILTER +config NETFILTER bool "Network packet filtering (replaces ipchains)" ---help--- Netfilter is a framework for filtering and mangling network packets @@ -181,14 +130,13 @@ config NETFILTER_DEBUG bool "Network packet filtering debugging" - depends on NETFILTER help You can say Y here if you want to get additional messages useful in debugging the netfilter code. config BRIDGE_NETFILTER bool "Bridged IP/ARP packets filtering" - depends on BRIDGE && NETFILTER && INET + depends on BRIDGE && INET default y ---help--- Enabling this option will let arptables resp. iptables see bridged @@ -204,443 +152,22 @@ source "net/decnet/netfilter/Kconfig" source "net/bridge/netfilter/Kconfig" -endif - -config XFRM - bool - depends on NET - -source "net/xfrm/Kconfig" - -source "net/sctp/Kconfig" - -config ATM - tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - ATM is a high-speed networking technology for Local Area Networks - and Wide Area Networks. It uses a fixed packet size and is - connection oriented, allowing for the negotiation of minimum - bandwidth requirements. - - In order to participate in an ATM network, your Linux box needs an - ATM networking card. If you have that, say Y here and to the driver - of your ATM card below. - - Note that you need a set of user-space programs to actually make use - of ATM. See the file for - further details. - -config ATM_CLIP - tristate "Classical IP over ATM (EXPERIMENTAL)" - depends on ATM && INET - help - Classical IP over ATM for PVCs and SVCs, supporting InARP and - ATMARP. If you want to communication with other IP hosts on your ATM - network, you will typically either say Y here or to "LAN Emulation - (LANE)" below. - -config ATM_CLIP_NO_ICMP - bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" - depends on ATM_CLIP - help - Normally, an "ICMP host unreachable" message is sent if a neighbour - cannot be reached because there is no VC to it in the kernel's - ATMARP table. This may cause problems when ATMARP table entries are - briefly removed during revalidation. If you say Y here, packets to - such neighbours are silently discarded instead. - -config ATM_LANE - tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" - depends on ATM - help - LAN Emulation emulates services of existing LANs across an ATM - network. Besides operating as a normal ATM end station client, Linux - LANE client can also act as an proxy client bridging packets between - ELAN and Ethernet segments. You need LANE if you want to try MPOA. - -config ATM_MPOA - tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" - depends on ATM && INET && ATM_LANE!=n - help - Multi-Protocol Over ATM allows ATM edge devices such as routers, - bridges and ATM attached hosts establish direct ATM VCs across - subnetwork boundaries. These shortcut connections bypass routers - enhancing overall network performance. - -config ATM_BR2684 - tristate "RFC1483/2684 Bridged protocols" - depends on ATM && INET - help - ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) - This device will act like an ethernet from the kernels point of view, - with the traffic being carried by ATM PVCs (currently 1 PVC/device). - This is sometimes used over DSL lines. If in doubt, say N. - -config ATM_BR2684_IPFILTER - bool "Per-VC IP filter kludge" - depends on ATM_BR2684 - help - This is an experimental mechanism for users who need to terminating a - large number of IP-only vcc's. Do not enable this unless you are sure - you know what you are doing. - -config BRIDGE - tristate "802.1d Ethernet Bridging" - ---help--- - If you say Y here, then your Linux box will be able to act as an - Ethernet bridge, which means that the different Ethernet segments it - is connected to will appear as one Ethernet to the participants. - Several such bridges can work together to create even larger - networks of Ethernets using the IEEE 802.1 spanning tree algorithm. - As this is a standard, Linux bridges will cooperate properly with - other third party bridge products. - - In order to use the Ethernet bridge, you'll need the bridge - configuration tools; see - for location. Please read the Bridge mini-HOWTO for more - information. - - If you enable iptables support along with the bridge support then you - turn your bridge into a bridging IP firewall. - iptables will then see the IP packets being bridged, so you need to - take this into account when setting up your firewall rules. - Enabling arptables support when bridging will let arptables see - bridged ARP traffic in the arptables FORWARD chain. - - To compile this code as a module, choose M here: the module - will be called bridge. - - If unsure, say N. - -config VLAN_8021Q - tristate "802.1Q VLAN Support" - ---help--- - Select this and you will be able to create 802.1Q VLAN interfaces - on your ethernet interfaces. 802.1Q VLAN supports almost - everything a regular ethernet interface does, including - firewalling, bridging, and of course IP traffic. You will need - the 'vconfig' tool from the VLAN project in order to effectively - use VLANs. See the VLAN web page for more information: - - - To compile this code as a module, choose M here: the module - will be called 8021q. - - If unsure, say N. - -config DECNET - tristate "DECnet Support" - ---help--- - The DECnet networking protocol was used in many products made by - Digital (now Compaq). It provides reliable stream and sequenced - packet communications over which run a variety of services similar - to those which run over TCP/IP. - - To find some tools to use with the kernel layer support, please - look at Patrick Caulfield's web site: - . - - More detailed documentation is available in - . - - Be sure to say Y to "/proc file system support" and "Sysctl support" - below when using DECnet, since you will need sysctl support to aid - in configuration at run time. - - The DECnet code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module is called decnet. - -source "net/decnet/Kconfig" - -source "net/llc/Kconfig" - -config IPX - tristate "The IPX protocol" - select LLC - ---help--- - This is support for the Novell networking protocol, IPX, commonly - used for local networks of Windows machines. You need it if you - want to access Novell NetWare file or print servers using the Linux - Novell client ncpfs (available from - ) or from - within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, - available from ). In order - to do the former, you'll also have to say Y to "NCP file system - support", below. - - IPX is similar in scope to IP, while SPX, which runs on top of IPX, - is similar to TCP. There is also experimental support for SPX in - Linux (see "SPX networking", below). - - To turn your Linux box into a fully featured NetWare file server and - IPX router, say Y here and fetch either lwared from - or - mars_nwe from . For more - information, read the IPX-HOWTO available from - . - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . - - The IPX driver would enlarge your kernel by about 16 KB. To compile - this driver as a module, choose M here: the module will be called ipx. - Unless you want to integrate your Linux box with a local Novell - network, say N. - -source "net/ipx/Kconfig" - -config ATALK - tristate "Appletalk protocol support" - select LLC - ---help--- - AppleTalk is the protocol that Apple computers can use to communicate - on a network. If your Linux box is connected to such a network and you - wish to connect to it, say Y. You will need to use the netatalk package - so that your Linux box can act as a print and file server for Macs as - well as access AppleTalk printers. Check out - on the WWW for details. - EtherTalk is the name used for AppleTalk over Ethernet and the - cheaper and slower LocalTalk is AppleTalk over a proprietary Apple - network using serial links. EtherTalk and LocalTalk are fully - supported by Linux. - - General information about how to connect Linux, Windows machines and - Macs is on the WWW at . The - NET-3-HOWTO, available from - , contains valuable - information as well. - - To compile this driver as a module, choose M here: the module will be - called appletalk. You almost certainly want to compile it as a - module so you can restart your AppleTalk stack without rebooting - your machine. I hear that the GNU boycott of Apple is over, so - even politically correct people are allowed to say Y here. - -source "drivers/net/appletalk/Kconfig" - -config X25 - tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - X.25 is a set of standardized network protocols, similar in scope to - frame relay; the one physical line from your box to the X.25 network - entry point can carry several logical point-to-point connections - (called "virtual circuits") to other computers connected to the X.25 - network. Governments, banks, and other organizations tend to use it - to connect to each other or to form Wide Area Networks (WANs). Many - countries have public X.25 networks. X.25 consists of two - protocols: the higher level Packet Layer Protocol (PLP) (say Y here - if you want that) and the lower level data link layer protocol LAPB - (say Y to "LAPB Data Link Driver" below if you want that). - - You can read more about X.25 at and - . - Information about X.25 for Linux is contained in the files - and - . - - One connects to an X.25 network either with a dedicated network card - using the X.21 protocol (not yet supported by Linux) or one can do - X.25 over a standard telephone line using an ordinary modem (say Y - to "X.25 async driver" below) or over Ethernet using an ordinary - Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link - Driver" and "LAPB over Ethernet driver" below). - - To compile this driver as a module, choose M here: the module - will be called x25. If unsure, say N. - -config LAPB - tristate "LAPB Data Link Driver (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. - the lower) part of the X.25 protocol. It offers a reliable - connection service to exchange data frames with one other host, and - it is used to transport higher level protocols (mostly X.25 Packet - Layer, the higher part of X.25, but others are possible as well). - Usually, LAPB is used with specialized X.21 network cards, but Linux - currently supports LAPB only over Ethernet connections. If you want - to use LAPB connections over Ethernet, say Y here and to "LAPB over - Ethernet driver" below. Read - for technical - details. - - To compile this driver as a module, choose M here: the - module will be called lapb. If unsure, say N. - -config NET_DIVERT - bool "Frame Diverter (EXPERIMENTAL)" - depends on EXPERIMENTAL - ---help--- - The Frame Diverter allows you to divert packets from the - network, that are not aimed at the interface receiving it (in - promisc. mode). Typically, a Linux box setup as an Ethernet bridge - with the Frames Diverter on, can do some *really* transparent www - caching using a Squid proxy for example. - - This is very useful when you don't want to change your router's - config (or if you simply don't have access to it). - - The other possible usages of diverting Ethernet Frames are - numberous: - - reroute smtp traffic to another interface - - traffic-shape certain network streams - - transparently proxy smtp connections - - etc... - - For more informations, please refer to: - - - - If unsure, say N. - -config ECONET - tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" - depends on EXPERIMENTAL && INET - ---help--- - Econet is a fairly old and slow networking protocol mainly used by - Acorn computers to access file and print servers. It uses native - Econet network cards. AUN is an implementation of the higher level - parts of Econet that runs over ordinary Ethernet connections, on - top of the UDP packet protocol, which in turn runs on top of the - Internet protocol IP. - - If you say Y here, you can choose with the next two options whether - to send Econet/AUN traffic over a UDP Ethernet connection or over - a native Econet network card. - - To compile this driver as a module, choose M here: the module - will be called econet. - -config ECONET_AUNUDP - bool "AUN over UDP" - depends on ECONET - help - Say Y here if you want to send Econet/AUN traffic over a UDP - connection (UDP is a packet based protocol that runs on top of the - Internet protocol IP) using an ordinary Ethernet network card. - -config ECONET_NATIVE - bool "Native Econet" - depends on ECONET - help - Say Y here if you have a native Econet network card installed in - your computer. - -config WAN_ROUTER - tristate "WAN router" - depends on EXPERIMENTAL - ---help--- - Wide Area Networks (WANs), such as X.25, frame relay and leased - lines, are used to interconnect Local Area Networks (LANs) over vast - distances with data transfer rates significantly higher than those - achievable with commonly used asynchronous modem connections. - Usually, a quite expensive external device called a `WAN router' is - needed to connect to a WAN. - - As an alternative, WAN routing can be built into the Linux kernel. - With relatively inexpensive WAN interface cards available on the - market, a perfectly usable router can be built for less than half - the price of an external router. If you have one of those cards and - wish to use your Linux box as a WAN router, say Y here and also to - the WAN driver for your card, below. You will then need the - wan-tools package which is available from . - Read for more - information. - - To compile WAN routing support as a module, choose M here: the - module will be called wanrouter. - - If unsure, say N. - -menu "QoS and/or fair queueing" - -config NET_SCHED - bool "QoS and/or fair queueing" - ---help--- - When the kernel has several packets to send out over a network - device, it has to decide which ones to send first, which ones to - delay, and which ones to drop. This is the job of the packet - scheduler, and several different algorithms for how to do this - "fairly" have been proposed. - - If you say N here, you will get the standard packet scheduler, which - is a FIFO (first come, first served). If you say Y here, you will be - able to choose from among several alternative algorithms which can - then be attached to different network devices. This is useful for - example if some of your network devices are real time devices that - need a certain minimum data flow rate, or if you need to limit the - maximum data flow rate for traffic which matches specified criteria. - This code is considered to be experimental. - - To administer these schedulers, you'll need the user-level utilities - from the package iproute2+tc at . - That package also contains some documentation; for more, check out - . - - This Quality of Service (QoS) support will enable you to use - Differentiated Services (diffserv) and Resource Reservation Protocol - (RSVP) on your Linux router if you also say Y to "QoS support", - "Packet classifier API" and to some classifiers below. Documentation - and software is at . - - If you say Y here and to "/proc file system" below, you will be able - to read status information about packet schedulers from the file - /proc/net/psched. - - The available schedulers are listed in the following questions; you - can say Y to as many as you like. If unsure, say N now. +endif # if NETFILTER +endmenu # "Network packet filtering" source "net/sched/Kconfig" - -endmenu - -menu "Network testing" - -config NET_PKTGEN - tristate "Packet Generator (USE WITH CAUTION)" - depends on PROC_FS - ---help--- - This module will inject preconfigured packets, at a configurable - rate, out of a given interface. It is used for network interface - stress testing and performance analysis. If you don't understand - what was just said, you don't need it: say N. - - Documentation on how to use the packet generator can be found - at . - - To compile this code as a module, choose M here: the - module will be called pktgen. - -endmenu - -endmenu - -config NETPOLL - def_bool NETCONSOLE - -config NETPOLL_RX - bool "Netpoll support for trapping incoming packets" - default n - depends on NETPOLL - -config NETPOLL_TRAP - bool "Netpoll traffic trapping" - default n - depends on NETPOLL - -config NET_POLL_CONTROLLER - def_bool NETPOLL - +source "net/xfrm/Kconfig" +source "net/packet/Kconfig" +source "net/unix/Kconfig" +source "net/bridge/Kconfig" +source "net/8021q/Kconfig" +source "net/wanrouter/Kconfig" source "net/ax25/Kconfig" - source "net/irda/Kconfig" - source "net/bluetooth/Kconfig" +source "net/atm/Kconfig" +source "net/core/Kconfig" -source "drivers/net/Kconfig" - -endmenu +endif # if NET +endmenu # "Networking" diff -Nru a/net/appletalk/Kconfig b/net/appletalk/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/appletalk/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,33 @@ +# +# Appletalk configuration +# + +config ATALK + tristate "Appletalk protocol support" + depends on NET + select LLC + ---help--- + AppleTalk is the protocol that Apple computers can use to communicate + on a network. If your Linux box is connected to such a network and you + wish to connect to it, say Y. You will need to use the netatalk package + so that your Linux box can act as a print and file server for Macs as + well as access AppleTalk printers. Check out + on the WWW for details. + EtherTalk is the name used for AppleTalk over Ethernet and the + cheaper and slower LocalTalk is AppleTalk over a proprietary Apple + network using serial links. EtherTalk and LocalTalk are fully + supported by Linux. + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . The + NET-3-HOWTO, available from + , contains valuable + information as well. + + To compile this driver as a module, choose M here: the module will be + called appletalk. You almost certainly want to compile it as a + module so you can restart your AppleTalk stack without rebooting + your machine. I hear that the GNU boycott of Apple is over, so + even politically correct people are allowed to say Y here. + +source "drivers/net/appletalk/Kconfig" diff -Nru a/net/atm/Kconfig b/net/atm/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/atm/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,79 @@ +# +# ATM Configarition +# + +menu "Asynchronous Transfer Mode (ATM)" + +config ATM + tristate "Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + ATM is a high-speed networking technology for Local Area Networks + and Wide Area Networks. It uses a fixed packet size and is + connection oriented, allowing for the negotiation of minimum + bandwidth requirements. + + In order to participate in an ATM network, your Linux box needs an + ATM networking card. If you have that, say Y here and to the driver + of your ATM card below. + + Note that you need a set of user-space programs to actually make use + of ATM. See the file for + further details. + +config ATM_CLIP + tristate "Classical IP over ATM (EXPERIMENTAL)" + depends on ATM && INET + help + Classical IP over ATM for PVCs and SVCs, supporting InARP and + ATMARP. If you want to communication with other IP hosts on your ATM + network, you will typically either say Y here or to "LAN Emulation + (LANE)" below. + +config ATM_CLIP_NO_ICMP + bool "Do NOT send ICMP if no neighbour (EXPERIMENTAL)" + depends on ATM_CLIP + help + Normally, an "ICMP host unreachable" message is sent if a neighbour + cannot be reached because there is no VC to it in the kernel's + ATMARP table. This may cause problems when ATMARP table entries are + briefly removed during revalidation. If you say Y here, packets to + such neighbours are silently discarded instead. + +config ATM_LANE + tristate "LAN Emulation (LANE) support (EXPERIMENTAL)" + depends on ATM + help + LAN Emulation emulates services of existing LANs across an ATM + network. Besides operating as a normal ATM end station client, Linux + LANE client can also act as an proxy client bridging packets between + ELAN and Ethernet segments. You need LANE if you want to try MPOA. + +config ATM_MPOA + tristate "Multi-Protocol Over ATM (MPOA) support (EXPERIMENTAL)" + depends on ATM && INET && ATM_LANE!=n + help + Multi-Protocol Over ATM allows ATM edge devices such as routers, + bridges and ATM attached hosts establish direct ATM VCs across + subnetwork boundaries. These shortcut connections bypass routers + enhancing overall network performance. + +config ATM_BR2684 + tristate "RFC1483/2684 Bridged protocols" + depends on ATM && INET + help + ATM PVCs can carry ethernet PDUs according to rfc2684 (formerly 1483) + This device will act like an ethernet from the kernels point of view, + with the traffic being carried by ATM PVCs (currently 1 PVC/device). + This is sometimes used over DSL lines. If in doubt, say N. + +config ATM_BR2684_IPFILTER + bool "Per-VC IP filter kludge" + depends on ATM_BR2684 + help + This is an experimental mechanism for users who need to terminating a + large number of IP-only vcc's. Do not enable this unless you are sure + you know what you are doing. + +endmenu # "Asynchronous Transfer Mode (ATM)" + diff -Nru a/net/ax25/Kconfig b/net/ax25/Kconfig --- a/net/ax25/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/ax25/Kconfig 2005-04-05 23:02:06 +02:00 @@ -6,7 +6,9 @@ # Joerg Reuter DL1BKE # 19980129 Moved to net/ax25/Config.in, sourcing device drivers. -menuconfig HAMRADIO +menu "Amateur Radio support" + +config HAMRADIO depends on NET bool "Amateur Radio support" help @@ -107,4 +109,5 @@ source "drivers/net/hamradio/Kconfig" endmenu +endmenu # "Amateur Radio support" diff -Nru a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig --- a/net/bluetooth/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/bluetooth/Kconfig 2005-04-05 23:02:06 +02:00 @@ -2,7 +2,9 @@ # Bluetooth subsystem configuration # -menuconfig BT +menu "Bluetooth subsystem support" + +config BT depends on NET tristate "Bluetooth subsystem support" help @@ -60,4 +62,6 @@ source "net/bluetooth/hidp/Kconfig" source "drivers/bluetooth/Kconfig" + +endmenu # "Bluetooth subsystem support" diff -Nru a/net/bridge/Kconfig b/net/bridge/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/bridge/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,32 @@ +# +# Configuration for Ethernet bridging +# + +config BRIDGE + tristate "802.1d Ethernet Bridging" + ---help--- + If you say Y here, then your Linux box will be able to act as an + Ethernet bridge, which means that the different Ethernet segments it + is connected to will appear as one Ethernet to the participants. + Several such bridges can work together to create even larger + networks of Ethernets using the IEEE 802.1 spanning tree algorithm. + As this is a standard, Linux bridges will cooperate properly with + other third party bridge products. + + In order to use the Ethernet bridge, you'll need the bridge + configuration tools; see + for location. Please read the Bridge mini-HOWTO for more + information. + + If you enable iptables support along with the bridge support then you + turn your bridge into a bridging IP firewall. + iptables will then see the IP packets being bridged, so you need to + take this into account when setting up your firewall rules. + Enabling arptables support when bridging will let arptables see + bridged ARP traffic in the arptables FORWARD chain. + + To compile this code as a module, choose M here: the module + will be called bridge. + + If unsure, say N. + diff -Nru a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig --- a/net/bridge/netfilter/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/bridge/netfilter/Kconfig 2005-04-05 23:02:06 +02:00 @@ -139,6 +139,7 @@ config BRIDGE_EBT_ARPREPLY tristate "ebt: arp reply target support" depends on BRIDGE_NF_EBTABLES + depends on INET help This option adds the arp reply target, which allows automatically sending arp replies to arp requests. diff -Nru a/net/core/Kconfig b/net/core/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/core/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,67 @@ +# +# Core configuration +# + +menu "Network testing" + +config NET_DIVERT + bool "Frame Diverter (EXPERIMENTAL)" + depends on EXPERIMENTAL + ---help--- + The Frame Diverter allows you to divert packets from the + network, that are not aimed at the interface receiving it (in + promisc. mode). Typically, a Linux box setup as an Ethernet bridge + with the Frames Diverter on, can do some *really* transparent www + caching using a Squid proxy for example. + + This is very useful when you don't want to change your router's + config (or if you simply don't have access to it). + + The other possible usages of diverting Ethernet Frames are + numberous: + - reroute smtp traffic to another interface + - traffic-shape certain network streams + - transparently proxy smtp connections + - etc... + + For more informations, please refer to: + + + + If unsure, say N. + +config NET_PKTGEN + tristate "Packet Generator (USE WITH CAUTION)" + depends on PROC_FS + depends on INET + ---help--- + This module will inject preconfigured packets, at a configurable + rate, out of a given interface. It is used for network interface + stress testing and performance analysis. If you don't understand + what was just said, you don't need it: say N. + + Documentation on how to use the packet generator can be found + at . + + To compile this code as a module, choose M here: the + module will be called pktgen. + +endmenu + +config NETPOLL + def_bool NETCONSOLE + +config NETPOLL_RX + bool "Netpoll support for trapping incoming packets" + default n + depends on NETPOLL + +config NETPOLL_TRAP + bool "Netpoll traffic trapping" + default n + depends on NETPOLL + +config NET_POLL_CONTROLLER + def_bool NETPOLL + + diff -Nru a/net/decnet/Kconfig b/net/decnet/Kconfig --- a/net/decnet/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/decnet/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,6 +1,30 @@ # # DECnet configuration # + +config DECNET + tristate "DECnet Support" + ---help--- + The DECnet networking protocol was used in many products made by + Digital (now Compaq). It provides reliable stream and sequenced + packet communications over which run a variety of services similar + to those which run over TCP/IP. + + To find some tools to use with the kernel layer support, please + look at Patrick Caulfield's web site: + . + + More detailed documentation is available in + . + + Be sure to say Y to "/proc file system support" and "Sysctl support" + below when using DECnet, since you will need sysctl support to aid + in configuration at run time. + + The DECnet code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called decnet. + config DECNET_ROUTER bool "DECnet: router support (EXPERIMENTAL)" depends on DECNET && EXPERIMENTAL diff -Nru a/net/econet/Kconfig b/net/econet/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/econet/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,34 @@ + +config ECONET + tristate "Acorn Econet/AUN protocols (EXPERIMENTAL)" + depends on EXPERIMENTAL && INET + ---help--- + Econet is a fairly old and slow networking protocol mainly used by + Acorn computers to access file and print servers. It uses native + Econet network cards. AUN is an implementation of the higher level + parts of Econet that runs over ordinary Ethernet connections, on + top of the UDP packet protocol, which in turn runs on top of the + Internet protocol IP. + + If you say Y here, you can choose with the next two options whether + to send Econet/AUN traffic over a UDP Ethernet connection or over + a native Econet network card. + + To compile this driver as a module, choose M here: the module + will be called econet. + +config ECONET_AUNUDP + bool "AUN over UDP" + depends on ECONET + help + Say Y here if you want to send Econet/AUN traffic over a UDP + connection (UDP is a packet based protocol that runs on top of the + Internet protocol IP) using an ordinary Ethernet network card. + +config ECONET_NATIVE + bool "Native Econet" + depends on ECONET + help + Say Y here if you have a native Econet network card installed in + your computer. + diff -Nru a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig --- a/net/ipv4/netfilter/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/ipv4/netfilter/Kconfig 2005-04-05 23:02:06 +02:00 @@ -2,9 +2,6 @@ # IP netfilter configuration # -menu "IP: Netfilter Configuration" - depends on INET && NETFILTER - # connection tracking, helpers and protocols config IP_NF_CONNTRACK tristate "Connection tracking (required for masq/NAT)" @@ -691,6 +688,4 @@ help Allows altering the ARP packet payload: source and destination hardware and network addresses. - -endmenu diff -Nru a/net/ipv6/Kconfig b/net/ipv6/Kconfig --- a/net/ipv6/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/ipv6/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,6 +1,26 @@ # # IPv6 configuration # + +# IPv6 as module will cause a CRASH if you try to unload it +config IPV6 + tristate "The IPv6 protocol" + default m + select CRYPTO if IPV6_PRIVACY + select CRYPTO_MD5 if IPV6_PRIVACY + ---help--- + This is complemental support for the IP version 6. + You will still be able to do traditional IPv4 networking as well. + + For general information about IPv6, see + . + For Linux IPv6 development information, see . + For specific information about IPv6 under Linux, read the HOWTO at + . + + To compile this protocol support as a module, choose M here: the + module will be called ipv6. + config IPV6_PRIVACY bool "IPv6: Privacy Extensions (RFC 3041) support" depends on IPV6 diff -Nru a/net/ipx/Kconfig b/net/ipx/Kconfig --- a/net/ipx/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/ipx/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,6 +1,39 @@ # # IPX configuration # +config IPX + tristate "The IPX protocol" + select LLC + ---help--- + This is support for the Novell networking protocol, IPX, commonly + used for local networks of Windows machines. You need it if you + want to access Novell NetWare file or print servers using the Linux + Novell client ncpfs (available from + ) or from + within the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, + available from ). In order + to do the former, you'll also have to say Y to "NCP file system + support", below. + + IPX is similar in scope to IP, while SPX, which runs on top of IPX, + is similar to TCP. There is also experimental support for SPX in + Linux (see "SPX networking", below). + + To turn your Linux box into a fully featured NetWare file server and + IPX router, say Y here and fetch either lwared from + or + mars_nwe from . For more + information, read the IPX-HOWTO available from + . + + General information about how to connect Linux, Windows machines and + Macs is on the WWW at . + + The IPX driver would enlarge your kernel by about 16 KB. To compile + this driver as a module, choose M here: the module will be called ipx. + Unless you want to integrate your Linux box with a local Novell + network, say N. + config IPX_INTERN bool "IPX: Full internal IPX network" depends on IPX diff -Nru a/net/irda/Kconfig b/net/irda/Kconfig --- a/net/irda/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/irda/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,8 +1,9 @@ # # IrDA protocol configuration # +menu "IrDA (infrared) subsystem support" -menuconfig IRDA +config IRDA depends on NET tristate "IrDA (infrared) subsystem support" select CRC_CCITT @@ -93,4 +94,6 @@ If unsure, say Y (since it makes it easier to find the bugs). source "drivers/net/irda/Kconfig" + +endmenu # "IrDA (infrared) subsystem support" diff -Nru a/net/lapb/Kconfig b/net/lapb/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/lapb/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,24 @@ +# +# LAPB Configuration +# + +config LAPB + tristate "LAPB Data Link Driver (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + Link Access Procedure, Balanced (LAPB) is the data link layer (i.e. + the lower) part of the X.25 protocol. It offers a reliable + connection service to exchange data frames with one other host, and + it is used to transport higher level protocols (mostly X.25 Packet + Layer, the higher part of X.25, but others are possible as well). + Usually, LAPB is used with specialized X.21 network cards, but Linux + currently supports LAPB only over Ethernet connections. If you want + to use LAPB connections over Ethernet, say Y here and to "LAPB over + Ethernet driver" below. Read + for technical + details. + + To compile this driver as a module, choose M here: the + module will be called lapb. If unsure, say N. + + diff -Nru a/net/packet/Kconfig b/net/packet/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/packet/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,26 @@ +# +# Packet configuration +# + +config PACKET + tristate "Packet socket" + ---help--- + The Packet protocol is used by applications which communicate + directly with network devices without an intermediate network + protocol implemented in the kernel, e.g. tcpdump. If you want them + to work, choose Y. + + To compile this driver as a module, choose M here: the module will + be called af_packet. + + If unsure, say Y. + +config PACKET_MMAP + bool "Packet socket: mmapped IO" + depends on PACKET + help + If you say Y here, the Packet protocol driver will use an IO + mechanism that results in faster communication. + + If unsure, say N. + diff -Nru a/net/sched/Kconfig b/net/sched/Kconfig --- a/net/sched/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/sched/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,6 +1,45 @@ # # Traffic control configuration. # + +menu "QoS and/or fair queueing" + +config NET_SCHED + bool "QoS and/or fair queueing" + ---help--- + When the kernel has several packets to send out over a network + device, it has to decide which ones to send first, which ones to + delay, and which ones to drop. This is the job of the packet + scheduler, and several different algorithms for how to do this + "fairly" have been proposed. + + If you say N here, you will get the standard packet scheduler, which + is a FIFO (first come, first served). If you say Y here, you will be + able to choose from among several alternative algorithms which can + then be attached to different network devices. This is useful for + example if some of your network devices are real time devices that + need a certain minimum data flow rate, or if you need to limit the + maximum data flow rate for traffic which matches specified criteria. + This code is considered to be experimental. + + To administer these schedulers, you'll need the user-level utilities + from the package iproute2+tc at . + That package also contains some documentation; for more, check out + . + + This Quality of Service (QoS) support will enable you to use + Differentiated Services (diffserv) and Resource Reservation Protocol + (RSVP) on your Linux router if you also say Y to "QoS support", + "Packet classifier API" and to some classifiers below. Documentation + and software is at . + + If you say Y here and to "/proc file system" below, you will be able + to read status information about packet schedulers from the file + /proc/net/psched. + + The available schedulers are listed in the following questions; you + can say Y to as many as you like. If unsure, say N now. + choice prompt "Packet scheduler clock source" depends on NET_SCHED @@ -506,3 +545,4 @@ Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. +endmenu diff -Nru a/net/sctp/Kconfig b/net/sctp/Kconfig --- a/net/sctp/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/sctp/Kconfig 2005-04-05 23:02:06 +02:00 @@ -2,11 +2,15 @@ # SCTP configuration # -menu "SCTP Configuration (EXPERIMENTAL)" - depends on INET && EXPERIMENTAL +# Dummy added to make idention correct in menuconfig +# The depends on IPV6 || IPV6=n causes SCTP to be indented an extra level +# if following line is omitted +config IP_SCTP config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" + depends on EXPERIMENTAL + # Avoid SCTP as built-in if IPV6 is a module depends on IPV6 || IPV6=n select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5 @@ -86,4 +90,3 @@ advised to use either HMAC-MD5 or HMAC-SHA1. endchoice -endmenu diff -Nru a/net/unix/Kconfig b/net/unix/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/unix/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,22 @@ +# +# Configuration for Unix domain sockets +# + +config UNIX + tristate "Unix domain sockets" + ---help--- + If you say Y here, you will include support for Unix domain sockets; + sockets are the standard Unix mechanism for establishing and + accessing network connections. Many commonly used programs such as + the X Window system and syslog use these sockets even if your + machine is not connected to any network. Unless you are working on + an embedded system or something similar, you therefore definitely + want to say Y here. + + To compile this driver as a module, choose M here: the module will be + called unix. Note that several important services won't work + correctly if you say M here and then neglect to load the module. + + Say Y unless you know what you are doing. + + diff -Nru a/net/wanrouter/Kconfig b/net/wanrouter/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/wanrouter/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,31 @@ +# +# Configuration for WAN Router +# + +config WAN_ROUTER + tristate "WAN router" + depends on EXPERIMENTAL + ---help--- + Wide Area Networks (WANs), such as X.25, frame relay and leased + lines, are used to interconnect Local Area Networks (LANs) over vast + distances with data transfer rates significantly higher than those + achievable with commonly used asynchronous modem connections. + Usually, a quite expensive external device called a `WAN router' is + needed to connect to a WAN. + + As an alternative, WAN routing can be built into the Linux kernel. + With relatively inexpensive WAN interface cards available on the + market, a perfectly usable router can be built for less than half + the price of an external router. If you have one of those cards and + wish to use your Linux box as a WAN router, say Y here and also to + the WAN driver for your card, below. You will then need the + wan-tools package which is available from . + Read for more + information. + + To compile WAN routing support as a module, choose M here: the + module will be called wanrouter. + + If unsure, say N. + + diff -Nru a/net/x25/Kconfig b/net/x25/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/x25/Kconfig 2005-04-05 23:02:06 +02:00 @@ -0,0 +1,35 @@ +# +# X25 Configuration +# + +config X25 + tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)" + depends on NET && EXPERIMENTAL + ---help--- + X.25 is a set of standardized network protocols, similar in scope to + frame relay; the one physical line from your box to the X.25 network + entry point can carry several logical point-to-point connections + (called "virtual circuits") to other computers connected to the X.25 + network. Governments, banks, and other organizations tend to use it + to connect to each other or to form Wide Area Networks (WANs). Many + countries have public X.25 networks. X.25 consists of two + protocols: the higher level Packet Layer Protocol (PLP) (say Y here + if you want that) and the lower level data link layer protocol LAPB + (say Y to "LAPB Data Link Driver" below if you want that). + + You can read more about X.25 at and + . + Information about X.25 for Linux is contained in the files + and + . + + One connects to an X.25 network either with a dedicated network card + using the X.21 protocol (not yet supported by Linux) or one can do + X.25 over a standard telephone line using an ordinary modem (say Y + to "X.25 async driver" below) or over Ethernet using an ordinary + Ethernet card and the LAPB over Ethernet (say Y to "LAPB Data Link + Driver" and "LAPB over Ethernet driver" below). + + To compile this driver as a module, choose M here: the module + will be called x25. If unsure, say N. + diff -Nru a/net/xfrm/Kconfig b/net/xfrm/Kconfig --- a/net/xfrm/Kconfig 2005-04-05 23:02:06 +02:00 +++ b/net/xfrm/Kconfig 2005-04-05 23:02:06 +02:00 @@ -1,6 +1,10 @@ # # XFRM configuration # + +config XFRM + bool + config XFRM_USER tristate "IPsec user configuration interface" depends on INET && XFRM @@ -9,4 +13,14 @@ by native Linux tools. If unsure, say Y. + +config NET_KEY + tristate "PF_KEY sockets" + select XFRM + ---help--- + PF_KEYv2 socket family, compatible to KAME ones. + They are required if you are going to use IPsec tools ported + from KAME. + + Say Y unless you know what you are doing. From jean-mickael.guerin@6wind.com Tue Apr 5 14:39:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:39:49 -0700 (PDT) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Ldfoh027916 for ; Tue, 5 Apr 2005 14:39:44 -0700 Received: from [82.225.148.74] (michelet-10-82-225-148-74.fbx.proxad.net [82.225.148.74]) by eagle.6wind.com (Postfix) with ESMTP id BE71E5C; Tue, 5 Apr 2005 23:39:40 +0200 (CEST) Message-ID: <4253059C.1080000@6wind.com> Date: Tue, 05 Apr 2005 23:39:40 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Yusupov Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event References: <1112730889.16753.17.camel@beastie> In-Reply-To: <1112730889.16753.17.camel@beastie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-mickael.guerin@6wind.com Precedence: bulk X-list: netdev Dmitry Yusupov wrote: > This patch provides: > > * new event for unicast connections NETLINK_UESTABLISHED. Which kind of application takes benefit of this event ? btw your diff is reversed ;-) Jean-Mickael From ravinandan.arakali@neterion.com Tue Apr 5 14:41:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:41:18 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35LfCrS028237 for ; Tue, 5 Apr 2005 14:41:12 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j35LewOC016522; Tue, 5 Apr 2005 17:40:58 -0400 (EDT) Received: from rarakali ([10.16.16.56]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j35LesDD009936; Tue, 5 Apr 2005 17:40:54 -0400 (EDT) From: "Ravinandan Arakali" To: "'Jay Vosburgh'" Cc: "'Arthur Kepner'" , , , "'Leonid. Grossman \(E-mail\)'" , "'Raghavendra. Koushik \(E-mail\)'" Subject: RE: High CPU utilization with Bonding driver ? Date: Tue, 5 Apr 2005 14:40:47 -0700 Message-ID: <003a01c53a28$21c1d0a0$3a10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003B_01C539ED.7562F8A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200504052031.j35KVQiR027629@death.nxdomain.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C539ED.7562F8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The kernel is from SuSE9-SP1. Attached is the .config file. Ravi -----Original Message----- From: Jay Vosburgh [mailto:fubar@us.ibm.com] Sent: Tuesday, April 05, 2005 1:31 PM To: Ravinandan Arakali Cc: 'Arthur Kepner'; netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net; 'Leonid. Grossman (E-mail)'; 'Raghavendra. Koushik (E-mail)' Subject: Re: High CPU utilization with Bonding driver ? Ravinandan Arakali wrote: >The problem does not seem to be due to your patch because >the bonding driver built without your patch crashes too on load. >However, the pre-existing binary under /lib/modules/`uname -r`/... >works fine. >Any idea why this may be happening ? > >Given below is the output of trying to insmod the bonding driver. > >linux:/usr/src/linux-2.6.5-7.135/drivers/net/bonding # insmod bonding.ko >mode=4 miimon=100 What's this kernel from, and do you have the config file available? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com ------=_NextPart_000_003B_01C539ED.7562F8A0 Content-Type: application/octet-stream; name="config" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="config" #=0A= # Automatically generated make config: don't edit=0A= #=0A= CONFIG_X86_64=3Dy=0A= CONFIG_64BIT=3Dy=0A= CONFIG_X86=3Dy=0A= CONFIG_MMU=3Dy=0A= CONFIG_RWSEM_GENERIC_SPINLOCK=3Dy=0A= CONFIG_X86_CMPXCHG=3Dy=0A= CONFIG_EARLY_PRINTK=3Dy=0A= CONFIG_HPET_TIMER=3Dy=0A= CONFIG_HPET_EMULATE_RTC=3Dy=0A= CONFIG_GENERIC_ISA_DMA=3Dy=0A= =0A= #=0A= # Code maturity level options=0A= #=0A= CONFIG_EXPERIMENTAL=3Dy=0A= CONFIG_CLEAN_COMPILE=3Dy=0A= # CONFIG_STANDALONE is not set=0A= =0A= #=0A= # General setup=0A= #=0A= CONFIG_SWAP=3Dy=0A= CONFIG_SYSVIPC=3Dy=0A= CONFIG_POSIX_MQUEUE=3Dy=0A= CONFIG_BSD_PROCESS_ACCT=3Dy=0A= CONFIG_SYSCTL=3Dy=0A= CONFIG_LOG_BUF_SHIFT=3D18=0A= CONFIG_HOTPLUG=3Dy=0A= CONFIG_EVLOG=3Dy=0A= # CONFIG_EVLOG_FWPRINTK is not set=0A= CONFIG_IKCONFIG=3Dy=0A= CONFIG_IKCONFIG_PROC=3Dy=0A= # CONFIG_EMBEDDED is not set=0A= =0A= #=0A= # Class Based Kernel Resource Management=0A= #=0A= CONFIG_CKRM=3Dy=0A= CONFIG_RCFS_FS=3Dm=0A= CONFIG_CKRM_TYPE_TASKCLASS=3Dy=0A= CONFIG_CKRM_RES_NUMTASKS=3Dm=0A= CONFIG_CKRM_CPU_SCHEDULE=3Dy=0A= # CONFIG_CKRM_CPU_SCHEDULE_AT_BOOT is not set=0A= CONFIG_CKRM_TYPE_SOCKETCLASS=3Dy=0A= CONFIG_CKRM_RBCE=3Dm=0A= CONFIG_CKRM_CRBCE=3Dm=0A= CONFIG_DELAY_ACCT=3Dy=0A= CONFIG_KALLSYMS=3Dy=0A= CONFIG_FUTEX=3Dy=0A= CONFIG_EPOLL=3Dy=0A= CONFIG_IOSCHED_NOOP=3Dy=0A= CONFIG_IOSCHED_AS=3Dy=0A= CONFIG_IOSCHED_DEADLINE=3Dy=0A= CONFIG_IOSCHED_CFQ=3Dy=0A= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set=0A= =0A= #=0A= # Loadable module support=0A= #=0A= CONFIG_MODULES=3Dy=0A= CONFIG_MODULE_UNLOAD=3Dy=0A= CONFIG_MODULE_FORCE_UNLOAD=3Dy=0A= CONFIG_OBSOLETE_MODPARM=3Dy=0A= CONFIG_MODVERSIONS=3Dy=0A= CONFIG_KMOD=3Dy=0A= CONFIG_STOP_MACHINE=3Dy=0A= =0A= #=0A= # Processor type and features=0A= #=0A= # CONFIG_MK8 is not set=0A= # CONFIG_MPSC is not set=0A= CONFIG_GENERIC_CPU=3Dy=0A= CONFIG_X86_L1_CACHE_BYTES=3D128=0A= CONFIG_X86_L1_CACHE_SHIFT=3D7=0A= CONFIG_X86_TSC=3Dy=0A= CONFIG_X86_GOOD_APIC=3Dy=0A= CONFIG_MICROCODE=3Dm=0A= CONFIG_X86_MSR=3Dm=0A= CONFIG_X86_CPUID=3Dm=0A= CONFIG_X86_HT=3Dy=0A= CONFIG_X86_IO_APIC=3Dy=0A= CONFIG_X86_LOCAL_APIC=3Dy=0A= CONFIG_MTRR=3Dy=0A= CONFIG_SMP=3Dy=0A= # CONFIG_PREEMPT is not set=0A= CONFIG_SCHED_SMT=3Dy=0A= # CONFIG_K8_NUMA is not set=0A= CONFIG_HAVE_DEC_LOCK=3Dy=0A= CONFIG_NR_CPUS=3D8=0A= CONFIG_GART_IOMMU=3Dy=0A= CONFIG_SWIOTLB=3Dy=0A= CONFIG_X86_MCE=3Dy=0A= =0A= #=0A= # Power management options=0A= #=0A= CONFIG_PM=3Dy=0A= CONFIG_SOFTWARE_SUSPEND=3Dy=0A= # CONFIG_PM_DISK is not set=0A= =0A= #=0A= # ACPI (Advanced Configuration and Power Interface) Support=0A= #=0A= CONFIG_ACPI=3Dy=0A= CONFIG_ACPI_BOOT=3Dy=0A= CONFIG_ACPI_INTERPRETER=3Dy=0A= CONFIG_ACPI_SLEEP=3Dy=0A= CONFIG_ACPI_SLEEP_PROC_FS=3Dy=0A= CONFIG_ACPI_AC=3Dm=0A= CONFIG_ACPI_BATTERY=3Dm=0A= CONFIG_ACPI_BUTTON=3Dm=0A= CONFIG_ACPI_FAN=3Dm=0A= CONFIG_ACPI_PROCESSOR=3Dm=0A= CONFIG_ACPI_THERMAL=3Dm=0A= # CONFIG_ACPI_ASUS is not set=0A= # CONFIG_ACPI_TOSHIBA is not set=0A= # CONFIG_ACPI_DEBUG is not set=0A= CONFIG_ACPI_BUS=3Dy=0A= CONFIG_ACPI_EC=3Dy=0A= CONFIG_ACPI_POWER=3Dy=0A= CONFIG_ACPI_PCI=3Dy=0A= CONFIG_ACPI_SYSTEM=3Dy=0A= CONFIG_ACPI_INITRD=3Dy=0A= =0A= #=0A= # CPU Frequency scaling=0A= #=0A= CONFIG_CPU_FREQ=3Dy=0A= CONFIG_CPU_FREQ_PROC_INTF=3Dm=0A= CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=3Dy=0A= # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set=0A= CONFIG_CPU_FREQ_GOV_PERFORMANCE=3Dy=0A= CONFIG_CPU_FREQ_GOV_POWERSAVE=3Dm=0A= CONFIG_CPU_FREQ_GOV_USERSPACE=3Dm=0A= CONFIG_CPU_FREQ_GOV_ONDEMAND=3Dm=0A= # CONFIG_CPU_FREQ_24_API is not set=0A= CONFIG_CPU_FREQ_TABLE=3Dm=0A= =0A= #=0A= # CPUFreq processor drivers=0A= #=0A= CONFIG_X86_POWERNOW_K8=3Dm=0A= CONFIG_X86_POWERNOW_K8_ACPI=3Dy=0A= CONFIG_X86_SPEEDSTEP_CENTRINO=3Dm=0A= CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=3Dy=0A= CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=3Dy=0A= CONFIG_X86_ACPI_CPUFREQ=3Dm=0A= # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set=0A= =0A= #=0A= # Bus options (PCI etc.)=0A= #=0A= CONFIG_PCI=3Dy=0A= CONFIG_PCI_DIRECT=3Dy=0A= CONFIG_PCI_MMCONFIG=3Dy=0A= # CONFIG_PCI_LEGACY_PROC is not set=0A= # CONFIG_PCI_NAMES is not set=0A= =0A= #=0A= # PCMCIA/CardBus support=0A= #=0A= CONFIG_PCMCIA=3Dm=0A= # CONFIG_PCMCIA_DEBUG is not set=0A= CONFIG_YENTA=3Dm=0A= CONFIG_CARDBUS=3Dy=0A= CONFIG_I82092=3Dm=0A= CONFIG_TCIC=3Dm=0A= =0A= #=0A= # PCI Hotplug Support=0A= #=0A= CONFIG_HOTPLUG_PCI=3Dm=0A= CONFIG_HOTPLUG_PCI_FAKE=3Dm=0A= CONFIG_HOTPLUG_PCI_AMD=3Dm=0A= CONFIG_HOTPLUG_PCI_ACPI=3Dm=0A= CONFIG_HOTPLUG_PCI_ACPI_IBM=3Dm=0A= CONFIG_HOTPLUG_PCI_CPCI=3Dy=0A= CONFIG_HOTPLUG_PCI_CPCI_ZT5550=3Dm=0A= CONFIG_HOTPLUG_PCI_CPCI_GENERIC=3Dm=0A= CONFIG_HOTPLUG_PCI_PCIE=3Dm=0A= # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set=0A= CONFIG_HOTPLUG_PCI_SHPC=3Dm=0A= # CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set=0A= =0A= #=0A= # Executable file formats / Emulations=0A= #=0A= CONFIG_BINFMT_ELF=3Dy=0A= CONFIG_BINFMT_MISC=3Dm=0A= CONFIG_IA32_EMULATION=3Dy=0A= CONFIG_IA32_AOUT=3Dy=0A= CONFIG_COMPAT=3Dy=0A= CONFIG_SYSVIPC_COMPAT=3Dy=0A= CONFIG_UID16=3Dy=0A= =0A= #=0A= # Device Drivers=0A= #=0A= =0A= #=0A= # Generic Driver Options=0A= #=0A= CONFIG_FW_LOADER=3Dm=0A= # CONFIG_DEBUG_DRIVER is not set=0A= =0A= #=0A= # Memory Technology Devices (MTD)=0A= #=0A= CONFIG_MTD=3Dm=0A= # CONFIG_MTD_DEBUG is not set=0A= CONFIG_MTD_PARTITIONS=3Dm=0A= CONFIG_MTD_CONCAT=3Dm=0A= CONFIG_MTD_REDBOOT_PARTS=3Dm=0A= CONFIG_MTD_CMDLINE_PARTS=3Dm=0A= =0A= #=0A= # User Modules And Translation Layers=0A= #=0A= CONFIG_MTD_CHAR=3Dm=0A= CONFIG_MTD_BLOCK=3Dm=0A= # CONFIG_MTD_BLOCK_RO is not set=0A= # CONFIG_FTL is not set=0A= # CONFIG_NFTL is not set=0A= # CONFIG_INFTL is not set=0A= =0A= #=0A= # RAM/ROM/Flash chip drivers=0A= #=0A= CONFIG_MTD_CFI=3Dm=0A= CONFIG_MTD_JEDECPROBE=3Dm=0A= CONFIG_MTD_GEN_PROBE=3Dm=0A= CONFIG_MTD_CFI_ADV_OPTIONS=3Dy=0A= CONFIG_MTD_CFI_NOSWAP=3Dy=0A= # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set=0A= # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set=0A= # CONFIG_MTD_CFI_GEOMETRY is not set=0A= CONFIG_MTD_CFI_INTELEXT=3Dm=0A= CONFIG_MTD_CFI_AMDSTD=3Dm=0A= CONFIG_MTD_CFI_STAA=3Dm=0A= # CONFIG_MTD_RAM is not set=0A= # CONFIG_MTD_ROM is not set=0A= CONFIG_MTD_ABSENT=3Dm=0A= CONFIG_MTD_OBSOLETE_CHIPS=3Dy=0A= CONFIG_MTD_AMDSTD=3Dm=0A= CONFIG_MTD_SHARP=3Dm=0A= CONFIG_MTD_JEDEC=3Dm=0A= =0A= #=0A= # Mapping drivers for chip access=0A= #=0A= CONFIG_MTD_COMPLEX_MAPPINGS=3Dy=0A= CONFIG_MTD_PHYSMAP=3Dm=0A= CONFIG_MTD_PHYSMAP_START=3D0x8000000=0A= CONFIG_MTD_PHYSMAP_LEN=3D0x4000000=0A= CONFIG_MTD_PHYSMAP_BUSWIDTH=3D2=0A= # CONFIG_MTD_PNC2000 is not set=0A= # CONFIG_MTD_SC520CDP is not set=0A= # CONFIG_MTD_NETSC520 is not set=0A= # CONFIG_MTD_SBC_GXX is not set=0A= # CONFIG_MTD_ELAN_104NC is not set=0A= # CONFIG_MTD_OCTAGON is not set=0A= # CONFIG_MTD_VMAX is not set=0A= CONFIG_MTD_SCx200_DOCFLASH=3Dm=0A= CONFIG_MTD_AMD76XROM=3Dm=0A= # CONFIG_MTD_ICH2ROM is not set=0A= CONFIG_MTD_SCB2_FLASH=3Dm=0A= # CONFIG_MTD_NETtel is not set=0A= # CONFIG_MTD_DILNETPC is not set=0A= # CONFIG_MTD_L440GX is not set=0A= CONFIG_MTD_PCI=3Dm=0A= =0A= #=0A= # Self-contained MTD device drivers=0A= #=0A= CONFIG_MTD_PMC551=3Dm=0A= CONFIG_MTD_PMC551_BUGFIX=3Dy=0A= # CONFIG_MTD_PMC551_DEBUG is not set=0A= CONFIG_MTD_SLRAM=3Dm=0A= CONFIG_MTD_MTDRAM=3Dm=0A= CONFIG_MTDRAM_TOTAL_SIZE=3D4096=0A= CONFIG_MTDRAM_ERASE_SIZE=3D128=0A= CONFIG_MTD_BLKMTD=3Dm=0A= =0A= #=0A= # Disk-On-Chip Device Drivers=0A= #=0A= CONFIG_MTD_DOC2000=3Dm=0A= CONFIG_MTD_DOC2001=3Dm=0A= CONFIG_MTD_DOC2001PLUS=3Dm=0A= CONFIG_MTD_DOCPROBE=3Dm=0A= CONFIG_MTD_DOCPROBE_ADVANCED=3Dy=0A= CONFIG_MTD_DOCPROBE_ADDRESS=3D0x0000=0A= CONFIG_MTD_DOCPROBE_HIGH=3Dy=0A= CONFIG_MTD_DOCPROBE_55AA=3Dy=0A= =0A= #=0A= # NAND Flash Device Drivers=0A= #=0A= CONFIG_MTD_NAND=3Dm=0A= # CONFIG_MTD_NAND_VERIFY_WRITE is not set=0A= CONFIG_MTD_NAND_IDS=3Dm=0A= =0A= #=0A= # Parallel port support=0A= #=0A= CONFIG_PARPORT=3Dm=0A= CONFIG_PARPORT_PC=3Dm=0A= CONFIG_PARPORT_PC_CML1=3Dm=0A= CONFIG_PARPORT_SERIAL=3Dm=0A= CONFIG_PARPORT_PC_FIFO=3Dy=0A= CONFIG_PARPORT_PC_SUPERIO=3Dy=0A= CONFIG_PARPORT_PC_PCMCIA=3Dm=0A= CONFIG_PARPORT_OTHER=3Dy=0A= CONFIG_PARPORT_1284=3Dy=0A= =0A= #=0A= # Plug and Play support=0A= #=0A= =0A= #=0A= # Block devices=0A= #=0A= CONFIG_BLK_DEV_FD=3Dm=0A= CONFIG_PARIDE=3Dm=0A= CONFIG_PARIDE_PARPORT=3Dm=0A= =0A= #=0A= # Parallel IDE high-level drivers=0A= #=0A= CONFIG_PARIDE_PD=3Dm=0A= CONFIG_PARIDE_PCD=3Dm=0A= CONFIG_PARIDE_PF=3Dm=0A= CONFIG_PARIDE_PT=3Dm=0A= CONFIG_PARIDE_PG=3Dm=0A= =0A= #=0A= # Parallel IDE protocol modules=0A= #=0A= CONFIG_PARIDE_ATEN=3Dm=0A= CONFIG_PARIDE_BPCK=3Dm=0A= CONFIG_PARIDE_COMM=3Dm=0A= CONFIG_PARIDE_DSTR=3Dm=0A= CONFIG_PARIDE_FIT2=3Dm=0A= CONFIG_PARIDE_FIT3=3Dm=0A= CONFIG_PARIDE_EPAT=3Dm=0A= CONFIG_PARIDE_EPATC8=3Dy=0A= CONFIG_PARIDE_EPIA=3Dm=0A= CONFIG_PARIDE_FRIQ=3Dm=0A= CONFIG_PARIDE_FRPW=3Dm=0A= CONFIG_PARIDE_KBIC=3Dm=0A= CONFIG_PARIDE_KTTI=3Dm=0A= CONFIG_PARIDE_ON20=3Dm=0A= CONFIG_PARIDE_ON26=3Dm=0A= CONFIG_BLK_CPQ_DA=3Dm=0A= CONFIG_BLK_CPQ_CISS_DA=3Dm=0A= CONFIG_CISS_SCSI_TAPE=3Dy=0A= CONFIG_BLK_DEV_DAC960=3Dm=0A= CONFIG_BLK_DEV_UMEM=3Dm=0A= CONFIG_BLK_DEV_LOOP=3Dy=0A= CONFIG_BLK_DEV_CRYPTOLOOP=3Dm=0A= CONFIG_BLK_DEV_NBD=3Dm=0A= CONFIG_BLK_DEV_CARMEL=3Dm=0A= CONFIG_BLK_DEV_RAM=3Dy=0A= CONFIG_BLK_DEV_RAM_SIZE=3D128000=0A= CONFIG_BLK_DEV_INITRD=3Dy=0A= CONFIG_LBD=3Dy=0A= CONFIG_CIPHER_TWOFISH=3Dm=0A= =0A= #=0A= # ATA/ATAPI/MFM/RLL support=0A= #=0A= CONFIG_IDE=3Dy=0A= CONFIG_BLK_DEV_IDE=3Dy=0A= =0A= #=0A= # Please see Documentation/ide.txt for help/info on IDE drives=0A= #=0A= # CONFIG_BLK_DEV_HD_IDE is not set=0A= CONFIG_BLK_DEV_IDEDISK=3Dy=0A= CONFIG_IDEDISK_MULTI_MODE=3Dy=0A= CONFIG_IDEDISK_STROKE=3Dy=0A= CONFIG_BLK_DEV_IDECS=3Dm=0A= CONFIG_BLK_DEV_IDECD=3Dy=0A= CONFIG_BLK_DEV_IDETAPE=3Dm=0A= CONFIG_BLK_DEV_IDEFLOPPY=3Dy=0A= CONFIG_BLK_DEV_IDESCSI=3Dm=0A= # CONFIG_IDE_TASK_IOCTL is not set=0A= # CONFIG_IDE_TASKFILE_IO is not set=0A= =0A= #=0A= # IDE chipset support/bugfixes=0A= #=0A= CONFIG_IDE_GENERIC=3Dy=0A= CONFIG_BLK_DEV_CMD640=3Dy=0A= CONFIG_BLK_DEV_CMD640_ENHANCED=3Dy=0A= CONFIG_BLK_DEV_IDEPCI=3Dy=0A= CONFIG_IDEPCI_SHARE_IRQ=3Dy=0A= CONFIG_BLK_DEV_OFFBOARD=3Dy=0A= CONFIG_BLK_DEV_GENERIC=3Dy=0A= # CONFIG_BLK_DEV_OPTI621 is not set=0A= CONFIG_BLK_DEV_RZ1000=3Dy=0A= CONFIG_BLK_DEV_IDEDMA_PCI=3Dy=0A= # CONFIG_BLK_DEV_IDEDMA_FORCED is not set=0A= CONFIG_IDEDMA_PCI_AUTO=3Dy=0A= CONFIG_IDEDMA_ONLYDISK=3Dy=0A= CONFIG_BLK_DEV_ADMA=3Dy=0A= CONFIG_BLK_DEV_AEC62XX=3Dy=0A= CONFIG_BLK_DEV_ALI15X3=3Dy=0A= # CONFIG_WDC_ALI15X3 is not set=0A= CONFIG_BLK_DEV_AMD74XX=3Dy=0A= CONFIG_BLK_DEV_ATIIXP=3Dy=0A= CONFIG_BLK_DEV_CMD64X=3Dy=0A= CONFIG_BLK_DEV_TRIFLEX=3Dy=0A= CONFIG_BLK_DEV_CY82C693=3Dy=0A= CONFIG_BLK_DEV_CS5520=3Dm=0A= CONFIG_BLK_DEV_CS5530=3Dm=0A= CONFIG_BLK_DEV_HPT34X=3Dy=0A= CONFIG_HPT34X_AUTODMA=3Dy=0A= CONFIG_BLK_DEV_HPT366=3Dy=0A= CONFIG_BLK_DEV_SC1200=3Dy=0A= CONFIG_BLK_DEV_PIIX=3Dy=0A= CONFIG_BLK_DEV_NS87415=3Dy=0A= CONFIG_BLK_DEV_PDC202XX_OLD=3Dy=0A= CONFIG_PDC202XX_BURST=3Dy=0A= CONFIG_BLK_DEV_PDC202XX_NEW=3Dy=0A= CONFIG_PDC202XX_FORCE=3Dy=0A= CONFIG_BLK_DEV_SVWKS=3Dy=0A= CONFIG_BLK_DEV_SIIMAGE=3Dy=0A= CONFIG_BLK_DEV_SIS5513=3Dy=0A= CONFIG_BLK_DEV_SLC90E66=3Dy=0A= # CONFIG_BLK_DEV_TRM290 is not set=0A= CONFIG_BLK_DEV_VIA82CXXX=3Dy=0A= CONFIG_BLK_DEV_IDEDMA=3Dy=0A= # CONFIG_IDEDMA_IVB is not set=0A= CONFIG_IDEDMA_AUTO=3Dy=0A= # CONFIG_BLK_DEV_HD is not set=0A= =0A= #=0A= # SCSI device support=0A= #=0A= CONFIG_SCSI=3Dm=0A= CONFIG_SCSI_PROC_FS=3Dy=0A= =0A= #=0A= # SCSI support type (disk, tape, CD-ROM)=0A= #=0A= CONFIG_BLK_DEV_SD=3Dm=0A= CONFIG_CHR_DEV_ST=3Dm=0A= CONFIG_CHR_DEV_OSST=3Dm=0A= CONFIG_BLK_DEV_SR=3Dm=0A= # CONFIG_BLK_DEV_SR_VENDOR is not set=0A= CONFIG_CHR_DEV_SG=3Dm=0A= CONFIG_CHR_DEV_SCH=3Dm=0A= =0A= #=0A= # Some SCSI devices (e.g. CD jukebox) support multiple LUNs=0A= #=0A= CONFIG_SCSI_MULTI_LUN=3Dy=0A= CONFIG_SCSI_CONSTANTS=3Dy=0A= CONFIG_SCSI_LOGGING=3Dy=0A= =0A= #=0A= # SCSI Transport Attributes=0A= #=0A= CONFIG_SCSI_SPI_ATTRS=3Dm=0A= CONFIG_SCSI_FC_ATTRS=3Dm=0A= =0A= #=0A= # SCSI low-level drivers=0A= #=0A= CONFIG_BLK_DEV_3W_XXXX_RAID=3Dm=0A= CONFIG_SCSI_ACARD=3Dm=0A= CONFIG_SCSI_AACRAID=3Dm=0A= CONFIG_SCSI_AIC7XXX=3Dm=0A= CONFIG_AIC7XXX_CMDS_PER_DEVICE=3D32=0A= CONFIG_AIC7XXX_RESET_DELAY_MS=3D5000=0A= # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set=0A= # CONFIG_AIC7XXX_DEBUG_ENABLE is not set=0A= CONFIG_AIC7XXX_DEBUG_MASK=3D0=0A= CONFIG_AIC7XXX_REG_PRETTY_PRINT=3Dy=0A= CONFIG_SCSI_AIC7XXX_OLD=3Dm=0A= CONFIG_SCSI_AIC79XX=3Dm=0A= CONFIG_AIC79XX_CMDS_PER_DEVICE=3D32=0A= CONFIG_AIC79XX_RESET_DELAY_MS=3D15000=0A= # CONFIG_AIC79XX_BUILD_FIRMWARE is not set=0A= # CONFIG_AIC79XX_ENABLE_RD_STRM is not set=0A= # CONFIG_AIC79XX_DEBUG_ENABLE is not set=0A= CONFIG_AIC79XX_DEBUG_MASK=3D0=0A= CONFIG_AIC79XX_REG_PRETTY_PRINT=3Dy=0A= CONFIG_SCSI_AIC79XX_NEW=3Dm=0A= CONFIG_SCSI_ADVANSYS=3Dm=0A= CONFIG_MEGARAID_NEWGEN=3Dy=0A= CONFIG_MEGARAID_MM=3Dm=0A= CONFIG_MEGARAID_MAILBOX=3Dm=0A= CONFIG_MEGARAID_LEGACY=3Dm=0A= CONFIG_SCSI_SATA=3Dy=0A= CONFIG_SCSI_SATA_SVW=3Dm=0A= CONFIG_SCSI_ATA_PIIX=3Dm=0A= CONFIG_SCSI_SATA_PROMISE=3Dm=0A= CONFIG_SCSI_SATA_SIL=3Dm=0A= CONFIG_SCSI_SATA_SIS=3Dm=0A= CONFIG_SCSI_SATA_VIA=3Dm=0A= CONFIG_SCSI_SATA_VITESSE=3Dm=0A= CONFIG_SCSI_BUSLOGIC=3Dm=0A= # CONFIG_SCSI_OMIT_FLASHPOINT is not set=0A= # CONFIG_SCSI_CPQFCTS is not set=0A= CONFIG_SCSI_DMX3191D=3Dm=0A= CONFIG_SCSI_EATA=3Dm=0A= CONFIG_SCSI_EATA_TAGGED_QUEUE=3Dy=0A= CONFIG_SCSI_EATA_LINKED_COMMANDS=3Dy=0A= CONFIG_SCSI_EATA_MAX_TAGS=3D16=0A= CONFIG_SCSI_EATA_PIO=3Dm=0A= CONFIG_SCSI_FUTURE_DOMAIN=3Dm=0A= CONFIG_SCSI_GDTH=3Dm=0A= CONFIG_SCSI_IPS=3Dm=0A= # CONFIG_SCSI_INIA100 is not set=0A= CONFIG_SCSI_PPA=3Dm=0A= CONFIG_SCSI_IMM=3Dm=0A= # CONFIG_SCSI_IZIP_EPP16 is not set=0A= # CONFIG_SCSI_IZIP_SLOW_CTR is not set=0A= CONFIG_SCSI_SYM53C8XX_2=3Dm=0A= CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=3D1=0A= CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=3D16=0A= CONFIG_SCSI_SYM53C8XX_MAX_TAGS=3D64=0A= # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set=0A= CONFIG_SCSI_LPFC=3Dm=0A= # CONFIG_SCSI_IPR is not set=0A= CONFIG_SCSI_QLOGIC_ISP=3Dm=0A= CONFIG_SCSI_QLOGIC_FC=3Dm=0A= CONFIG_SCSI_QLOGIC_FC_FIRMWARE=3Dy=0A= CONFIG_SCSI_QLOGIC_1280=3Dm=0A= CONFIG_SCSI_QLA2XXX=3Dm=0A= CONFIG_SCSI_QLA21XX=3Dm=0A= CONFIG_SCSI_QLA22XX=3Dm=0A= CONFIG_SCSI_QLA2300=3Dm=0A= CONFIG_SCSI_QLA2322=3Dm=0A= CONFIG_SCSI_QLA6312=3Dm=0A= CONFIG_SCSI_QLA6322=3Dm=0A= CONFIG_SCSI_QLA2XXX_FAILOVER=3Dy=0A= CONFIG_SCSI_QLA4XXX=3Dm=0A= CONFIG_SCSI_QLA4XXX_FAILOVER=3Dy=0A= CONFIG_SCSI_DC395x=3Dm=0A= CONFIG_SCSI_DC390T=3Dm=0A= CONFIG_SCSI_DEBUG=3Dm=0A= =0A= #=0A= # PCMCIA SCSI adapter support=0A= #=0A= CONFIG_PCMCIA_FDOMAIN=3Dm=0A= CONFIG_PCMCIA_QLOGIC=3Dm=0A= =0A= #=0A= # Multi-device support (RAID and LVM)=0A= #=0A= CONFIG_MD=3Dy=0A= CONFIG_BLK_DEV_MD=3Dy=0A= CONFIG_MD_LINEAR=3Dm=0A= CONFIG_MD_RAID0=3Dm=0A= CONFIG_MD_RAID1=3Dm=0A= CONFIG_MD_RAID5=3Dm=0A= CONFIG_MD_RAID6=3Dm=0A= CONFIG_MD_MULTIPATH=3Dm=0A= CONFIG_BLK_DEV_DM=3Dm=0A= CONFIG_DM_CRYPT=3Dm=0A= CONFIG_DM_MULTIPATH=3Dm=0A= CONFIG_DM_SNAPSHOT=3Dm=0A= CONFIG_DM_MIRROR=3Dm=0A= CONFIG_DM_ZERO=3Dm=0A= CONFIG_DM_FLAKEY=3Dm=0A= CONFIG_BLK_DEV_DM_BBR=3Dm=0A= =0A= #=0A= # Fusion MPT device support=0A= #=0A= CONFIG_FUSION=3Dm=0A= CONFIG_FUSION_MAX_SGE=3D40=0A= CONFIG_FUSION_CTL=3Dm=0A= CONFIG_FUSION_LAN=3Dm=0A= =0A= #=0A= # IEEE 1394 (FireWire) support=0A= #=0A= CONFIG_IEEE1394=3Dm=0A= =0A= #=0A= # Subsystem Options=0A= #=0A= # CONFIG_IEEE1394_VERBOSEDEBUG is not set=0A= # CONFIG_IEEE1394_OUI_DB is not set=0A= CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=3Dy=0A= CONFIG_IEEE1394_CONFIG_ROM_IP1394=3Dy=0A= =0A= #=0A= # Device Drivers=0A= #=0A= CONFIG_IEEE1394_PCILYNX=3Dm=0A= CONFIG_IEEE1394_OHCI1394=3Dm=0A= =0A= #=0A= # Protocol Drivers=0A= #=0A= CONFIG_IEEE1394_VIDEO1394=3Dm=0A= CONFIG_IEEE1394_SBP2=3Dm=0A= # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set=0A= CONFIG_IEEE1394_ETH1394=3Dm=0A= CONFIG_IEEE1394_DV1394=3Dm=0A= CONFIG_IEEE1394_RAWIO=3Dm=0A= CONFIG_IEEE1394_CMP=3Dm=0A= CONFIG_IEEE1394_AMDTP=3Dm=0A= =0A= #=0A= # I2O device support=0A= #=0A= CONFIG_I2O=3Dm=0A= CONFIG_I2O_CONFIG=3Dm=0A= CONFIG_I2O_BLOCK=3Dm=0A= CONFIG_I2O_SCSI=3Dm=0A= CONFIG_I2O_PROC=3Dm=0A= =0A= #=0A= # Networking support=0A= #=0A= CONFIG_NET=3Dy=0A= =0A= #=0A= # Networking options=0A= #=0A= CONFIG_PACKET=3Dm=0A= CONFIG_PACKET_MMAP=3Dy=0A= CONFIG_NETLINK_DEV=3Dm=0A= CONFIG_UNIX=3Dy=0A= CONFIG_NET_KEY=3Dm=0A= CONFIG_INET=3Dy=0A= CONFIG_IP_MULTICAST=3Dy=0A= CONFIG_IP_ADVANCED_ROUTER=3Dy=0A= CONFIG_IP_MULTIPLE_TABLES=3Dy=0A= CONFIG_IP_ROUTE_FWMARK=3Dy=0A= CONFIG_IP_ROUTE_NAT=3Dy=0A= CONFIG_IP_ROUTE_MULTIPATH=3Dy=0A= CONFIG_IP_ROUTE_TOS=3Dy=0A= CONFIG_IP_ROUTE_VERBOSE=3Dy=0A= CONFIG_IP_PNP=3Dy=0A= CONFIG_IP_PNP_DHCP=3Dy=0A= CONFIG_IP_PNP_BOOTP=3Dy=0A= CONFIG_IP_PNP_RARP=3Dy=0A= CONFIG_NET_IPIP=3Dm=0A= CONFIG_NET_IPGRE=3Dm=0A= CONFIG_NET_IPGRE_BROADCAST=3Dy=0A= CONFIG_IP_MROUTE=3Dy=0A= CONFIG_IP_PIMSM_V1=3Dy=0A= CONFIG_IP_PIMSM_V2=3Dy=0A= # CONFIG_ARPD is not set=0A= CONFIG_SYN_COOKIES=3Dy=0A= CONFIG_INET_AH=3Dm=0A= CONFIG_INET_ESP=3Dm=0A= CONFIG_INET_IPCOMP=3Dm=0A= # CONFIG_ACCEPT_QUEUES is not set=0A= =0A= #=0A= # IP: Virtual Server Configuration=0A= #=0A= CONFIG_IP_VS=3Dm=0A= # CONFIG_IP_VS_DEBUG is not set=0A= CONFIG_IP_VS_TAB_BITS=3D12=0A= =0A= #=0A= # IPVS transport protocol load balancing support=0A= #=0A= CONFIG_IP_VS_PROTO_TCP=3Dy=0A= CONFIG_IP_VS_PROTO_UDP=3Dy=0A= CONFIG_IP_VS_PROTO_ESP=3Dy=0A= CONFIG_IP_VS_PROTO_AH=3Dy=0A= =0A= #=0A= # IPVS scheduler=0A= #=0A= CONFIG_IP_VS_RR=3Dm=0A= CONFIG_IP_VS_WRR=3Dm=0A= CONFIG_IP_VS_LC=3Dm=0A= CONFIG_IP_VS_WLC=3Dm=0A= CONFIG_IP_VS_LBLC=3Dm=0A= CONFIG_IP_VS_LBLCR=3Dm=0A= CONFIG_IP_VS_DH=3Dm=0A= CONFIG_IP_VS_SH=3Dm=0A= CONFIG_IP_VS_SED=3Dm=0A= CONFIG_IP_VS_NQ=3Dm=0A= =0A= #=0A= # IPVS application helper=0A= #=0A= CONFIG_IP_VS_FTP=3Dm=0A= CONFIG_IPV6=3Dm=0A= CONFIG_IPV6_SUBTREES=3Dy=0A= CONFIG_IPV6_PRIVACY=3Dy=0A= CONFIG_IPV6_NDISC_NEW=3Dy=0A= CONFIG_INET6_AH=3Dm=0A= CONFIG_INET6_ESP=3Dm=0A= CONFIG_INET6_IPCOMP=3Dm=0A= CONFIG_IPV6_TUNNEL=3Dm=0A= =0A= #=0A= # MOBILE IPv6 (EXPERIMENTAL)=0A= #=0A= CONFIG_IPV6_MOBILITY=3Dm=0A= CONFIG_IPV6_MOBILITY_MN=3Dm=0A= CONFIG_IPV6_MOBILITY_HA=3Dm=0A= # CONFIG_IPV6_MOBILITY_DEBUG is not set=0A= CONFIG_DECNET=3Dm=0A= CONFIG_DECNET_SIOCGIFCONF=3Dy=0A= # CONFIG_DECNET_ROUTER is not set=0A= CONFIG_BRIDGE=3Dm=0A= CONFIG_NETFILTER=3Dy=0A= # CONFIG_NETFILTER_DEBUG is not set=0A= CONFIG_BRIDGE_NETFILTER=3Dy=0A= =0A= #=0A= # IP: Netfilter Configuration=0A= #=0A= CONFIG_IP_NF_CONNTRACK=3Dm=0A= CONFIG_IP_NF_FTP=3Dm=0A= CONFIG_IP_NF_IRC=3Dm=0A= CONFIG_IP_NF_TFTP=3Dm=0A= CONFIG_IP_NF_AMANDA=3Dm=0A= CONFIG_IP_NF_QUEUE=3Dm=0A= CONFIG_IP_NF_IPTABLES=3Dm=0A= CONFIG_IP_NF_MATCH_LIMIT=3Dm=0A= CONFIG_IP_NF_MATCH_IPRANGE=3Dm=0A= CONFIG_IP_NF_MATCH_MAC=3Dm=0A= CONFIG_IP_NF_MATCH_PKTTYPE=3Dm=0A= CONFIG_IP_NF_MATCH_POLICY=3Dm=0A= CONFIG_IP_NF_MATCH_MARK=3Dm=0A= CONFIG_IP_NF_MATCH_MULTIPORT=3Dm=0A= CONFIG_IP_NF_MATCH_TOS=3Dm=0A= CONFIG_IP_NF_MATCH_RECENT=3Dm=0A= CONFIG_IP_NF_MATCH_ECN=3Dm=0A= CONFIG_IP_NF_MATCH_DSCP=3Dm=0A= CONFIG_IP_NF_MATCH_AH_ESP=3Dm=0A= CONFIG_IP_NF_MATCH_LENGTH=3Dm=0A= CONFIG_IP_NF_MATCH_TTL=3Dm=0A= CONFIG_IP_NF_MATCH_TCPMSS=3Dm=0A= CONFIG_IP_NF_MATCH_HELPER=3Dm=0A= CONFIG_IP_NF_MATCH_STATE=3Dm=0A= CONFIG_IP_NF_MATCH_CONNTRACK=3Dm=0A= CONFIG_IP_NF_MATCH_OWNER=3Dm=0A= CONFIG_IP_NF_MATCH_PHYSDEV=3Dm=0A= CONFIG_IP_NF_FILTER=3Dm=0A= CONFIG_IP_NF_TARGET_REJECT=3Dm=0A= CONFIG_IP_NF_NAT=3Dm=0A= CONFIG_IP_NF_NAT_NEEDED=3Dy=0A= CONFIG_IP_NF_TARGET_MASQUERADE=3Dm=0A= CONFIG_IP_NF_TARGET_REDIRECT=3Dm=0A= CONFIG_IP_NF_TARGET_NETMAP=3Dm=0A= CONFIG_IP_NF_TARGET_SAME=3Dm=0A= # CONFIG_IP_NF_NAT_LOCAL is not set=0A= CONFIG_IP_NF_NAT_SNMP_BASIC=3Dm=0A= CONFIG_IP_NF_NAT_IRC=3Dm=0A= CONFIG_IP_NF_NAT_FTP=3Dm=0A= CONFIG_IP_NF_NAT_TFTP=3Dm=0A= CONFIG_IP_NF_NAT_AMANDA=3Dm=0A= CONFIG_IP_NF_MANGLE=3Dm=0A= CONFIG_IP_NF_TARGET_TOS=3Dm=0A= CONFIG_IP_NF_TARGET_ECN=3Dm=0A= CONFIG_IP_NF_TARGET_DSCP=3Dm=0A= CONFIG_IP_NF_TARGET_MARK=3Dm=0A= CONFIG_IP_NF_TARGET_CLASSIFY=3Dm=0A= CONFIG_IP_NF_TARGET_LOG=3Dm=0A= CONFIG_IP_NF_TARGET_ULOG=3Dm=0A= CONFIG_IP_NF_TARGET_TCPMSS=3Dm=0A= CONFIG_IP_NF_ARPTABLES=3Dm=0A= CONFIG_IP_NF_ARPFILTER=3Dm=0A= CONFIG_IP_NF_ARP_MANGLE=3Dm=0A= CONFIG_IP_NF_COMPAT_IPCHAINS=3Dm=0A= CONFIG_IP_NF_COMPAT_IPFWADM=3Dm=0A= CONFIG_IP_NF_CONNTRACK_MARK=3Dy=0A= CONFIG_IP_NF_TARGET_CONNMARK=3Dm=0A= CONFIG_IP_NF_MATCH_CONNMARK=3Dm=0A= CONFIG_IP_NF_TARGET_CLUSTERIP=3Dm=0A= =0A= #=0A= # IPv6: Netfilter Configuration=0A= #=0A= CONFIG_IP6_NF_FTP=3Dm=0A= CONFIG_IP6_NF_QUEUE=3Dm=0A= CONFIG_IP6_NF_IPTABLES=3Dm=0A= CONFIG_IP6_NF_MATCH_LIMIT=3Dm=0A= CONFIG_IP6_NF_MATCH_MAC=3Dm=0A= CONFIG_IP6_NF_MATCH_RT=3Dm=0A= CONFIG_IP6_NF_MATCH_OPTS=3Dm=0A= CONFIG_IP6_NF_MATCH_FRAG=3Dm=0A= CONFIG_IP6_NF_MATCH_HL=3Dm=0A= CONFIG_IP6_NF_MATCH_MULTIPORT=3Dm=0A= CONFIG_IP6_NF_MATCH_OWNER=3Dm=0A= CONFIG_IP6_NF_MATCH_MARK=3Dm=0A= CONFIG_IP6_NF_MATCH_IPV6HEADER=3Dm=0A= CONFIG_IP6_NF_MATCH_AHESP=3Dm=0A= CONFIG_IP6_NF_MATCH_LENGTH=3Dm=0A= CONFIG_IP6_NF_MATCH_EUI64=3Dm=0A= CONFIG_IP6_NF_CONNTRACK=3Dm=0A= CONFIG_IP6_NF_MATCH_STATE=3Dm=0A= CONFIG_IP6_NF_FILTER=3Dm=0A= CONFIG_IP6_NF_TARGET_LOG=3Dm=0A= CONFIG_IP6_NF_TARGET_REJECT=3Dm=0A= CONFIG_IP6_NF_MANGLE=3Dm=0A= CONFIG_IP6_NF_TARGET_MARK=3Dm=0A= =0A= #=0A= # DECnet: Netfilter Configuration=0A= #=0A= # CONFIG_DECNET_NF_GRABULATOR is not set=0A= =0A= #=0A= # Bridge: Netfilter Configuration=0A= #=0A= CONFIG_BRIDGE_NF_EBTABLES=3Dm=0A= CONFIG_BRIDGE_EBT_BROUTE=3Dm=0A= CONFIG_BRIDGE_EBT_T_FILTER=3Dm=0A= CONFIG_BRIDGE_EBT_T_NAT=3Dm=0A= CONFIG_BRIDGE_EBT_802_3=3Dm=0A= CONFIG_BRIDGE_EBT_AMONG=3Dm=0A= CONFIG_BRIDGE_EBT_ARP=3Dm=0A= CONFIG_BRIDGE_EBT_IP=3Dm=0A= CONFIG_BRIDGE_EBT_LIMIT=3Dm=0A= CONFIG_BRIDGE_EBT_MARK=3Dm=0A= CONFIG_BRIDGE_EBT_PKTTYPE=3Dm=0A= CONFIG_BRIDGE_EBT_STP=3Dm=0A= CONFIG_BRIDGE_EBT_VLAN=3Dm=0A= CONFIG_BRIDGE_EBT_ARPREPLY=3Dm=0A= CONFIG_BRIDGE_EBT_DNAT=3Dm=0A= CONFIG_BRIDGE_EBT_MARK_T=3Dm=0A= CONFIG_BRIDGE_EBT_REDIRECT=3Dm=0A= CONFIG_BRIDGE_EBT_SNAT=3Dm=0A= CONFIG_BRIDGE_EBT_LOG=3Dm=0A= CONFIG_XFRM=3Dy=0A= CONFIG_XFRM_USER=3Dm=0A= =0A= #=0A= # SCTP Configuration (EXPERIMENTAL)=0A= #=0A= CONFIG_IP_SCTP=3Dm=0A= # CONFIG_SCTP_DBG_MSG is not set=0A= # CONFIG_SCTP_DBG_OBJCNT is not set=0A= # CONFIG_SCTP_HMAC_NONE is not set=0A= # CONFIG_SCTP_HMAC_SHA1 is not set=0A= CONFIG_SCTP_HMAC_MD5=3Dy=0A= # CONFIG_ATM is not set=0A= CONFIG_VLAN_8021Q=3Dm=0A= CONFIG_LLC=3Dy=0A= CONFIG_LLC2=3Dm=0A= CONFIG_IPX=3Dm=0A= CONFIG_IPX_INTERN=3Dy=0A= CONFIG_ATALK=3Dm=0A= CONFIG_DEV_APPLETALK=3Dy=0A= CONFIG_IPDDP=3Dm=0A= CONFIG_IPDDP_ENCAP=3Dy=0A= CONFIG_IPDDP_DECAP=3Dy=0A= CONFIG_X25=3Dm=0A= CONFIG_LAPB=3Dm=0A= # CONFIG_NET_DIVERT is not set=0A= CONFIG_ECONET=3Dm=0A= # CONFIG_ECONET_AUNUDP is not set=0A= # CONFIG_ECONET_NATIVE is not set=0A= CONFIG_WAN_ROUTER=3Dm=0A= # CONFIG_NET_FASTROUTE is not set=0A= # CONFIG_NET_HW_FLOWCONTROL is not set=0A= =0A= #=0A= # QoS and/or fair queueing=0A= #=0A= CONFIG_NET_SCHED=3Dy=0A= CONFIG_NET_SCH_CBQ=3Dm=0A= CONFIG_NET_SCH_HTB=3Dm=0A= CONFIG_NET_SCH_HFSC=3Dm=0A= CONFIG_NET_SCH_CSZ=3Dm=0A= CONFIG_NET_SCH_PRIO=3Dm=0A= CONFIG_NET_SCH_RED=3Dm=0A= CONFIG_NET_SCH_SFQ=3Dm=0A= CONFIG_NET_SCH_TEQL=3Dm=0A= CONFIG_NET_SCH_TBF=3Dm=0A= CONFIG_NET_SCH_GRED=3Dm=0A= CONFIG_NET_SCH_DSMARK=3Dm=0A= CONFIG_NET_SCH_DELAY=3Dm=0A= CONFIG_NET_SCH_INGRESS=3Dm=0A= CONFIG_NET_QOS=3Dy=0A= CONFIG_NET_ESTIMATOR=3Dy=0A= CONFIG_NET_CLS=3Dy=0A= CONFIG_NET_CLS_TCINDEX=3Dm=0A= CONFIG_NET_CLS_ROUTE4=3Dm=0A= CONFIG_NET_CLS_ROUTE=3Dy=0A= CONFIG_NET_CLS_FW=3Dm=0A= CONFIG_NET_CLS_U32=3Dm=0A= CONFIG_NET_CLS_RSVP=3Dm=0A= CONFIG_NET_CLS_RSVP6=3Dm=0A= CONFIG_NET_CLS_POLICE=3Dy=0A= =0A= #=0A= # Network testing=0A= #=0A= CONFIG_NET_PKTGEN=3Dm=0A= CONFIG_NETDEVICES=3Dy=0A= =0A= #=0A= # ARCnet devices=0A= #=0A= CONFIG_ARCNET=3Dm=0A= CONFIG_ARCNET_1201=3Dm=0A= CONFIG_ARCNET_1051=3Dm=0A= CONFIG_ARCNET_RAW=3Dm=0A= CONFIG_ARCNET_COM90xx=3Dm=0A= CONFIG_ARCNET_COM90xxIO=3Dm=0A= CONFIG_ARCNET_RIM_I=3Dm=0A= # CONFIG_ARCNET_COM20020 is not set=0A= CONFIG_DUMMY=3Dm=0A= CONFIG_BONDING=3Dm=0A= CONFIG_EQUALIZER=3Dm=0A= CONFIG_TUN=3Dm=0A= CONFIG_ETHERTAP=3Dm=0A= =0A= #=0A= # Ethernet (10 or 100Mbit)=0A= #=0A= CONFIG_NET_ETHERNET=3Dy=0A= CONFIG_MII=3Dm=0A= CONFIG_HAPPYMEAL=3Dm=0A= CONFIG_SUNGEM=3Dm=0A= CONFIG_NET_VENDOR_3COM=3Dy=0A= CONFIG_VORTEX=3Dm=0A= CONFIG_TYPHOON=3Dm=0A= =0A= #=0A= # Tulip family network device support=0A= #=0A= CONFIG_NET_TULIP=3Dy=0A= CONFIG_DE2104X=3Dm=0A= CONFIG_TULIP=3Dm=0A= # CONFIG_TULIP_MWI is not set=0A= # CONFIG_TULIP_MMIO is not set=0A= CONFIG_TULIP_NAPI=3Dy=0A= CONFIG_TULIP_NAPI_HW_MITIGATION=3Dy=0A= CONFIG_DE4X5=3Dm=0A= CONFIG_WINBOND_840=3Dm=0A= CONFIG_DM9102=3Dm=0A= CONFIG_PCMCIA_XIRCOM=3Dm=0A= CONFIG_HP100=3Dm=0A= CONFIG_NET_PCI=3Dy=0A= CONFIG_PCNET32=3Dm=0A= CONFIG_AMD8111_ETH=3Dm=0A= CONFIG_ADAPTEC_STARFIRE=3Dm=0A= CONFIG_ADAPTEC_STARFIRE_NAPI=3Dy=0A= CONFIG_B44=3Dm=0A= CONFIG_FORCEDETH=3Dm=0A= CONFIG_DGRS=3Dm=0A= CONFIG_EEPRO100=3Dm=0A= # CONFIG_EEPRO100_PIO is not set=0A= CONFIG_E100=3Dm=0A= CONFIG_E100_NAPI=3Dy=0A= CONFIG_FEALNX=3Dm=0A= CONFIG_NATSEMI=3Dm=0A= CONFIG_NE2K_PCI=3Dm=0A= CONFIG_8139CP=3Dm=0A= CONFIG_8139TOO=3Dm=0A= # CONFIG_8139TOO_PIO is not set=0A= # CONFIG_8139TOO_TUNE_TWISTER is not set=0A= CONFIG_8139TOO_8129=3Dy=0A= # CONFIG_8139_OLD_RX_RESET is not set=0A= CONFIG_8139_RXBUF_IDX=3D2=0A= CONFIG_SIS900=3Dm=0A= CONFIG_EPIC100=3Dm=0A= CONFIG_SUNDANCE=3Dm=0A= # CONFIG_SUNDANCE_MMIO is not set=0A= CONFIG_VIA_RHINE=3Dm=0A= # CONFIG_VIA_RHINE_MMIO is not set=0A= =0A= #=0A= # Ethernet (1000 Mbit)=0A= #=0A= CONFIG_ACENIC=3Dm=0A= # CONFIG_ACENIC_OMIT_TIGON_I is not set=0A= CONFIG_DL2K=3Dm=0A= CONFIG_E1000=3Dm=0A= CONFIG_E1000_NAPI=3Dy=0A= CONFIG_E1000_NEW=3Dm=0A= CONFIG_E1000_NEW_NAPI=3Dy=0A= CONFIG_NS83820=3Dm=0A= CONFIG_HAMACHI=3Dm=0A= CONFIG_YELLOWFIN=3Dm=0A= CONFIG_R8169=3Dm=0A= CONFIG_SIS190=3Dm=0A= CONFIG_SK98LIN=3Dm=0A= CONFIG_TIGON3=3Dm=0A= CONFIG_NET_BROADCOM=3Dm=0A= CONFIG_NET_BROADCOM_NEW=3Dm=0A= CONFIG_NET_BCM44=3Dm=0A= CONFIG_TIGON3_NEW=3Dm=0A= =0A= #=0A= # Ethernet (10000 Mbit)=0A= #=0A= CONFIG_IXGB=3Dm=0A= CONFIG_IXGB_NAPI=3Dy=0A= CONFIG_S2IO=3Dm=0A= CONFIG_S2IO_NAPI=3Dy=0A= CONFIG_FDDI=3Dy=0A= # CONFIG_DEFXX is not set=0A= CONFIG_SKFP=3Dm=0A= CONFIG_HIPPI=3Dy=0A= CONFIG_ROADRUNNER=3Dm=0A= CONFIG_ROADRUNNER_LARGE_RINGS=3Dy=0A= CONFIG_PLIP=3Dm=0A= CONFIG_PPP=3Dm=0A= CONFIG_PPP_MULTILINK=3Dy=0A= CONFIG_PPP_FILTER=3Dy=0A= CONFIG_PPP_ASYNC=3Dm=0A= CONFIG_PPP_SYNC_TTY=3Dm=0A= CONFIG_PPP_DEFLATE=3Dm=0A= CONFIG_PPP_BSDCOMP=3Dm=0A= CONFIG_PPP_MPPE=3Dm=0A= CONFIG_PPPOE=3Dm=0A= CONFIG_SLIP=3Dm=0A= CONFIG_SLIP_COMPRESSED=3Dy=0A= CONFIG_SLIP_SMART=3Dy=0A= CONFIG_SLIP_MODE_SLIP6=3Dy=0A= =0A= #=0A= # Wireless LAN (non-hamradio)=0A= #=0A= CONFIG_NET_RADIO=3Dy=0A= =0A= #=0A= # Obsolete Wireless cards support (pre-802.11)=0A= #=0A= CONFIG_STRIP=3Dm=0A= CONFIG_PCMCIA_WAVELAN=3Dm=0A= CONFIG_PCMCIA_NETWAVE=3Dm=0A= =0A= #=0A= # Wireless 802.11 Frequency Hopping cards support=0A= #=0A= CONFIG_PCMCIA_RAYCS=3Dm=0A= =0A= #=0A= # Wireless 802.11b ISA/PCI cards support=0A= #=0A= CONFIG_AIRO=3Dm=0A= CONFIG_HERMES=3Dm=0A= CONFIG_PLX_HERMES=3Dm=0A= CONFIG_TMD_HERMES=3Dm=0A= CONFIG_PCI_HERMES=3Dm=0A= CONFIG_ATMEL=3Dm=0A= CONFIG_PCI_ATMEL=3Dm=0A= =0A= #=0A= # Wireless 802.11b Pcmcia/Cardbus cards support=0A= #=0A= CONFIG_PCMCIA_HERMES=3Dm=0A= CONFIG_AIRO_CS=3Dm=0A= CONFIG_PCMCIA_ATMEL=3Dm=0A= CONFIG_PCMCIA_WL3501=3Dm=0A= =0A= #=0A= # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support=0A= #=0A= CONFIG_PRISM54=3Dm=0A= CONFIG_NET_WIRELESS=3Dy=0A= =0A= #=0A= # Token Ring devices=0A= #=0A= CONFIG_TR=3Dy=0A= CONFIG_IBMOL=3Dm=0A= # CONFIG_IBMLS is not set=0A= CONFIG_3C359=3Dm=0A= CONFIG_TMS380TR=3Dm=0A= CONFIG_TMSPCI=3Dm=0A= CONFIG_ABYSS=3Dm=0A= CONFIG_NET_FC=3Dy=0A= CONFIG_NET_LPFC=3Dm=0A= CONFIG_SHAPER=3Dm=0A= CONFIG_NETCONSOLE=3Dm=0A= =0A= #=0A= # Wan interfaces=0A= #=0A= # CONFIG_WAN is not set=0A= =0A= #=0A= # PCMCIA network device support=0A= #=0A= CONFIG_NET_PCMCIA=3Dy=0A= CONFIG_PCMCIA_3C589=3Dm=0A= CONFIG_PCMCIA_3C574=3Dm=0A= CONFIG_PCMCIA_FMVJ18X=3Dm=0A= CONFIG_PCMCIA_PCNET=3Dm=0A= CONFIG_PCMCIA_NMCLAN=3Dm=0A= CONFIG_PCMCIA_SMC91C92=3Dm=0A= CONFIG_PCMCIA_XIRC2PS=3Dm=0A= CONFIG_PCMCIA_AXNET=3Dm=0A= =0A= #=0A= # Amateur Radio support=0A= #=0A= CONFIG_HAMRADIO=3Dy=0A= =0A= #=0A= # Packet Radio protocols=0A= #=0A= CONFIG_AX25=3Dm=0A= CONFIG_AX25_DAMA_SLAVE=3Dy=0A= CONFIG_NETROM=3Dm=0A= CONFIG_ROSE=3Dm=0A= =0A= #=0A= # AX.25 network device drivers=0A= #=0A= CONFIG_BPQETHER=3Dm=0A= CONFIG_BAYCOM_SER_FDX=3Dm=0A= CONFIG_BAYCOM_SER_HDX=3Dm=0A= CONFIG_BAYCOM_PAR=3Dm=0A= CONFIG_YAM=3Dm=0A= =0A= #=0A= # IrDA (infrared) support=0A= #=0A= CONFIG_IRDA=3Dm=0A= =0A= #=0A= # IrDA protocols=0A= #=0A= CONFIG_IRLAN=3Dm=0A= CONFIG_IRNET=3Dm=0A= CONFIG_IRCOMM=3Dm=0A= CONFIG_IRDA_ULTRA=3Dy=0A= =0A= #=0A= # IrDA options=0A= #=0A= CONFIG_IRDA_CACHE_LAST_LSAP=3Dy=0A= # CONFIG_IRDA_FAST_RR is not set=0A= # CONFIG_IRDA_DEBUG is not set=0A= =0A= #=0A= # Infrared-port device drivers=0A= #=0A= =0A= #=0A= # SIR device drivers=0A= #=0A= CONFIG_IRTTY_SIR=3Dm=0A= =0A= #=0A= # Dongle support=0A= #=0A= CONFIG_DONGLE=3Dy=0A= CONFIG_ESI_DONGLE=3Dm=0A= CONFIG_ACTISYS_DONGLE=3Dm=0A= CONFIG_TEKRAM_DONGLE=3Dm=0A= CONFIG_LITELINK_DONGLE=3Dm=0A= CONFIG_MA600_DONGLE=3Dm=0A= CONFIG_GIRBIL_DONGLE=3Dm=0A= CONFIG_MCP2120_DONGLE=3Dm=0A= CONFIG_OLD_BELKIN_DONGLE=3Dm=0A= CONFIG_ACT200L_DONGLE=3Dm=0A= =0A= #=0A= # Old SIR device drivers=0A= #=0A= =0A= #=0A= # Old Serial dongle support=0A= #=0A= =0A= #=0A= # FIR device drivers=0A= #=0A= CONFIG_USB_IRDA=3Dm=0A= CONFIG_SIGMATEL_FIR=3Dm=0A= CONFIG_VLSI_FIR=3Dm=0A= =0A= #=0A= # Bluetooth support=0A= #=0A= CONFIG_BT=3Dm=0A= CONFIG_BT_L2CAP=3Dm=0A= CONFIG_BT_SCO=3Dm=0A= CONFIG_BT_RFCOMM=3Dm=0A= CONFIG_BT_RFCOMM_TTY=3Dy=0A= CONFIG_BT_BNEP=3Dm=0A= CONFIG_BT_BNEP_MC_FILTER=3Dy=0A= CONFIG_BT_BNEP_PROTO_FILTER=3Dy=0A= CONFIG_BT_CMTP=3Dm=0A= =0A= #=0A= # Bluetooth device drivers=0A= #=0A= CONFIG_BT_HCIUSB=3Dm=0A= CONFIG_BT_HCIUSB_SCO=3Dy=0A= CONFIG_BT_HCIUART=3Dm=0A= CONFIG_BT_HCIUART_H4=3Dy=0A= CONFIG_BT_HCIUART_BCSP=3Dy=0A= CONFIG_BT_HCIUART_BCSP_TXCRC=3Dy=0A= CONFIG_BT_HCIBCM203X=3Dm=0A= CONFIG_BT_HCIBFUSB=3Dm=0A= CONFIG_BT_HCIDTL1=3Dm=0A= CONFIG_BT_HCIBT3C=3Dm=0A= CONFIG_BT_HCIBLUECARD=3Dm=0A= CONFIG_BT_HCIBTUART=3Dm=0A= CONFIG_BT_HCIVHCI=3Dm=0A= CONFIG_NETPOLL=3Dy=0A= CONFIG_NETPOLL_RX=3Dy=0A= CONFIG_NETPOLL_TRAP=3Dy=0A= CONFIG_NET_POLL_CONTROLLER=3Dy=0A= =0A= #=0A= # ISDN subsystem=0A= #=0A= CONFIG_ISDN=3Dm=0A= =0A= #=0A= # Old ISDN4Linux=0A= #=0A= CONFIG_ISDN_I4L=3Dm=0A= CONFIG_ISDN_PPP=3Dy=0A= CONFIG_ISDN_PPP_VJ=3Dy=0A= CONFIG_ISDN_MPP=3Dy=0A= CONFIG_IPPP_FILTER=3Dy=0A= CONFIG_ISDN_PPP_BSDCOMP=3Dm=0A= CONFIG_ISDN_AUDIO=3Dy=0A= CONFIG_ISDN_TTY_FAX=3Dy=0A= CONFIG_ISDN_X25=3Dy=0A= =0A= #=0A= # ISDN feature submodules=0A= #=0A= =0A= #=0A= # ISDN4Linux hardware drivers=0A= #=0A= =0A= #=0A= # Passive cards=0A= #=0A= CONFIG_ISDN_DRV_HISAX=3Dm=0A= =0A= #=0A= # D-channel protocol features=0A= #=0A= CONFIG_HISAX_EURO=3Dy=0A= CONFIG_DE_AOC=3Dy=0A= # CONFIG_HISAX_NO_SENDCOMPLETE is not set=0A= # CONFIG_HISAX_NO_LLC is not set=0A= # CONFIG_HISAX_NO_KEYPAD is not set=0A= CONFIG_HISAX_1TR6=3Dy=0A= CONFIG_HISAX_NI1=3Dy=0A= CONFIG_HISAX_MAX_CARDS=3D8=0A= =0A= #=0A= # HiSax supported cards=0A= #=0A= CONFIG_HISAX_16_3=3Dy=0A= CONFIG_HISAX_TELESPCI=3Dy=0A= CONFIG_HISAX_S0BOX=3Dy=0A= CONFIG_HISAX_FRITZPCI=3Dy=0A= CONFIG_HISAX_AVM_A1_PCMCIA=3Dy=0A= CONFIG_HISAX_ELSA=3Dy=0A= CONFIG_HISAX_DIEHLDIVA=3Dy=0A= CONFIG_HISAX_SEDLBAUER=3Dy=0A= CONFIG_HISAX_NETJET=3Dy=0A= CONFIG_HISAX_NETJET_U=3Dy=0A= CONFIG_HISAX_NICCY=3Dy=0A= CONFIG_HISAX_BKM_A4T=3Dy=0A= CONFIG_HISAX_SCT_QUADRO=3Dy=0A= CONFIG_HISAX_GAZEL=3Dy=0A= CONFIG_HISAX_HFC_PCI=3Dy=0A= CONFIG_HISAX_W6692=3Dy=0A= CONFIG_HISAX_HFC_SX=3Dy=0A= CONFIG_HISAX_ENTERNOW_PCI=3Dy=0A= CONFIG_HISAX_DEBUG=3Dy=0A= =0A= #=0A= # HiSax PCMCIA card service modules=0A= #=0A= CONFIG_HISAX_SEDLBAUER_CS=3Dm=0A= CONFIG_HISAX_ELSA_CS=3Dm=0A= CONFIG_HISAX_AVM_A1_CS=3Dm=0A= CONFIG_HISAX_TELES_CS=3Dm=0A= =0A= #=0A= # HiSax sub driver modules=0A= #=0A= CONFIG_HISAX_ST5481=3Dm=0A= CONFIG_HISAX_HFCUSB=3Dm=0A= CONFIG_HISAX_FRITZ_PCIPNP=3Dm=0A= CONFIG_HISAX_HDLC=3Dy=0A= =0A= #=0A= # Active cards=0A= #=0A= CONFIG_ISDN_DRV_TPAM=3Dm=0A= =0A= #=0A= # CAPI subsystem=0A= #=0A= CONFIG_ISDN_CAPI=3Dm=0A= CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=3Dy=0A= CONFIG_ISDN_CAPI_MIDDLEWARE=3Dy=0A= CONFIG_ISDN_CAPI_CAPI20=3Dm=0A= CONFIG_ISDN_CAPI_CAPIFS_BOOL=3Dy=0A= CONFIG_ISDN_CAPI_CAPIFS=3Dm=0A= CONFIG_ISDN_CAPI_CAPIDRV=3Dm=0A= =0A= #=0A= # CAPI hardware drivers=0A= #=0A= =0A= #=0A= # Active AVM cards=0A= #=0A= CONFIG_CAPI_AVM=3Dy=0A= CONFIG_ISDN_DRV_AVMB1_B1PCI=3Dm=0A= CONFIG_ISDN_DRV_AVMB1_B1PCIV4=3Dy=0A= CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=3Dm=0A= CONFIG_ISDN_DRV_AVMB1_AVM_CS=3Dm=0A= CONFIG_ISDN_DRV_AVMB1_T1PCI=3Dm=0A= CONFIG_ISDN_DRV_AVMB1_C4=3Dm=0A= =0A= #=0A= # Active Eicon DIVA Server cards=0A= #=0A= # CONFIG_CAPI_EICON is not set=0A= =0A= #=0A= # Telephony Support=0A= #=0A= CONFIG_PHONE=3Dm=0A= CONFIG_PHONE_IXJ=3Dm=0A= CONFIG_PHONE_IXJ_PCMCIA=3Dm=0A= =0A= #=0A= # Input device support=0A= #=0A= CONFIG_INPUT=3Dy=0A= =0A= #=0A= # Userland interfaces=0A= #=0A= CONFIG_INPUT_MOUSEDEV=3Dy=0A= CONFIG_INPUT_MOUSEDEV_PSAUX=3Dy=0A= CONFIG_INPUT_MOUSEDEV_SCREEN_X=3D1024=0A= CONFIG_INPUT_MOUSEDEV_SCREEN_Y=3D768=0A= CONFIG_INPUT_JOYDEV=3Dm=0A= CONFIG_INPUT_TSDEV=3Dm=0A= CONFIG_INPUT_TSDEV_SCREEN_X=3D240=0A= CONFIG_INPUT_TSDEV_SCREEN_Y=3D320=0A= CONFIG_INPUT_EVDEV=3Dm=0A= # CONFIG_INPUT_EVBUG is not set=0A= =0A= #=0A= # Input I/O drivers=0A= #=0A= CONFIG_GAMEPORT=3Dm=0A= CONFIG_SOUND_GAMEPORT=3Dm=0A= CONFIG_GAMEPORT_NS558=3Dm=0A= CONFIG_GAMEPORT_L4=3Dm=0A= CONFIG_GAMEPORT_EMU10K1=3Dm=0A= CONFIG_GAMEPORT_VORTEX=3Dm=0A= CONFIG_GAMEPORT_FM801=3Dm=0A= CONFIG_GAMEPORT_CS461x=3Dm=0A= CONFIG_SERIO=3Dy=0A= CONFIG_SERIO_I8042=3Dy=0A= CONFIG_SERIO_SERPORT=3Dm=0A= CONFIG_SERIO_CT82C710=3Dm=0A= CONFIG_SERIO_PARKBD=3Dm=0A= CONFIG_SERIO_PCIPS2=3Dm=0A= =0A= #=0A= # Input Device Drivers=0A= #=0A= CONFIG_INPUT_KEYBOARD=3Dy=0A= CONFIG_KEYBOARD_ATKBD=3Dy=0A= CONFIG_KEYBOARD_SUNKBD=3Dm=0A= # CONFIG_KEYBOARD_LKKBD is not set=0A= CONFIG_KEYBOARD_XTKBD=3Dm=0A= CONFIG_KEYBOARD_NEWTON=3Dm=0A= # CONFIG_KEYBOARD_POSFILTER is not set=0A= CONFIG_INPUT_MOUSE=3Dy=0A= CONFIG_MOUSE_PS2=3Dy=0A= CONFIG_MOUSE_SERIAL=3Dm=0A= # CONFIG_MOUSE_VSXXXAA is not set=0A= CONFIG_INPUT_JOYSTICK=3Dy=0A= CONFIG_JOYSTICK_ANALOG=3Dm=0A= CONFIG_JOYSTICK_A3D=3Dm=0A= CONFIG_JOYSTICK_ADI=3Dm=0A= CONFIG_JOYSTICK_COBRA=3Dm=0A= CONFIG_JOYSTICK_GF2K=3Dm=0A= CONFIG_JOYSTICK_GRIP=3Dm=0A= CONFIG_JOYSTICK_GRIP_MP=3Dm=0A= CONFIG_JOYSTICK_GUILLEMOT=3Dm=0A= CONFIG_JOYSTICK_INTERACT=3Dm=0A= CONFIG_JOYSTICK_SIDEWINDER=3Dm=0A= CONFIG_JOYSTICK_TMDC=3Dm=0A= CONFIG_JOYSTICK_IFORCE=3Dm=0A= CONFIG_JOYSTICK_IFORCE_USB=3Dy=0A= CONFIG_JOYSTICK_IFORCE_232=3Dy=0A= CONFIG_JOYSTICK_WARRIOR=3Dm=0A= CONFIG_JOYSTICK_MAGELLAN=3Dm=0A= CONFIG_JOYSTICK_SPACEORB=3Dm=0A= CONFIG_JOYSTICK_SPACEBALL=3Dm=0A= CONFIG_JOYSTICK_STINGER=3Dm=0A= CONFIG_JOYSTICK_TWIDDLER=3Dm=0A= CONFIG_JOYSTICK_DB9=3Dm=0A= CONFIG_JOYSTICK_GAMECON=3Dm=0A= CONFIG_JOYSTICK_TURBOGRAFX=3Dm=0A= # CONFIG_INPUT_JOYDUMP is not set=0A= CONFIG_INPUT_TOUCHSCREEN=3Dy=0A= CONFIG_TOUCHSCREEN_GUNZE=3Dm=0A= CONFIG_INPUT_MISC=3Dy=0A= CONFIG_INPUT_PCSPKR=3Dy=0A= CONFIG_INPUT_UINPUT=3Dm=0A= =0A= #=0A= # Character devices=0A= #=0A= CONFIG_VT=3Dy=0A= CONFIG_VT_CONSOLE=3Dy=0A= CONFIG_HW_CONSOLE=3Dy=0A= # CONFIG_ECC is not set=0A= CONFIG_SERIAL_NONSTANDARD=3Dy=0A= CONFIG_ROCKETPORT=3Dm=0A= CONFIG_SYNCLINK=3Dm=0A= CONFIG_SYNCLINKMP=3Dm=0A= CONFIG_N_HDLC=3Dm=0A= CONFIG_STALDRV=3Dy=0A= =0A= #=0A= # Serial drivers=0A= #=0A= CONFIG_SERIAL_8250=3Dy=0A= CONFIG_SERIAL_8250_CONSOLE=3Dy=0A= CONFIG_SERIAL_8250_CS=3Dm=0A= # CONFIG_SERIAL_8250_ACPI is not set=0A= CONFIG_SERIAL_8250_NR_UARTS=3D4=0A= # CONFIG_SERIAL_8250_EXTENDED is not set=0A= =0A= #=0A= # Non-8250 serial port support=0A= #=0A= CONFIG_SERIAL_CORE=3Dy=0A= CONFIG_SERIAL_CORE_CONSOLE=3Dy=0A= # CONFIG_SERIAL_ICOM is not set=0A= CONFIG_SERIAL_JSM=3Dm=0A= CONFIG_UNIX98_PTYS=3Dy=0A= CONFIG_LEGACY_PTYS=3Dy=0A= CONFIG_LEGACY_PTY_COUNT=3D256=0A= CONFIG_PRINTER=3Dm=0A= # CONFIG_LP_CONSOLE is not set=0A= CONFIG_PPDEV=3Dm=0A= CONFIG_TIPAR=3Dm=0A= CONFIG_QIC02_TAPE=3Dm=0A= CONFIG_QIC02_DYNCONF=3Dy=0A= =0A= #=0A= # Setting runtime QIC-02 configuration is done with qic02conf=0A= #=0A= =0A= #=0A= # from the tpqic02-support package. It is available at=0A= #=0A= =0A= #=0A= # metalab.unc.edu or ftp://titus.cfw.com/pub/Linux/util/=0A= #=0A= =0A= #=0A= # IPMI=0A= #=0A= CONFIG_IPMI_HANDLER=3Dm=0A= CONFIG_IPMI_PANIC_EVENT=3Dy=0A= # CONFIG_IPMI_PANIC_STRING is not set=0A= CONFIG_IPMI_DEVICE_INTERFACE=3Dm=0A= CONFIG_IPMI_KCS=3Dm=0A= CONFIG_IPMI_WATCHDOG=3Dm=0A= =0A= #=0A= # Watchdog Cards=0A= #=0A= CONFIG_WATCHDOG=3Dy=0A= # CONFIG_WATCHDOG_NOWAYOUT is not set=0A= =0A= #=0A= # Watchdog Device Drivers=0A= #=0A= CONFIG_SOFT_WATCHDOG=3Dm=0A= CONFIG_ACQUIRE_WDT=3Dm=0A= CONFIG_ADVANTECH_WDT=3Dm=0A= CONFIG_ALIM1535_WDT=3Dm=0A= CONFIG_ALIM7101_WDT=3Dm=0A= CONFIG_AMD7XX_TCO=3Dm=0A= CONFIG_SC520_WDT=3Dm=0A= CONFIG_EUROTECH_WDT=3Dm=0A= CONFIG_IB700_WDT=3Dm=0A= CONFIG_WAFER_WDT=3Dm=0A= CONFIG_I8XX_TCO=3Dm=0A= CONFIG_SC1200_WDT=3Dm=0A= CONFIG_SCx200_WDT=3Dm=0A= CONFIG_60XX_WDT=3Dm=0A= CONFIG_CPU5_WDT=3Dm=0A= CONFIG_W83627HF_WDT=3Dm=0A= CONFIG_W83877F_WDT=3Dm=0A= CONFIG_MACHZ_WDT=3Dm=0A= =0A= #=0A= # PCI-based Watchdog Cards=0A= #=0A= CONFIG_PCIPCWATCHDOG=3Dm=0A= CONFIG_WDTPCI=3Dm=0A= CONFIG_WDT_501_PCI=3Dy=0A= =0A= #=0A= # USB-based Watchdog Cards=0A= #=0A= CONFIG_USBPCWATCHDOG=3Dm=0A= CONFIG_HW_RANDOM=3Dm=0A= CONFIG_NVRAM=3Dy=0A= CONFIG_RTC=3Dy=0A= CONFIG_DTLK=3Dm=0A= CONFIG_R3964=3Dm=0A= CONFIG_APPLICOM=3Dm=0A= =0A= #=0A= # Ftape, the floppy tape device driver=0A= #=0A= CONFIG_AGP=3Dy=0A= CONFIG_AGP_AMD64=3Dy=0A= CONFIG_AGP_INTEL_MCH=3Dm=0A= # CONFIG_DRM is not set=0A= =0A= #=0A= # PCMCIA character devices=0A= #=0A= CONFIG_SYNCLINK_CS=3Dm=0A= # CONFIG_MWAVE is not set=0A= CONFIG_RAW_DRIVER=3Dm=0A= CONFIG_MAX_RAW_DEVS=3D4096=0A= CONFIG_HANGCHECK_TIMER=3Dm=0A= # CONFIG_VTUNE is not set=0A= =0A= #=0A= # Linux InfraRed Controller=0A= #=0A= CONFIG_LIRC_SUPPORT=3Dm=0A= CONFIG_LIRC_MAX_DEV=3D2=0A= CONFIG_LIRC_BT829=3Dm=0A= CONFIG_LIRC_IT87=3Dm=0A= CONFIG_LIRC_ATIUSB=3Dm=0A= CONFIG_LIRC_SERIAL=3Dm=0A= # CONFIG_LIRC_HOMEBREW is not set=0A= CONFIG_LIRC_PORT_SERIAL=3D0x3f8=0A= CONFIG_LIRC_IRQ_SERIAL=3D4=0A= CONFIG_LIRC_SIR=3Dm=0A= CONFIG_LIRC_PORT_SIR=3D0x3f8=0A= CONFIG_LIRC_IRQ_SIR=3D4=0A= =0A= #=0A= # I2C support=0A= #=0A= CONFIG_I2C=3Dm=0A= CONFIG_I2C_CHARDEV=3Dm=0A= =0A= #=0A= # I2C Algorithms=0A= #=0A= CONFIG_I2C_ALGOBIT=3Dm=0A= CONFIG_I2C_ALGOPCF=3Dm=0A= =0A= #=0A= # I2C Hardware Bus support=0A= #=0A= CONFIG_I2C_ALI1535=3Dm=0A= CONFIG_I2C_ALI15X3=3Dm=0A= CONFIG_I2C_AMD756=3Dm=0A= CONFIG_I2C_AMD8111=3Dm=0A= CONFIG_I2C_I801=3Dm=0A= CONFIG_I2C_I810=3Dm=0A= CONFIG_I2C_ISA=3Dm=0A= CONFIG_I2C_NFORCE2=3Dm=0A= CONFIG_I2C_PARPORT=3Dm=0A= CONFIG_I2C_PARPORT_LIGHT=3Dm=0A= CONFIG_I2C_PROSAVAGE=3Dm=0A= CONFIG_I2C_SAVAGE4=3Dm=0A= CONFIG_SCx200_ACB=3Dm=0A= CONFIG_I2C_SIS5595=3Dm=0A= CONFIG_I2C_SIS630=3Dm=0A= CONFIG_I2C_SIS96X=3Dm=0A= CONFIG_I2C_VIA=3Dm=0A= CONFIG_I2C_VIAPRO=3Dm=0A= CONFIG_I2C_VOODOO3=3Dm=0A= =0A= #=0A= # Hardware Sensors Chip support=0A= #=0A= CONFIG_I2C_SENSOR=3Dm=0A= CONFIG_SENSORS_ADM1021=3Dm=0A= CONFIG_SENSORS_ASB100=3Dm=0A= CONFIG_SENSORS_DS1621=3Dm=0A= CONFIG_SENSORS_FSCHER=3Dm=0A= CONFIG_SENSORS_GL518SM=3Dm=0A= CONFIG_SENSORS_IT87=3Dm=0A= CONFIG_SENSORS_LM75=3Dm=0A= CONFIG_SENSORS_LM78=3Dm=0A= CONFIG_SENSORS_LM80=3Dm=0A= CONFIG_SENSORS_LM83=3Dm=0A= CONFIG_SENSORS_LM85=3Dm=0A= CONFIG_SENSORS_LM90=3Dm=0A= CONFIG_SENSORS_VIA686A=3Dm=0A= CONFIG_SENSORS_W83781D=3Dm=0A= CONFIG_SENSORS_W83L785TS=3Dm=0A= CONFIG_SENSORS_W83627HF=3Dm=0A= =0A= #=0A= # Other I2C Chip support=0A= #=0A= CONFIG_SENSORS_EEPROM=3Dm=0A= # CONFIG_I2C_DEBUG_CORE is not set=0A= # CONFIG_I2C_DEBUG_ALGO is not set=0A= # CONFIG_I2C_DEBUG_BUS is not set=0A= # CONFIG_I2C_DEBUG_CHIP is not set=0A= =0A= #=0A= # Misc devices=0A= #=0A= CONFIG_IBM_ASM=3Dm=0A= =0A= #=0A= # Multimedia devices=0A= #=0A= CONFIG_VIDEO_DEV=3Dm=0A= =0A= #=0A= # Video For Linux=0A= #=0A= =0A= #=0A= # Video Adapters=0A= #=0A= CONFIG_VIDEO_BT848=3Dm=0A= CONFIG_VIDEO_BWQCAM=3Dm=0A= CONFIG_VIDEO_CQCAM=3Dm=0A= CONFIG_VIDEO_W9966=3Dm=0A= CONFIG_VIDEO_CPIA=3Dm=0A= CONFIG_VIDEO_CPIA_PP=3Dm=0A= CONFIG_VIDEO_CPIA_USB=3Dm=0A= CONFIG_VIDEO_SAA5246A=3Dm=0A= CONFIG_VIDEO_SAA5249=3Dm=0A= CONFIG_TUNER_3036=3Dm=0A= CONFIG_VIDEO_STRADIS=3Dm=0A= CONFIG_VIDEO_ZORAN=3Dm=0A= CONFIG_VIDEO_ZORAN_BUZ=3Dm=0A= CONFIG_VIDEO_ZORAN_DC10=3Dm=0A= CONFIG_VIDEO_ZORAN_DC30=3Dm=0A= CONFIG_VIDEO_ZORAN_LML33=3Dm=0A= CONFIG_VIDEO_ZORAN_LML33R10=3Dm=0A= CONFIG_VIDEO_SAA7134=3Dm=0A= CONFIG_VIDEO_MXB=3Dm=0A= CONFIG_VIDEO_DPC=3Dm=0A= CONFIG_VIDEO_HEXIUM_ORION=3Dm=0A= CONFIG_VIDEO_HEXIUM_GEMINI=3Dm=0A= CONFIG_VIDEO_CX88=3Dm=0A= =0A= #=0A= # Radio Adapters=0A= #=0A= CONFIG_RADIO_GEMTEK_PCI=3Dm=0A= CONFIG_RADIO_MAXIRADIO=3Dm=0A= CONFIG_RADIO_MAESTRO=3Dm=0A= =0A= #=0A= # Digital Video Broadcasting Devices=0A= #=0A= CONFIG_DVB=3Dy=0A= CONFIG_DVB_CORE=3Dm=0A= =0A= #=0A= # Supported Frontend Modules=0A= #=0A= CONFIG_DVB_TWINHAN_DST=3Dm=0A= CONFIG_DVB_STV0299=3Dm=0A= CONFIG_DVB_SP887X=3Dm=0A= CONFIG_DVB_SP887X_FIRMWARE_FILE=3D"/etc/dvb/sc_main.mc"=0A= CONFIG_DVB_ALPS_TDLB7=3Dm=0A= CONFIG_DVB_ALPS_TDMB7=3Dm=0A= CONFIG_DVB_ATMEL_AT76C651=3Dm=0A= CONFIG_DVB_CX24110=3Dm=0A= CONFIG_DVB_GRUNDIG_29504_491=3Dm=0A= CONFIG_DVB_GRUNDIG_29504_401=3Dm=0A= CONFIG_DVB_MT312=3Dm=0A= CONFIG_DVB_VES1820=3Dm=0A= CONFIG_DVB_VES1X93=3Dm=0A= CONFIG_DVB_TDA1004X=3Dm=0A= CONFIG_DVB_TDA1004X_FIRMWARE_FILE=3D"/usr/lib/hotplug/firmware/tda1004x.b= in"=0A= CONFIG_DVB_NXT6000=3Dm=0A= =0A= #=0A= # Supported SAA7146 based PCI Adapters=0A= #=0A= CONFIG_DVB_AV7110=3Dm=0A= # CONFIG_DVB_AV7110_FIRMWARE is not set=0A= # CONFIG_DVB_AV7110_OSD is not set=0A= CONFIG_DVB_BUDGET=3Dm=0A= CONFIG_DVB_BUDGET_CI=3Dm=0A= CONFIG_DVB_BUDGET_AV=3Dm=0A= CONFIG_DVB_BUDGET_PATCH=3Dm=0A= =0A= #=0A= # Supported USB Adapters=0A= #=0A= CONFIG_DVB_TTUSB_BUDGET=3Dm=0A= CONFIG_DVB_TTUSB_DEC=3Dm=0A= =0A= #=0A= # Supported FlexCopII (B2C2) Adapters=0A= #=0A= CONFIG_DVB_B2C2_SKYSTAR=3Dm=0A= =0A= #=0A= # Supported BT878 Adapters=0A= #=0A= CONFIG_DVB_BT8XX=3Dm=0A= CONFIG_VIDEO_SAA7146=3Dm=0A= CONFIG_VIDEO_SAA7146_VV=3Dm=0A= CONFIG_VIDEO_VIDEOBUF=3Dm=0A= CONFIG_VIDEO_TUNER=3Dm=0A= CONFIG_VIDEO_BUF=3Dm=0A= CONFIG_VIDEO_BTCX=3Dm=0A= CONFIG_VIDEO_IR=3Dm=0A= =0A= #=0A= # Graphics support=0A= #=0A= CONFIG_FB=3Dy=0A= # CONFIG_FB_PM2 is not set=0A= CONFIG_FB_CYBER2000=3Dm=0A= # CONFIG_FB_IMSTT is not set=0A= CONFIG_FB_VGA16=3Dm=0A= CONFIG_FB_VESA=3Dy=0A= CONFIG_VIDEO_SELECT=3Dy=0A= CONFIG_FB_HGA=3Dm=0A= CONFIG_FB_RIVA=3Dm=0A= CONFIG_FB_MATROX=3Dm=0A= CONFIG_FB_MATROX_MILLENIUM=3Dy=0A= CONFIG_FB_MATROX_MYSTIQUE=3Dy=0A= CONFIG_FB_MATROX_G450=3Dy=0A= CONFIG_FB_MATROX_G100=3Dy=0A= CONFIG_FB_MATROX_I2C=3Dm=0A= CONFIG_FB_MATROX_MAVEN=3Dm=0A= CONFIG_FB_MATROX_MULTIHEAD=3Dy=0A= # CONFIG_FB_RADEON_OLD is not set=0A= CONFIG_FB_RADEON=3Dm=0A= CONFIG_FB_RADEON_I2C=3Dy=0A= # CONFIG_FB_RADEON_DEBUG is not set=0A= CONFIG_FB_ATY128=3Dm=0A= CONFIG_FB_ATY=3Dm=0A= CONFIG_FB_ATY_CT=3Dy=0A= CONFIG_FB_ATY_GX=3Dy=0A= CONFIG_FB_ATY_XL_INIT=3Dy=0A= CONFIG_FB_SIS=3Dm=0A= CONFIG_FB_SIS_300=3Dy=0A= CONFIG_FB_SIS_315=3Dy=0A= CONFIG_FB_NEOMAGIC=3Dm=0A= CONFIG_FB_KYRO=3Dm=0A= CONFIG_FB_3DFX=3Dm=0A= CONFIG_FB_VOODOO1=3Dm=0A= CONFIG_FB_TRIDENT=3Dm=0A= CONFIG_FB_VIRTUAL=3Dm=0A= =0A= #=0A= # Console display driver support=0A= #=0A= CONFIG_VGA_CONSOLE=3Dy=0A= CONFIG_MDA_CONSOLE=3Dm=0A= CONFIG_DUMMY_CONSOLE=3Dy=0A= CONFIG_FRAMEBUFFER_CONSOLE=3Dy=0A= CONFIG_PCI_CONSOLE=3Dy=0A= # CONFIG_FONTS is not set=0A= CONFIG_FONT_8x8=3Dy=0A= CONFIG_FONT_8x16=3Dy=0A= =0A= #=0A= # Logo configuration=0A= #=0A= # CONFIG_LOGO is not set=0A= =0A= #=0A= # Bootsplash configuration=0A= #=0A= CONFIG_BOOTSPLASH=3Dy=0A= =0A= #=0A= # Sound=0A= #=0A= CONFIG_SOUND=3Dm=0A= =0A= #=0A= # Advanced Linux Sound Architecture=0A= #=0A= CONFIG_SND=3Dm=0A= CONFIG_SND_BIT32_EMUL=3Dm=0A= CONFIG_SND_TIMER=3Dm=0A= CONFIG_SND_PCM=3Dm=0A= CONFIG_SND_HWDEP=3Dm=0A= CONFIG_SND_RAWMIDI=3Dm=0A= CONFIG_SND_SEQUENCER=3Dm=0A= CONFIG_SND_SEQ_DUMMY=3Dm=0A= CONFIG_SND_OSSEMUL=3Dy=0A= CONFIG_SND_MIXER_OSS=3Dm=0A= CONFIG_SND_PCM_OSS=3Dm=0A= CONFIG_SND_SEQUENCER_OSS=3Dy=0A= CONFIG_SND_RTCTIMER=3Dm=0A= CONFIG_SND_VERBOSE_PRINTK=3Dy=0A= CONFIG_SND_DEBUG=3Dy=0A= CONFIG_SND_DEBUG_MEMORY=3Dy=0A= # CONFIG_SND_DEBUG_DETECT is not set=0A= =0A= #=0A= # Generic devices=0A= #=0A= CONFIG_SND_MPU401_UART=3Dm=0A= CONFIG_SND_OPL3_LIB=3Dm=0A= CONFIG_SND_VX_LIB=3Dm=0A= CONFIG_SND_DUMMY=3Dm=0A= CONFIG_SND_VIRMIDI=3Dm=0A= CONFIG_SND_MTPAV=3Dm=0A= CONFIG_SND_SERIAL_U16550=3Dm=0A= CONFIG_SND_MPU401=3Dm=0A= =0A= #=0A= # PCI devices=0A= #=0A= CONFIG_SND_AC97_CODEC=3Dm=0A= CONFIG_SND_ALI5451=3Dm=0A= CONFIG_SND_ATIIXP=3Dm=0A= CONFIG_SND_AU8810=3Dm=0A= CONFIG_SND_AU8820=3Dm=0A= CONFIG_SND_AU8830=3Dm=0A= CONFIG_SND_AZT3328=3Dm=0A= CONFIG_SND_BT87X=3Dm=0A= CONFIG_SND_CS46XX=3Dm=0A= CONFIG_SND_CS46XX_NEW_DSP=3Dy=0A= CONFIG_SND_CS4281=3Dm=0A= CONFIG_SND_EMU10K1=3Dm=0A= CONFIG_SND_KORG1212=3Dm=0A= CONFIG_SND_MIXART=3Dm=0A= CONFIG_SND_NM256=3Dm=0A= CONFIG_SND_RME32=3Dm=0A= CONFIG_SND_RME96=3Dm=0A= CONFIG_SND_RME9652=3Dm=0A= CONFIG_SND_HDSP=3Dm=0A= CONFIG_SND_TRIDENT=3Dm=0A= CONFIG_SND_YMFPCI=3Dm=0A= CONFIG_SND_ALS4000=3Dm=0A= CONFIG_SND_CMIPCI=3Dm=0A= CONFIG_SND_ENS1370=3Dm=0A= CONFIG_SND_ENS1371=3Dm=0A= CONFIG_SND_ES1938=3Dm=0A= CONFIG_SND_ES1968=3Dm=0A= CONFIG_SND_MAESTRO3=3Dm=0A= CONFIG_SND_FM801=3Dm=0A= CONFIG_SND_FM801_TEA575X=3Dm=0A= CONFIG_SND_ICE1712=3Dm=0A= CONFIG_SND_ICE1724=3Dm=0A= CONFIG_SND_INTEL8X0=3Dm=0A= CONFIG_SND_INTEL8X0M=3Dm=0A= CONFIG_SND_SONICVIBES=3Dm=0A= CONFIG_SND_VIA82XX=3Dm=0A= CONFIG_SND_VX222=3Dm=0A= =0A= #=0A= # ALSA USB devices=0A= #=0A= CONFIG_SND_USB_AUDIO=3Dm=0A= =0A= #=0A= # PCMCIA devices=0A= #=0A= =0A= #=0A= # Open Sound System=0A= #=0A= CONFIG_SOUND_PRIME=3Dm=0A= CONFIG_SOUND_BT878=3Dm=0A= CONFIG_SOUND_CMPCI=3Dm=0A= CONFIG_SOUND_CMPCI_FM=3Dy=0A= CONFIG_SOUND_CMPCI_FMIO=3D0x388=0A= CONFIG_SOUND_CMPCI_MIDI=3Dy=0A= CONFIG_SOUND_CMPCI_MPUIO=3D0x330=0A= CONFIG_SOUND_CMPCI_JOYSTICK=3Dy=0A= CONFIG_SOUND_CMPCI_CM8738=3Dy=0A= # CONFIG_SOUND_CMPCI_SPDIFINVERSE is not set=0A= CONFIG_SOUND_CMPCI_SPDIFLOOP=3Dy=0A= CONFIG_SOUND_CMPCI_SPEAKERS=3D2=0A= CONFIG_SOUND_EMU10K1=3Dm=0A= CONFIG_MIDI_EMU10K1=3Dy=0A= # CONFIG_SOUND_FUSION is not set=0A= CONFIG_SOUND_CS4281=3Dm=0A= CONFIG_SOUND_ES1370=3Dm=0A= CONFIG_SOUND_ES1371=3Dm=0A= CONFIG_SOUND_ESSSOLO1=3Dm=0A= CONFIG_SOUND_MAESTRO=3Dm=0A= CONFIG_SOUND_MAESTRO3=3Dm=0A= CONFIG_SOUND_ICH=3Dm=0A= CONFIG_SOUND_SONICVIBES=3Dm=0A= CONFIG_SOUND_TRIDENT=3Dm=0A= # CONFIG_SOUND_MSNDCLAS is not set=0A= # CONFIG_SOUND_MSNDPIN is not set=0A= CONFIG_SOUND_VIA82CXXX=3Dm=0A= CONFIG_MIDI_VIA82CXXX=3Dy=0A= CONFIG_SOUND_OSS=3Dm=0A= CONFIG_SOUND_TRACEINIT=3Dy=0A= CONFIG_SOUND_DMAP=3Dy=0A= CONFIG_SOUND_AD1816=3Dm=0A= CONFIG_SOUND_AD1889=3Dm=0A= CONFIG_SOUND_SGALAXY=3Dm=0A= CONFIG_SOUND_ADLIB=3Dm=0A= CONFIG_SOUND_ACI_MIXER=3Dm=0A= CONFIG_SOUND_CS4232=3Dm=0A= CONFIG_SOUND_SSCAPE=3Dm=0A= CONFIG_SOUND_GUS=3Dm=0A= # CONFIG_SOUND_GUS16 is not set=0A= CONFIG_SOUND_GUSMAX=3Dy=0A= CONFIG_SOUND_VMIDI=3Dm=0A= CONFIG_SOUND_TRIX=3Dm=0A= CONFIG_SOUND_MSS=3Dm=0A= CONFIG_SOUND_MPU401=3Dm=0A= CONFIG_SOUND_NM256=3Dm=0A= CONFIG_SOUND_MAD16=3Dm=0A= CONFIG_MAD16_OLDCARD=3Dy=0A= CONFIG_SOUND_PAS=3Dm=0A= CONFIG_SOUND_PSS=3Dm=0A= CONFIG_PSS_MIXER=3Dy=0A= # CONFIG_PSS_HAVE_BOOT is not set=0A= CONFIG_SOUND_SB=3Dm=0A= CONFIG_SOUND_AWE32_SYNTH=3Dm=0A= CONFIG_SOUND_WAVEFRONT=3Dm=0A= CONFIG_SOUND_MAUI=3Dm=0A= CONFIG_SOUND_YM3812=3Dm=0A= CONFIG_SOUND_OPL3SA1=3Dm=0A= CONFIG_SOUND_OPL3SA2=3Dm=0A= CONFIG_SOUND_YMFPCI=3Dm=0A= CONFIG_SOUND_YMFPCI_LEGACY=3Dy=0A= CONFIG_SOUND_UART6850=3Dm=0A= CONFIG_SOUND_AEDSP16=3Dm=0A= CONFIG_SC6600=3Dy=0A= CONFIG_SC6600_JOY=3Dy=0A= CONFIG_SC6600_CDROM=3D4=0A= CONFIG_SC6600_CDROMBASE=3D0x0=0A= # CONFIG_AEDSP16_MSS is not set=0A= # CONFIG_AEDSP16_SBPRO is not set=0A= CONFIG_AEDSP16_MPU401=3Dy=0A= CONFIG_SOUND_TVMIXER=3Dm=0A= CONFIG_SOUND_KAHLUA=3Dm=0A= CONFIG_SOUND_ALI5455=3Dm=0A= CONFIG_SOUND_FORTE=3Dm=0A= CONFIG_SOUND_RME96XX=3Dm=0A= CONFIG_SOUND_AD1980=3Dm=0A= =0A= #=0A= # USB support=0A= #=0A= CONFIG_USB=3Dm=0A= # CONFIG_USB_DEBUG is not set=0A= =0A= #=0A= # Miscellaneous USB options=0A= #=0A= CONFIG_USB_DEVICEFS=3Dy=0A= # CONFIG_USB_BANDWIDTH is not set=0A= # CONFIG_USB_DYNAMIC_MINORS is not set=0A= =0A= #=0A= # USB Host Controller Drivers=0A= #=0A= CONFIG_USB_EHCI_HCD=3Dm=0A= CONFIG_USB_EHCI_SPLIT_ISO=3Dy=0A= CONFIG_USB_EHCI_ROOT_HUB_TT=3Dy=0A= CONFIG_USB_OHCI_HCD=3Dm=0A= CONFIG_USB_UHCI_HCD=3Dm=0A= =0A= #=0A= # USB Device Class drivers=0A= #=0A= CONFIG_USB_AUDIO=3Dm=0A= =0A= #=0A= # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem=0A= #=0A= CONFIG_USB_MIDI=3Dm=0A= CONFIG_USB_ACM=3Dm=0A= CONFIG_USB_PRINTER=3Dm=0A= CONFIG_USB_STORAGE=3Dm=0A= # CONFIG_USB_STORAGE_DEBUG is not set=0A= CONFIG_USB_STORAGE_DATAFAB=3Dy=0A= CONFIG_USB_STORAGE_FREECOM=3Dy=0A= CONFIG_USB_STORAGE_ISD200=3Dy=0A= CONFIG_USB_STORAGE_DPCM=3Dy=0A= CONFIG_USB_STORAGE_HP8200e=3Dy=0A= CONFIG_USB_STORAGE_SDDR09=3Dy=0A= CONFIG_USB_STORAGE_SDDR55=3Dy=0A= CONFIG_USB_STORAGE_JUMPSHOT=3Dy=0A= =0A= #=0A= # USB Human Interface Devices (HID)=0A= #=0A= CONFIG_USB_HID=3Dm=0A= CONFIG_USB_HIDINPUT=3Dy=0A= CONFIG_HID_FF=3Dy=0A= CONFIG_HID_PID=3Dy=0A= CONFIG_LOGITECH_FF=3Dy=0A= CONFIG_THRUSTMASTER_FF=3Dy=0A= CONFIG_USB_HIDDEV=3Dy=0A= =0A= #=0A= # USB HID Boot Protocol drivers=0A= #=0A= # CONFIG_USB_KBD is not set=0A= # CONFIG_USB_MOUSE is not set=0A= CONFIG_USB_AIPTEK=3Dm=0A= CONFIG_USB_WACOM=3Dm=0A= CONFIG_USB_KBTAB=3Dm=0A= CONFIG_USB_POWERMATE=3Dm=0A= CONFIG_USB_MTOUCH=3Dm=0A= CONFIG_USB_XPAD=3Dm=0A= CONFIG_USB_ATI_REMOTE=3Dm=0A= =0A= #=0A= # USB Imaging devices=0A= #=0A= CONFIG_USB_MDC800=3Dm=0A= CONFIG_USB_MICROTEK=3Dm=0A= CONFIG_USB_HPUSBSCSI=3Dm=0A= =0A= #=0A= # USB Multimedia devices=0A= #=0A= CONFIG_USB_DABUSB=3Dm=0A= CONFIG_USB_VICAM=3Dm=0A= CONFIG_USB_DSBR=3Dm=0A= CONFIG_USB_IBMCAM=3Dm=0A= CONFIG_USB_KONICAWC=3Dm=0A= CONFIG_USB_OV511=3Dm=0A= CONFIG_USB_SE401=3Dm=0A= CONFIG_USB_STV680=3Dm=0A= CONFIG_USB_W9968CF=3Dm=0A= =0A= #=0A= # USB Network adaptors=0A= #=0A= CONFIG_USB_CATC=3Dm=0A= CONFIG_USB_KAWETH=3Dm=0A= CONFIG_USB_PEGASUS=3Dm=0A= CONFIG_USB_RTL8150=3Dm=0A= CONFIG_USB_USBNET=3Dm=0A= =0A= #=0A= # USB Host-to-Host Cables=0A= #=0A= CONFIG_USB_ALI_M5632=3Dy=0A= CONFIG_USB_AN2720=3Dy=0A= CONFIG_USB_BELKIN=3Dy=0A= CONFIG_USB_GENESYS=3Dy=0A= CONFIG_USB_NET1080=3Dy=0A= CONFIG_USB_PL2301=3Dy=0A= =0A= #=0A= # Intelligent USB Devices/Gadgets=0A= #=0A= CONFIG_USB_ARMLINUX=3Dy=0A= CONFIG_USB_EPSON2888=3Dy=0A= CONFIG_USB_ZAURUS=3Dy=0A= CONFIG_USB_CDCETHER=3Dy=0A= =0A= #=0A= # USB Network Adapters=0A= #=0A= CONFIG_USB_AX8817X=3Dy=0A= =0A= #=0A= # USB port drivers=0A= #=0A= CONFIG_USB_USS720=3Dm=0A= =0A= #=0A= # USB Serial Converter support=0A= #=0A= CONFIG_USB_SERIAL=3Dm=0A= CONFIG_USB_SERIAL_GENERIC=3Dy=0A= CONFIG_USB_SERIAL_BELKIN=3Dm=0A= CONFIG_USB_SERIAL_DIGI_ACCELEPORT=3Dm=0A= CONFIG_USB_SERIAL_EMPEG=3Dm=0A= CONFIG_USB_SERIAL_FTDI_SIO=3Dm=0A= CONFIG_USB_SERIAL_VISOR=3Dm=0A= CONFIG_USB_SERIAL_IPAQ=3Dm=0A= CONFIG_USB_SERIAL_IR=3Dm=0A= CONFIG_USB_SERIAL_EDGEPORT=3Dm=0A= CONFIG_USB_SERIAL_EDGEPORT_TI=3Dm=0A= CONFIG_USB_SERIAL_KEYSPAN_PDA=3Dm=0A= CONFIG_USB_SERIAL_KEYSPAN=3Dm=0A= CONFIG_USB_SERIAL_KEYSPAN_MPR=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA28=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA28X=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA28XA=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA28XB=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA19=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA18X=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA19W=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA19QW=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA19QI=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA49W=3Dy=0A= CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=3Dy=0A= CONFIG_USB_SERIAL_KLSI=3Dm=0A= CONFIG_USB_SERIAL_KOBIL_SCT=3Dm=0A= CONFIG_USB_SERIAL_MCT_U232=3Dm=0A= CONFIG_USB_SERIAL_PL2303=3Dm=0A= CONFIG_USB_SERIAL_SAFE=3Dm=0A= CONFIG_USB_SERIAL_SAFE_PADDED=3Dy=0A= CONFIG_USB_SERIAL_CYBERJACK=3Dm=0A= CONFIG_USB_SERIAL_XIRCOM=3Dm=0A= CONFIG_USB_SERIAL_OMNINET=3Dm=0A= CONFIG_USB_EZUSB=3Dy=0A= =0A= #=0A= # USB Miscellaneous drivers=0A= #=0A= CONFIG_USB_EMI62=3Dm=0A= CONFIG_USB_EMI26=3Dm=0A= CONFIG_USB_TIGL=3Dm=0A= CONFIG_USB_AUERSWALD=3Dm=0A= CONFIG_USB_RIO500=3Dm=0A= CONFIG_USB_LEGOTOWER=3Dm=0A= CONFIG_USB_LCD=3Dm=0A= CONFIG_USB_LED=3Dm=0A= CONFIG_USB_CYTHERM=3Dm=0A= # CONFIG_USB_TEST is not set=0A= =0A= #=0A= # USB Gadget Support=0A= #=0A= # CONFIG_USB_GADGET is not set=0A= =0A= #=0A= # InfiniBand support=0A= #=0A= CONFIG_INFINIBAND=3Dm=0A= CONFIG_INFINIBAND_IPOIB=3Dm=0A= # CONFIG_INFINIBAND_SDP is not set=0A= CONFIG_INFINIBAND_SRP=3Dm=0A= CONFIG_INFINIBAND_UDAPL_HELPER=3Dm=0A= CONFIG_INFINIBAND_MELLANOX_HCA=3Dm=0A= CONFIG_AUDIT=3Dm=0A= =0A= #=0A= # File systems=0A= #=0A= CONFIG_EXT2_FS=3Dy=0A= CONFIG_EXT2_FS_XATTR=3Dy=0A= CONFIG_EXT2_FS_POSIX_ACL=3Dy=0A= CONFIG_EXT2_FS_SECURITY=3Dy=0A= CONFIG_EXT3_FS=3Dm=0A= CONFIG_EXT3_FS_XATTR=3Dy=0A= CONFIG_EXT3_FS_POSIX_ACL=3Dy=0A= CONFIG_EXT3_FS_SECURITY=3Dy=0A= CONFIG_JBD=3Dm=0A= CONFIG_JBD_DEBUG=3Dy=0A= CONFIG_FS_MBCACHE=3Dy=0A= CONFIG_REISERFS_FS=3Dm=0A= # CONFIG_REISERFS_CHECK is not set=0A= # CONFIG_REISERFS_PROC_INFO is not set=0A= CONFIG_REISERFS_FS_XATTR=3Dy=0A= CONFIG_REISERFS_FS_POSIX_ACL=3Dy=0A= CONFIG_REISERFS_FS_SECURITY=3Dy=0A= CONFIG_JFS_FS=3Dm=0A= CONFIG_JFS_POSIX_ACL=3Dy=0A= CONFIG_JFS_DMAPI=3Dy=0A= # CONFIG_JFS_DEBUG is not set=0A= CONFIG_JFS_STATISTICS=3Dy=0A= CONFIG_FS_POSIX_ACL=3Dy=0A= CONFIG_XFS_FS=3Dm=0A= CONFIG_XFS_RT=3Dy=0A= CONFIG_XFS_QUOTA=3Dm=0A= CONFIG_XFS_DMAPI=3Dy=0A= CONFIG_XFS_SECURITY=3Dy=0A= CONFIG_XFS_POSIX_ACL=3Dy=0A= CONFIG_MINIX_FS=3Dy=0A= CONFIG_ROMFS_FS=3Dm=0A= CONFIG_DMAPI=3Dm=0A= # CONFIG_DMAPI_DEBUG is not set=0A= CONFIG_QUOTA=3Dy=0A= CONFIG_QFMT_V1=3Dm=0A= CONFIG_QFMT_V2=3Dm=0A= CONFIG_QUOTACTL=3Dy=0A= CONFIG_AUTOFS_FS=3Dm=0A= CONFIG_AUTOFS4_FS=3Dm=0A= =0A= #=0A= # CD-ROM/DVD Filesystems=0A= #=0A= CONFIG_ISO9660_FS=3Dy=0A= CONFIG_JOLIET=3Dy=0A= CONFIG_ZISOFS=3Dy=0A= CONFIG_ZISOFS_FS=3Dy=0A= CONFIG_UDF_FS=3Dm=0A= =0A= #=0A= # DOS/FAT/NT Filesystems=0A= #=0A= CONFIG_FAT_FS=3Dm=0A= CONFIG_MSDOS_FS=3Dm=0A= CONFIG_VFAT_FS=3Dm=0A= CONFIG_NTFS_FS=3Dm=0A= # CONFIG_NTFS_DEBUG is not set=0A= # CONFIG_NTFS_RW is not set=0A= =0A= #=0A= # Pseudo filesystems=0A= #=0A= CONFIG_PROC_FS=3Dy=0A= CONFIG_PROC_KCORE=3Dy=0A= # CONFIG_DEVFS_FS is not set=0A= CONFIG_DEVPTS_FS_XATTR=3Dy=0A= CONFIG_DEVPTS_FS_SECURITY=3Dy=0A= CONFIG_TMPFS=3Dy=0A= CONFIG_HUGETLBFS=3Dy=0A= CONFIG_HUGETLB_PAGE=3Dy=0A= CONFIG_RAMFS=3Dy=0A= CONFIG_RELAYFS_FS=3Dm=0A= # CONFIG_KLOG_CHANNEL is not set=0A= =0A= #=0A= # Miscellaneous filesystems=0A= #=0A= CONFIG_ADFS_FS=3Dm=0A= # CONFIG_ADFS_FS_RW is not set=0A= CONFIG_AFFS_FS=3Dm=0A= CONFIG_HFS_FS=3Dm=0A= CONFIG_HFSPLUS_FS=3Dm=0A= CONFIG_BEFS_FS=3Dm=0A= # CONFIG_BEFS_DEBUG is not set=0A= CONFIG_BFS_FS=3Dm=0A= CONFIG_EFS_FS=3Dm=0A= CONFIG_JFFS_FS=3Dm=0A= CONFIG_JFFS_FS_VERBOSE=3D0=0A= CONFIG_JFFS2_FS=3Dm=0A= CONFIG_JFFS2_FS_DEBUG=3D0=0A= # CONFIG_JFFS2_FS_NAND is not set=0A= CONFIG_CRAMFS=3Dm=0A= CONFIG_VXFS_FS=3Dm=0A= CONFIG_HPFS_FS=3Dm=0A= CONFIG_QNX4FS_FS=3Dm=0A= # CONFIG_QNX4FS_RW is not set=0A= CONFIG_SYSV_FS=3Dm=0A= CONFIG_UFS_FS=3Dm=0A= # CONFIG_UFS_FS_WRITE is not set=0A= =0A= #=0A= # Network File Systems=0A= #=0A= CONFIG_NFS_FS=3Dy=0A= CONFIG_NFS_V3=3Dy=0A= CONFIG_NFS_ACL=3Dy=0A= CONFIG_NFS_V4=3Dy=0A= CONFIG_NFS_DIRECTIO=3Dy=0A= CONFIG_NFSD=3Dm=0A= CONFIG_NFSD_V3=3Dy=0A= CONFIG_NFSD_ACL=3Dy=0A= CONFIG_NFS_ACL_SUPPORT=3Dy=0A= # CONFIG_NFSD_V4 is not set=0A= CONFIG_NFSD_TCP=3Dy=0A= CONFIG_ROOT_NFS=3Dy=0A= CONFIG_LOCKD=3Dy=0A= CONFIG_STATD=3Dy=0A= CONFIG_LOCKD_V4=3Dy=0A= CONFIG_EXPORTFS=3Dm=0A= CONFIG_SUNRPC=3Dy=0A= CONFIG_SUNRPC_GSS=3Dy=0A= CONFIG_RPCSEC_GSS_KRB5=3Dy=0A= CONFIG_SMB_FS=3Dm=0A= CONFIG_SMB_NLS_DEFAULT=3Dy=0A= CONFIG_SMB_NLS_REMOTE=3D"cp850"=0A= CONFIG_CIFS=3Dm=0A= CONFIG_CIFS_STATS=3Dy=0A= CONFIG_CIFS_XATTR=3Dy=0A= CONFIG_CIFS_POSIX=3Dy=0A= CONFIG_NCP_FS=3Dm=0A= CONFIG_NCPFS_PACKET_SIGNING=3Dy=0A= CONFIG_NCPFS_IOCTL_LOCKING=3Dy=0A= CONFIG_NCPFS_STRONG=3Dy=0A= CONFIG_NCPFS_NFS_NS=3Dy=0A= CONFIG_NCPFS_OS2_NS=3Dy=0A= CONFIG_NCPFS_SMALLDOS=3Dy=0A= CONFIG_NCPFS_NLS=3Dy=0A= CONFIG_NCPFS_EXTRAS=3Dy=0A= CONFIG_CODA_FS=3Dm=0A= # CONFIG_CODA_FS_OLD_API is not set=0A= # CONFIG_INTERMEZZO_FS is not set=0A= CONFIG_AFS_FS=3Dm=0A= CONFIG_RXRPC=3Dm=0A= =0A= #=0A= # Partition Types=0A= #=0A= CONFIG_PARTITION_ADVANCED=3Dy=0A= # CONFIG_ACORN_PARTITION is not set=0A= CONFIG_OSF_PARTITION=3Dy=0A= # CONFIG_AMIGA_PARTITION is not set=0A= CONFIG_ATARI_PARTITION=3Dy=0A= CONFIG_MAC_PARTITION=3Dy=0A= CONFIG_MSDOS_PARTITION=3Dy=0A= CONFIG_BSD_DISKLABEL=3Dy=0A= # CONFIG_MINIX_SUBPARTITION is not set=0A= CONFIG_SOLARIS_X86_PARTITION=3Dy=0A= CONFIG_UNIXWARE_DISKLABEL=3Dy=0A= CONFIG_LDM_PARTITION=3Dy=0A= # CONFIG_LDM_DEBUG is not set=0A= CONFIG_NEC98_PARTITION=3Dy=0A= CONFIG_SGI_PARTITION=3Dy=0A= CONFIG_ULTRIX_PARTITION=3Dy=0A= CONFIG_SUN_PARTITION=3Dy=0A= CONFIG_EFI_PARTITION=3Dy=0A= =0A= #=0A= # Native Language Support=0A= #=0A= CONFIG_NLS=3Dy=0A= CONFIG_NLS_DEFAULT=3D"utf8"=0A= CONFIG_NLS_CODEPAGE_437=3Dm=0A= CONFIG_NLS_CODEPAGE_737=3Dm=0A= CONFIG_NLS_CODEPAGE_775=3Dm=0A= CONFIG_NLS_CODEPAGE_850=3Dm=0A= CONFIG_NLS_CODEPAGE_852=3Dm=0A= CONFIG_NLS_CODEPAGE_855=3Dm=0A= CONFIG_NLS_CODEPAGE_857=3Dm=0A= CONFIG_NLS_CODEPAGE_860=3Dm=0A= CONFIG_NLS_CODEPAGE_861=3Dm=0A= CONFIG_NLS_CODEPAGE_862=3Dm=0A= CONFIG_NLS_CODEPAGE_863=3Dm=0A= CONFIG_NLS_CODEPAGE_864=3Dm=0A= CONFIG_NLS_CODEPAGE_865=3Dm=0A= CONFIG_NLS_CODEPAGE_866=3Dm=0A= CONFIG_NLS_CODEPAGE_869=3Dm=0A= CONFIG_NLS_CODEPAGE_936=3Dm=0A= CONFIG_NLS_CODEPAGE_950=3Dm=0A= CONFIG_NLS_CODEPAGE_932=3Dm=0A= CONFIG_NLS_CODEPAGE_949=3Dm=0A= CONFIG_NLS_CODEPAGE_874=3Dm=0A= CONFIG_NLS_ISO8859_8=3Dm=0A= CONFIG_NLS_CODEPAGE_1250=3Dm=0A= CONFIG_NLS_CODEPAGE_1251=3Dm=0A= CONFIG_NLS_ISO8859_1=3Dm=0A= CONFIG_NLS_ISO8859_2=3Dm=0A= CONFIG_NLS_ISO8859_3=3Dm=0A= CONFIG_NLS_ISO8859_4=3Dm=0A= CONFIG_NLS_ISO8859_5=3Dm=0A= CONFIG_NLS_ISO8859_6=3Dm=0A= CONFIG_NLS_ISO8859_7=3Dm=0A= CONFIG_NLS_ISO8859_9=3Dm=0A= CONFIG_NLS_ISO8859_13=3Dm=0A= CONFIG_NLS_ISO8859_14=3Dm=0A= CONFIG_NLS_ISO8859_15=3Dm=0A= CONFIG_NLS_KOI8_R=3Dm=0A= CONFIG_NLS_KOI8_U=3Dm=0A= CONFIG_NLS_UTF8=3Dm=0A= CONFIG_FSHOOKS=3Dy=0A= =0A= #=0A= # Profiling support=0A= #=0A= CONFIG_PROFILING=3Dy=0A= CONFIG_OPROFILE=3Dm=0A= =0A= #=0A= # Kernel hacking=0A= #=0A= CONFIG_CRASH_DUMP=3Dm=0A= CONFIG_KERNTYPES=3Dy=0A= CONFIG_CRASH_DUMP_BLOCKDEV=3Dm=0A= CONFIG_CRASH_DUMP_NETDEV=3Dm=0A= # CONFIG_CRASH_DUMP_MEMDEV is not set=0A= CONFIG_CRASH_DUMP_COMPRESS_RLE=3Dm=0A= CONFIG_CRASH_DUMP_COMPRESS_GZIP=3Dm=0A= CONFIG_DEBUG_KERNEL=3Dy=0A= # CONFIG_DEBUG_SLAB is not set=0A= CONFIG_MAGIC_SYSRQ=3Dy=0A= # CONFIG_DEBUG_SPINLOCK is not set=0A= # CONFIG_INIT_DEBUG is not set=0A= # CONFIG_DEBUG_INFO is not set=0A= # CONFIG_FRAME_POINTER is not set=0A= CONFIG_KDB=3Dm=0A= CONFIG_KDB_MODULES=3Dm=0A= # CONFIG_KDB_OFF is not set=0A= CONFIG_KDB_CONTINUE_CATASTROPHIC=3D0=0A= # CONFIG_IOMMU_DEBUG is not set=0A= =0A= #=0A= # Security options=0A= #=0A= CONFIG_SECURITY=3Dy=0A= CONFIG_SECURITY_NETWORK=3Dy=0A= CONFIG_SECURITY_CAPABILITIES=3Dm=0A= CONFIG_SECURITY_ROOTPLUG=3Dm=0A= CONFIG_SECURITY_SELINUX=3Dy=0A= CONFIG_SECURITY_SELINUX_BOOTPARAM=3Dy=0A= CONFIG_SECURITY_SELINUX_DEVELOP=3Dy=0A= # CONFIG_SECURITY_SELINUX_MLS is not set=0A= =0A= #=0A= # Cryptographic options=0A= #=0A= CONFIG_CRYPTO=3Dy=0A= CONFIG_CRYPTO_HMAC=3Dy=0A= CONFIG_CRYPTO_NULL=3Dm=0A= CONFIG_CRYPTO_MD4=3Dm=0A= CONFIG_CRYPTO_MD5=3Dy=0A= CONFIG_CRYPTO_SHA1=3Dm=0A= CONFIG_CRYPTO_SHA256=3Dm=0A= CONFIG_CRYPTO_SHA512=3Dm=0A= CONFIG_CRYPTO_DES=3Dy=0A= CONFIG_CRYPTO_BLOWFISH=3Dm=0A= CONFIG_CRYPTO_TWOFISH=3Dm=0A= CONFIG_CRYPTO_SERPENT=3Dm=0A= CONFIG_CRYPTO_AES=3Dm=0A= CONFIG_CRYPTO_CAST5=3Dm=0A= CONFIG_CRYPTO_CAST6=3Dm=0A= CONFIG_CRYPTO_ARC4=3Dm=0A= CONFIG_CRYPTO_DEFLATE=3Dm=0A= CONFIG_CRYPTO_MICHAEL_MIC=3Dm=0A= CONFIG_CRYPTO_TEST=3Dm=0A= =0A= #=0A= # Library routines=0A= #=0A= CONFIG_CRC32=3Dy=0A= CONFIG_QSORT=3Dy=0A= CONFIG_ZLIB_INFLATE=3Dy=0A= CONFIG_ZLIB_DEFLATE=3Dm=0A= =0A= #=0A= # Build options=0A= #=0A= CONFIG_SUSE_KERNEL=3Dy=0A= CONFIG_CFGNAME=3D"default"=0A= CONFIG_RELEASE=3D"7.135"=0A= ------=_NextPart_000_003B_01C539ED.7562F8A0-- From herbert@gondor.apana.org.au Tue Apr 5 14:46:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:46:18 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Lk9rN029261 for ; Tue, 5 Apr 2005 14:46:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DIvrk-0003SX-00; Wed, 06 Apr 2005 07:45:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DIvr8-0002yy-00; Wed, 06 Apr 2005 07:45:06 +1000 From: Herbert Xu To: christoph@lameter.com (Christoph Lameter) Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Cc: netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 06 Apr 2005 07:45:06 +1000 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Christoph Lameter wrote: > > Index: linux-2.6.11/net/core/dst.c > =================================================================== > --- linux-2.6.11.orig/net/core/dst.c 2005-03-01 23:38:12.000000000 -0800 > +++ linux-2.6.11/net/core/dst.c 2005-04-05 11:04:41.000000000 -0700 > @@ -198,7 +198,8 @@ again: > > dst = child; > if (dst) { > - if (atomic_dec_and_test(&dst->__refcnt)) { > + atomic_dec(&dst->__refcnt); > + if (!atomic_read(&dst->__refcnt)) { > /* We were real parent of this dst, so kill child. */ > if (dst->flags&DST_NOHASH) > goto again; This is racy (albeit very unlikely) because dst may be freed by dst_run_gc after the atomic_dec. When we are not the real parent of the dst (e.g., when we're xfrm_dst and the child is an rtentry), it may already be on the GC list. In fact the current code is buggy to, we need to check dst->flags before the dec as dst may no longer be valid afterwards. Signed-off-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/core/dst.c 1.28 vs edited ===== --- 1.28/net/core/dst.c 2005-02-16 09:23:10 +11:00 +++ edited/net/core/dst.c 2005-04-06 07:41:02 +10:00 @@ -198,13 +198,15 @@ dst = child; if (dst) { + int nohash = dst->flags & DST_NOHASH; + if (atomic_dec_and_test(&dst->__refcnt)) { /* We were real parent of this dst, so kill child. */ - if (dst->flags&DST_NOHASH) + if (nohash) goto again; } else { /* Child is still referenced, return it for freeing. */ - if (dst->flags&DST_NOHASH) + if (nohash) return dst; /* Child is still in his hash table */ } From davem@davemloft.net Tue Apr 5 14:50:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 14:50:57 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35Loosw030012 for ; Tue, 5 Apr 2005 14:50:50 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DIvun-00065M-00; Tue, 05 Apr 2005 14:48:53 -0700 Date: Tue, 5 Apr 2005 14:48:53 -0700 From: "David S. Miller" To: Herbert Xu Cc: christoph@lameter.com, netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-Id: <20050405144853.0523fde6.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 06 Apr 2005 07:45:06 +1000 Herbert Xu wrote: > When we are not the real parent of the dst (e.g., when we're xfrm_dst > and the child is an rtentry), it may already be on the GC list. > > In fact the current code is buggy to, we need to check dst->flags > before the dec as dst may no longer be valid afterwards. > > Signed-off-by: Herbert Xu Good catch Herbert, I'll apply this. From christoph@graphe.net Tue Apr 5 15:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 15:14:42 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35MEbLa031752 for ; Tue, 5 Apr 2005 15:14:37 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DIwJW-0004Vk-TB; Tue, 05 Apr 2005 15:14:29 -0700 Date: Tue, 5 Apr 2005 15:14:26 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@server.graphe.net To: Herbert Xu cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev On Wed, 6 Apr 2005, Herbert Xu wrote: > > - if (atomic_dec_and_test(&dst->__refcnt)) { > > + atomic_dec(&dst->__refcnt); > > + if (!atomic_read(&dst->__refcnt)) { > > This is racy (albeit very unlikely) because dst may be freed by > dst_run_gc after the atomic_dec. If that is so then it is also possible that the gc frees after atomic_dec_and_test: cpu0 dst_destroy cpu1 dst_run_gc atomic_dec_and_test(refcnt) if (atomic_read(refcnt)) ... .. dst_destroy(dst) kmem_cache_free(dst) .. goto again ... kmem_cache_free(dst) From jaganav@us.ibm.com Tue Apr 5 15:19:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 15:19:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j35MJpkN032547 for ; Tue, 5 Apr 2005 15:19:51 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j35MJjLg568926 for ; Tue, 5 Apr 2005 18:19:45 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j35MJjWs244554 for ; Tue, 5 Apr 2005 16:19:45 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j35MJibQ026809 for ; Tue, 5 Apr 2005 16:19:45 -0600 Received: from imap.linux.ibm.com (imap.rtp.raleigh.ibm.com [9.42.107.100]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j35MJgAr026742; Tue, 5 Apr 2005 16:19:44 -0600 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 7D16D7C015; Tue, 5 Apr 2005 18:19:41 -0400 (EDT) Received: from sig-9-65-39-90.mts.ibm.com (sig-9-65-39-90.mts.ibm.com [9.65.39.90]) by imap.rtp.raleigh.ibm.com (IMP) with HTTP for ; Tue, 5 Apr 2005 18:19:40 -0400 Message-ID: <1112739580.42530efce23ff@imap.linux.ibm.com> Date: Tue, 5 Apr 2005 18:19:40 -0400 From: jaganav@us.ibm.com To: Rik van Riel Cc: Greg KH , Stephen Hemminger , Roland Dreier , Benjamin LaHaise , Dmitry Yusupov , open-iscsi@googlegroups.com, "David S. Miller" , mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu, James.Bottomley@HansenPartnership.com, ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com, bmt@zurich.ibm.com Subject: Re: Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-Originating-IP: 9.65.39.90 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaganav@us.ibm.com Precedence: bulk X-list: netdev Quoting Rik van Riel : > On Sat, 2 Apr 2005 jaganav@us.ibm.com wrote: > > > If this dual license is a concern to other kernel developers as well > > from contributing to OpenRDMA, we would seriously consider this and > > discuss with the adapter vendors. > > It could be a problem when trying to reuse existing > GPL code, eg. to hook into locking mechanisms. It > could also be a problem if you touch data structures > that are protected by RCU. Right, this could be one of the significant porting issues but it may become a real concern. Thanks. Thanks Venkat From dmitry_yus@yahoo.com Tue Apr 5 16:53:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 16:54:02 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j35Nrv0J007739 for ; Tue, 5 Apr 2005 16:53:58 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp017.mail.yahoo.com with SMTP; 5 Apr 2005 23:53:57 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Jean-Mickael Guerin Cc: netdev@oss.sgi.com In-Reply-To: <4253059C.1080000@6wind.com> References: <1112730889.16753.17.camel@beastie> <4253059C.1080000@6wind.com> Content-Type: text/plain Date: Tue, 05 Apr 2005 16:53:56 -0700 Message-Id: <1112745236.16753.23.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev On Tue, 2005-04-05 at 23:39 +0200, Jean-Mickael Guerin wrote: > Dmitry Yusupov wrote: > > This patch provides: > > > > * new event for unicast connections NETLINK_UESTABLISHED. > > Which kind of application takes benefit of this event ? we have NETLINK_URELEASE already where netlink user usually free associated resources. It is nice to have NETLINK_UESTABLISHED to implement reverse needs. For example, netlink user wants to allocate associated resources or to monitor new connections from user-space before it actually gets first interrupt from it. > btw your diff is reversed ;-) oh, well, I was running out of time. still applicable... :) > Jean-Mickael > From dmitry_yus@yahoo.com Tue Apr 5 17:13:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 17:13:37 -0700 (PDT) Received: from smtp111.mail.sc5.yahoo.com (smtp111.mail.sc5.yahoo.com [66.163.170.9]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j360DX4a009176 for ; Tue, 5 Apr 2005 17:13:33 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp111.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 00:13:32 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Jean-Mickael Guerin Cc: netdev@oss.sgi.com In-Reply-To: <4253059C.1080000@6wind.com> References: <1112730889.16753.17.camel@beastie> <4253059C.1080000@6wind.com> Content-Type: multipart/mixed; boundary="=-sXHSrktl3TjxUojfEjC1" Date: Tue, 05 Apr 2005 17:13:31 -0700 Message-Id: <1112746411.16753.29.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev --=-sXHSrktl3TjxUojfEjC1 Content-Type: text/plain Content-Transfer-Encoding: 7bit resend. On Tue, 2005-04-05 at 23:39 +0200, Jean-Mickael Guerin wrote: > Dmitry Yusupov wrote: > > This patch provides: > > > > * new event for unicast connections NETLINK_UESTABLISHED. > > Which kind of application takes benefit of this event ? > > btw your diff is reversed ;-) > > Jean-Mickael > --=-sXHSrktl3TjxUojfEjC1 Content-Disposition: attachment; filename=netlink_uestablish_event.patch Content-Type: text/x-patch; name=netlink_uestablish_event.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- linux-2.6.11.orig/net/netlink/af_netlink.c 2005-03-01 23:38:09.000000000 -0800 +++ linux-2.6.11-um/net/netlink/af_netlink.c 2005-04-05 12:40:33.000000000 -0700 @@ -467,8 +467,14 @@ return err; } - if (!nladdr->nl_groups && !nlk->groups) + if (!nladdr->nl_groups && !nlk->groups) { + struct netlink_notify n = { + .protocol = sk->sk_protocol, + .pid = nladdr->nl_pid, + }; + notifier_call_chain(&netlink_chain, NETLINK_UESTABLISHED, &n); return 0; + } netlink_table_grab(); if (nlk->groups && !nladdr->nl_groups) @@ -504,7 +510,6 @@ if (!nlk->pid) err = netlink_autobind(sock); - if (err == 0) { sk->sk_state = NETLINK_CONNECTED; nlk->dst_pid = nladdr->nl_pid; @@ -542,7 +547,7 @@ } } -static struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid) +struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid) { int protocol = ssk->sk_protocol; struct sock *sock; @@ -920,7 +925,7 @@ if (len > sk->sk_sndbuf - 32) goto out; err = -ENOBUFS; - skb = alloc_skb(len, GFP_KERNEL); + skb = alloc_skb(len, sk->sk_allocation); if (skb==NULL) goto out; @@ -1179,7 +1184,7 @@ else size = NLMSG_SPACE(4 + NLMSG_ALIGN(nlh->nlmsg_len)); - skb = alloc_skb(size, GFP_KERNEL); + skb = alloc_skb(size, in_skb->sk->sk_allocation); if (!skb) { struct sock *sk; @@ -1465,4 +1470,5 @@ EXPORT_SYMBOL(netlink_set_nonroot); EXPORT_SYMBOL(netlink_unicast); EXPORT_SYMBOL(netlink_unregister_notifier); +EXPORT_SYMBOL(netlink_getsockbypid); --- linux-2.6.11.orig/include/linux/notifier.h 2005-03-01 23:37:48.000000000 -0800 +++ linux-2.6.11-um/include/linux/notifier.h 2005-04-05 12:30:10.000000000 -0700 @@ -62,14 +62,15 @@ #define SYS_HALT 0x0002 /* Notify of system halt */ #define SYS_POWER_OFF 0x0003 /* Notify of system power off */ -#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */ +#define NETLINK_UESTABLISHED 0x0001 /* Unicast netlink socket established */ +#define NETLINK_URELEASE 0x0002 /* Unicast netlink socket released */ -#define CPU_ONLINE 0x0002 /* CPU (unsigned)v is up */ -#define CPU_UP_PREPARE 0x0003 /* CPU (unsigned)v coming up */ -#define CPU_UP_CANCELED 0x0004 /* CPU (unsigned)v NOT coming up */ -#define CPU_DOWN_PREPARE 0x0005 /* CPU (unsigned)v going down */ -#define CPU_DOWN_FAILED 0x0006 /* CPU (unsigned)v NOT going down */ -#define CPU_DEAD 0x0007 /* CPU (unsigned)v dead */ +#define CPU_ONLINE 0x0003 /* CPU (unsigned)v is up */ +#define CPU_UP_PREPARE 0x0004 /* CPU (unsigned)v coming up */ +#define CPU_UP_CANCELED 0x0005 /* CPU (unsigned)v NOT coming up */ +#define CPU_DOWN_PREPARE 0x0006 /* CPU (unsigned)v going down */ +#define CPU_DOWN_FAILED 0x0007 /* CPU (unsigned)v NOT going down */ +#define CPU_DEAD 0x0008 /* CPU (unsigned)v dead */ #endif /* __KERNEL__ */ #endif /* _LINUX_NOTIFIER_H */ --- linux-2.6.11.orig/include/linux/netlink.h 2005-03-01 23:38:25.000000000 -0800 +++ linux-2.6.11-um/include/linux/netlink.h 2005-04-05 11:35:15.000000000 -0700 @@ -124,6 +124,7 @@ extern void netlink_set_err(struct sock *ssk, __u32 pid, __u32 group, int code); extern int netlink_register_notifier(struct notifier_block *nb); extern int netlink_unregister_notifier(struct notifier_block *nb); +extern struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid); /* finegrained unicast helpers: */ struct sock *netlink_getsockbyfilp(struct file *filp); --=-sXHSrktl3TjxUojfEjC1-- From herbert@gondor.apana.org.au Tue Apr 5 19:21:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 19:21:29 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j362LH8G015473 for ; Tue, 5 Apr 2005 19:21:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJ08p-00053m-00; Wed, 06 Apr 2005 12:19:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJ08O-0003Ln-00; Wed, 06 Apr 2005 12:19:12 +1000 From: Herbert Xu To: christoph@lameter.com (Christoph Lameter) Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 06 Apr 2005 12:19:12 +1000 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Christoph Lameter wrote: > > If that is so then it is also possible that the gc frees after > atomic_dec_and_test: No this is prevented by the nohash check. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Apr 5 19:23:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 19:23:18 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j362N6um015854 for ; Tue, 5 Apr 2005 19:23:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJ0BQ-00054o-00; Wed, 06 Apr 2005 12:22:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJ0B1-0003N9-00; Wed, 06 Apr 2005 12:21:55 +1000 Date: Wed, 6 Apr 2005 12:21:55 +1000 To: Patrick McHardy Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-ID: <20050406022155.GA12952@gondor.apana.org.au> References: <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> <4252EEA2.5020107@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4252EEA2.5020107@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 10:01:38PM +0200, Patrick McHardy wrote: > > Good idea, I didn't think of this. This patch is without replacement of > xfrm_init_tempsel(), it caused an "unused function" warning and, as I > mentioned before, I still need the function. Thanks. Just one more issue that I can think of, the check should only be done when tmpl->id.spi != 0. Otherwise the presence of valid states with differing state selectors will prevent new sessions from starting up. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Apr 5 19:46:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 19:46:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j362kiwG017223 for ; Tue, 5 Apr 2005 19:46:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJ0Yo-0005CC-00; Wed, 06 Apr 2005 12:46:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJ0YI-0003PR-00; Wed, 06 Apr 2005 12:45:58 +1000 From: Herbert Xu To: dmitry_yus@yahoo.com (Dmitry Yusupov) Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Cc: netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <1112730889.16753.17.camel@beastie> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 06 Apr 2005 12:45:58 +1000 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Dmitry Yusupov wrote: > > * new event for unicast connections NETLINK_UESTABLISHED. Huh? In the patch you're actually sending the notification when the socket stops listening to multicast traffic. Please document why we need this in greater detail too. > * netlink alloc_skb() now uses sk_allocation instead of hard-coded > GFP_KERNEL Why? We never set it to anything else for netlink. > * since netlink event described via proto and pid, > netlink_getsockbypid() is exported, so netlink user can identify socket. Please submit the users for kernel inclusion first. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From christoph@graphe.net Tue Apr 5 20:20:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 20:20:11 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j363K4TN022014 for ; Tue, 5 Apr 2005 20:20:04 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJ159-0005o7-UO; Tue, 05 Apr 2005 20:19:58 -0700 Date: Tue, 5 Apr 2005 20:19:55 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev On Wed, 6 Apr 2005, Herbert Xu wrote: > Christoph Lameter wrote: > > > > If that is so then it is also possible that the gc frees after > > atomic_dec_and_test: > > No this is prevented by the nohash check. Ok then the purpose of this whole thing is to decrement the usage counter and at the same time figure out if this is the last child on an unhashed entry. That unhashed entry is not handled by the garbage collector and must be freed separately. The atomic_dec_and_test is needed because as soon as the refcnt reaches zero the dst entry may potentially be freed by the garbage collector. Thus no future access to the dst entry is possible and the dec_and_test is the only safe way to figure out if the counter reached zero. I hope I got it now. Thanks. From lark@linux.net.cn Tue Apr 5 22:12:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 22:13:00 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j365Co3j026197 for ; Tue, 5 Apr 2005 22:12:51 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id E33083ED42; Wed, 6 Apr 2005 13:12:40 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 20008-02-2; Wed, 6 Apr 2005 13:12:36 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 85DAA3EC0B; Wed, 6 Apr 2005 13:12:35 +0800 (CST) Date: Wed, 06 Apr 2005 13:12:35 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [RFC] QoS: new per flow queue Cc: netdev In-Reply-To: <1112723858.1076.46.camel@jzny.localdomain> References: <20050405224956.0258.LARK@linux.net.cn> <1112723858.1076.46.camel@jzny.localdomain> Message-Id: <20050406123117.0265.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Hi jamal, I know your concern. Actually, I first try to implement it like you point out, but then I dismiss that scheme, because it is hard to maintain for the userspace. But if the dynfwmark can dynamically alloc htb class in the given class id range. For example tc filter ip u32 tc filter ip u32 match ip sport 80 0xffff flowid 1:12 \ action dynfwmark major 1 range 1:1000 continue When it detects a new flow, it creates the necessary htb class? So the userspace work is simple. But when we have segmented class id space, we may not get such an enough empty range. On 05 Apr 2005 13:57:38 -0400, jamal wrote: > > I quickly scanned the kernel portion. I dont think this is the best way > to achieve this - your qdisc is both a classifier and scheduler. I think > this is the major drwback. > And if you take out the classifier - whats left in your qdisc cant beat > htb or hfsc or cbq in terms of being proven to be accurate. I think per flow control in nature means that classifier must be intimately coupled with scheduler. There is no way around it. If you seperate them, you must provide a way to link them together again. The dynfwmark way you suggested actually does so, but not clean (because you choose to use existing nfmark infrastructure). If it carries an unique id or something like in its own namespace, then it can be clean and friendly for userspace, but I bet it is unnecessarily bloated. In my test, HTB performs very well. I intensionally requires a HTB class to enclose a perflow queue to provide guaranteed sum bandwidth. The queue is proven to be fair enough and can guarantee rate internally for its flows (if the per flow rate is at or above 10kbps). I haven't tested rate lower than 10kbps, because my test client is not that accurate to show the number. It's simply a "lftpget ". There are short threads before in which someone asked for a per flow control solution, and was suggested to use HTB + SFQ. My test reveals that SFQ is far away from fairness and can't meet the requirement of bandwidth assurance. For HFSC, I haven't any experience with it because the documentation is lacked. > > If you could write a meta action instead which is a simple dynamic > setter of something like fwmark that would suffice i.e something along > the lines of: > > example: > ---- > tc filter ip u32 match ip sport 80 0xffff flowid 1:12 \ > action dynfwmark continue > tc filter fwmark 0x1 .. classid aaaa > tc filter fwmark 0x2 .. classid bbbb > .. > .. > > tc qdisc htb/hfsc/cbq .... your rate parameters here. > --- > > dynfwmark will maintain your state table which gets deleted when timers > expire and will hash based on the current jenkins hash > Do you have to queue the packets? if not you could instead have the > police action (attached to fwmark) drop the packet once it exceeds > certain rate and then use any enqueueing scheme you want. > The drawback with above scheme is you will have as many entries for > fwmark as you want to have queues - each selecting its own queue. > > cheers, > jamal > > On Tue, 2005-04-05 at 11:25, Wang Jian wrote: > > Hi, > > > > I write a per flow rate control qdisc. I posted it to LARTC list. Some > > discussion about it is here > > > > http://mailman.ds9a.nl/pipermail/lartc/2005q2/015381.html > > > > I think I need more feedback and suggestion on it so I repost the patch > > here. Please read the thread and get a picture about why and how. > > > > The kernel patch is agains kernel 2.6.11, the iproute2 patch is against > > iproute2-2.6.11-050314. > > > > The test scenario is like this > > > > www server <- [ eth0 eth1 ] -> www clients > > > > The attached t.sh is used to generate test rules. Clients download a > > big ISO file from www server, so flows' rate can be estimated by view > > progress. > > > > I have some test on it and it works well. It provides good fairness. > > When all slot being used, in most time, the real rate can keep at > > specified guaranteed rate. But I know it should receive more test. > > > > I have some consideration though > > > > 1. In the test sometimes there a pair of unbalanced stream and don't get > > balanced quickly. One stream get 8.4kbps and another get 11.5kbps. How > > to find the flow with highest traffic and punish it most? > > > > 2. The default ceil equals to rate. Should I calculate it as > > ceil = rate * 1.05 * limit, or > > ceil = rate * 1.05? > > > > 3. when flow slots are full, optionally reclassify untraceable traffic > > into another specified class, instead of dropping it? > > > > TODO: > > > > 1. rtnetlink related code should be improved; > > 2. dump() and dump_stat(); > > > > > > Regards -- lark From dmitry_yus@yahoo.com Tue Apr 5 22:55:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 22:55:10 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j365t54d027849 for ; Tue, 5 Apr 2005 22:55:05 -0700 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp011.mail.yahoo.com with SMTP; 6 Apr 2005 05:55:04 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: References: Content-Type: text/plain Date: Tue, 05 Apr 2005 22:55:01 -0700 Message-Id: <1112766901.7488.16.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev On Wed, 2005-04-06 at 12:45 +1000, Herbert Xu wrote: > Dmitry Yusupov wrote: > > > > * new event for unicast connections NETLINK_UESTABLISHED. > > Huh? In the patch you're actually sending the notification > when the socket stops listening to multicast traffic. it could be that I just screwed up everything as usual and my application just works as expected for some mythical reasons 8) but on a serious note, it is sends event from netlink_bind() context for non-multicast connections only. may be I messed up something, so please correct me. > Please document why we need this in greater detail too. main reason for this is to have clear way to notify netlink user that new socket created and bound. > > * netlink alloc_skb() now uses sk_allocation instead of hard-coded > > GFP_KERNEL > > Why? We never set it to anything else for netlink. one reason is for consistency with sock interface. sk_allocation is equal to GFP_KERNEL by default, so nothing changed. but. in some cases application might require non-blocking kmalloc behavior. one real life example is networking block device used for swap partition. this way any GFP_KERENL allocation on recovery path might lead to deadlock condition. From herbert@gondor.apana.org.au Tue Apr 5 23:04:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 23:04:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3664Fq9028667 for ; Tue, 5 Apr 2005 23:04:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJ3e1-0005pL-00; Wed, 06 Apr 2005 16:04:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJ3df-0003fA-00; Wed, 06 Apr 2005 16:03:43 +1000 Date: Wed, 6 Apr 2005 16:03:43 +1000 To: Dmitry Yusupov Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050406060343.GA14059@gondor.apana.org.au> References: <1112766901.7488.16.camel@mylaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112766901.7488.16.camel@mylaptop> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, Apr 05, 2005 at 10:55:01PM -0700, Dmitry Yusupov wrote: > > main reason for this is to have clear way to notify netlink user that > new socket created and bound. Why do you want to exclude sockets that listen to multicast messages? They can still do unicast transactions. > one reason is for consistency with sock interface. sk_allocation is > equal to GFP_KERNEL by default, so nothing changed. but. in some cases > application might require non-blocking kmalloc behavior. one real life > example is networking block device used for swap partition. this way any > GFP_KERENL allocation on recovery path might lead to deadlock condition. Setting of sk_allocation is controlled by the protocol itself. In this case this is af_netlink.c. As you can see, we never set this to anything other than GFP_KERNEL. Using sk_allocation will only confuse those who are not familiar with netlink into thinking that this can be atomic. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From lark@linux.net.cn Tue Apr 5 23:45:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Apr 2005 23:46:07 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j366jnnF030770 for ; Tue, 5 Apr 2005 23:45:54 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id A557B3EC0B; Wed, 6 Apr 2005 14:45:43 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 21156-01-2; Wed, 6 Apr 2005 14:45:38 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 59D593ED42; Wed, 6 Apr 2005 14:45:37 +0800 (CST) Date: Wed, 06 Apr 2005 14:45:37 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: Thomas Graf , netdev In-Reply-To: <1112717495.1076.22.camel@jzny.localdomain> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> Message-Id: <20050406143842.026B.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_425383F105F906134008_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev --------_425383F105F906134008_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi jamal, On 05 Apr 2005 12:11:35 -0400, jamal wrote: > Hi Wang, > > On Tue, 2005-04-05 at 10:18, Wang Jian wrote: > > > I am not saying that we must use jenkins. We may use a less expensive > > hash function than jenkins, but better than & 0xFF. > > > > Sure; point is as long as it doesnt destroy the common use in place. > > >Anyway, I have done userspace test for jhash. The following test > > is done in a AMD Athlon 800MHz without other CPU load. > > > > No, the test i was asking for is to show distribution of the > hash not how long it took (which is also an ok test). Sorry, the test is not on the AMD Athlon 800MHz, but a 2.4G Pentium4! I didn't notice that. So the jhash's performance is not fast enough. On AMD 800Mhz line speed @ 1000Mbps [root@home ~]# time ./a.out 0.31user 0.00system 0:00.32elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+83minor)pagefaults 0swaps line speed @ 100Mbps [root@home ~]# time ./a.out 0.03user 0.00system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+83minor)pagefaults 0swaps > > i.e if you fed the jenkins hash with 256 buckets - lets pick the number 1024 > samples of the data you showed earlier for how fwmark looks like, > how well would the result look like. > And what if you fed it with something like 1024 incremental fwmark from > say 1..1024? > The test result looks not good. See attached file. So let's find a better way. -- lark --------_425383F105F906134008_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="jhash-dist.txt" Content-Disposition: attachment; filename="jhash-dist.txt" Content-Transfer-Encoding: base64 JFZBUjEgPSB7CiAgICAgICAgICAnMzInID0+IDEsCiAgICAgICAgICAnMTI3JyA9PiAzLAogICAg ICAgICAgJzkwJyA9PiA2LAogICAgICAgICAgJzExOCcgPT4gMywKICAgICAgICAgICcyMDYnID0+ IDIsCiAgICAgICAgICAnNzEnID0+IDIsCiAgICAgICAgICAnMTAyJyA9PiA3LAogICAgICAgICAg JzIwMCcgPT4gNCwKICAgICAgICAgICcxOCcgPT4gNywKICAgICAgICAgICcxMjUnID0+IDQsCiAg ICAgICAgICAnMTYnID0+IDgsCiAgICAgICAgICAnNDQnID0+IDIsCiAgICAgICAgICAnNTUnID0+ IDQsCiAgICAgICAgICAnODQnID0+IDYsCiAgICAgICAgICAnMjcnID0+IDQsCiAgICAgICAgICAn MTkwJyA9PiA1LAogICAgICAgICAgJzIzMycgPT4gNCwKICAgICAgICAgICcxNjEnID0+IDksCiAg ICAgICAgICAnNTcnID0+IDIsCiAgICAgICAgICAnMTk0JyA9PiAzLAogICAgICAgICAgJzk1JyA9 PiA1LAogICAgICAgICAgJzIyMCcgPT4gMiwKICAgICAgICAgICcyMCcgPT4gMiwKICAgICAgICAg ICcxNjMnID0+IDIsCiAgICAgICAgICAnMjMxJyA9PiAxLAogICAgICAgICAgJzEwOScgPT4gNCwK ICAgICAgICAgICcyNDMnID0+IDMsCiAgICAgICAgICAnMTUxJyA9PiAzLAogICAgICAgICAgJzg5 JyA9PiAzLAogICAgICAgICAgJzE3NScgPT4gMywKICAgICAgICAgICcxNDgnID0+IDcsCiAgICAg ICAgICAnMzEnID0+IDIsCiAgICAgICAgICAnMzUnID0+IDIsCiAgICAgICAgICAnMTEnID0+IDUs CiAgICAgICAgICAnMjA4JyA9PiA1LAogICAgICAgICAgJzc4JyA9PiA0LAogICAgICAgICAgJzkz JyA9PiAyLAogICAgICAgICAgJzEwNicgPT4gMSwKICAgICAgICAgICcxNTcnID0+IDUsCiAgICAg ICAgICAnNjUnID0+IDMsCiAgICAgICAgICAnMjknID0+IDUsCiAgICAgICAgICAnMTk3JyA9PiA3 LAogICAgICAgICAgJzIwMycgPT4gMiwKICAgICAgICAgICcxMzgnID0+IDEsCiAgICAgICAgICAn MTE0JyA9PiA0LAogICAgICAgICAgJzE5OScgPT4gNiwKICAgICAgICAgICcyMjYnID0+IDIsCiAg ICAgICAgICAnNTgnID0+IDcsCiAgICAgICAgICAnMTUnID0+IDMsCiAgICAgICAgICAnMTUzJyA9 PiAxLAogICAgICAgICAgJzIxMScgPT4gNSwKICAgICAgICAgICcxMzcnID0+IDEsCiAgICAgICAg ICAnODEnID0+IDUsCiAgICAgICAgICAnNjAnID0+IDMsCiAgICAgICAgICAnNzMnID0+IDIsCiAg ICAgICAgICAnMTAxJyA9PiA1LAogICAgICAgICAgJzc2JyA9PiA1LAogICAgICAgICAgJzg2JyA9 PiA2LAogICAgICAgICAgJzYyJyA9PiA2LAogICAgICAgICAgJzI0NycgPT4gMiwKICAgICAgICAg ICc2NycgPT4gNCwKICAgICAgICAgICcyMDQnID0+IDMsCiAgICAgICAgICAnMjQxJyA9PiAzLAog ICAgICAgICAgJzE2NScgPT4gNywKICAgICAgICAgICcxMzknID0+IDYsCiAgICAgICAgICAnMTk4 JyA9PiA2LAogICAgICAgICAgJzEyOScgPT4gNywKICAgICAgICAgICcyJyA9PiAzLAogICAgICAg ICAgJzE3JyA9PiA1LAogICAgICAgICAgJzE4NicgPT4gNCwKICAgICAgICAgICc4MicgPT4gNiwK ICAgICAgICAgICcxMTAnID0+IDIsCiAgICAgICAgICAnMTQ3JyA9PiA5LAogICAgICAgICAgJzIy OCcgPT4gMiwKICAgICAgICAgICcyMzYnID0+IDQsCiAgICAgICAgICAnMjQ5JyA9PiAzLAogICAg ICAgICAgJzIwMicgPT4gNiwKICAgICAgICAgICcxNjgnID0+IDMsCiAgICAgICAgICAnMjE4JyA9 PiAxLAogICAgICAgICAgJzE0JyA9PiAxLAogICAgICAgICAgJzEzNScgPT4gMywKICAgICAgICAg ICcxODQnID0+IDUsCiAgICAgICAgICAnNjknID0+IDUsCiAgICAgICAgICAnMTEyJyA9PiA3LAog ICAgICAgICAgJzE3MicgPT4gMywKICAgICAgICAgICcxNDUnID0+IDQsCiAgICAgICAgICAnNDkn ID0+IDQsCiAgICAgICAgICAnMTc4JyA9PiAzLAogICAgICAgICAgJzI0JyA9PiA1LAogICAgICAg ICAgJzIyNCcgPT4gMywKICAgICAgICAgICcxNDAnID0+IDcsCiAgICAgICAgICAnMTg3JyA9PiA0 LAogICAgICAgICAgJzIyMycgPT4gNSwKICAgICAgICAgICcxMjQnID0+IDEsCiAgICAgICAgICAn MTA0JyA9PiAzLAogICAgICAgICAgJzEzMScgPT4gNSwKICAgICAgICAgICcxODEnID0+IDIsCiAg ICAgICAgICAnMjM0JyA9PiA0LAogICAgICAgICAgJzc5JyA9PiAzLAogICAgICAgICAgJzEyMScg PT4gNCwKICAgICAgICAgICcyMTInID0+IDMsCiAgICAgICAgICAnMTU0JyA9PiA2LAogICAgICAg ICAgJzAnID0+IDUsCiAgICAgICAgICAnMjMnID0+IDEsCiAgICAgICAgICAnOTYnID0+IDcsCiAg ICAgICAgICAnMTI2JyA9PiAzLAogICAgICAgICAgJzIzOCcgPT4gMywKICAgICAgICAgICcxNTkn ID0+IDYsCiAgICAgICAgICAnMjUxJyA9PiAzLAogICAgICAgICAgJzI1MycgPT4gMiwKICAgICAg ICAgICcxNjAnID0+IDYsCiAgICAgICAgICAnMTc2JyA9PiAyLAogICAgICAgICAgJzQ3JyA9PiA3 LAogICAgICAgICAgJzgnID0+IDYsCiAgICAgICAgICAnOTgnID0+IDQsCiAgICAgICAgICAnMjA5 JyA9PiA0LAogICAgICAgICAgJzIxNicgPT4gNCwKICAgICAgICAgICczNycgPT4gNCwKICAgICAg ICAgICcxMTcnID0+IDIsCiAgICAgICAgICAnNDMnID0+IDQsCiAgICAgICAgICAnMTk1JyA9PiA3 LAogICAgICAgICAgJzUnID0+IDQsCiAgICAgICAgICAnMTcwJyA9PiA0LAogICAgICAgICAgJzMz JyA9PiA1LAogICAgICAgICAgJzYzJyA9PiA1LAogICAgICAgICAgJzIxJyA9PiA2LAogICAgICAg ICAgJzcnID0+IDUsCiAgICAgICAgICAnMjI3JyA9PiAzLAogICAgICAgICAgJzgwJyA9PiA0LAog ICAgICAgICAgJzI2JyA9PiA0LAogICAgICAgICAgJzE5MycgPT4gMSwKICAgICAgICAgICcxMTkn ID0+IDMsCiAgICAgICAgICAnOTknID0+IDEsCiAgICAgICAgICAnMTgwJyA9PiAzLAogICAgICAg ICAgJzI0NCcgPT4gNCwKICAgICAgICAgICcxNjInID0+IDIsCiAgICAgICAgICAnNzInID0+IDQs CiAgICAgICAgICAnMTc5JyA9PiAzLAogICAgICAgICAgJzI1NScgPT4gMywKICAgICAgICAgICcy NDYnID0+IDMsCiAgICAgICAgICAnNzQnID0+IDQsCiAgICAgICAgICAnMjQwJyA9PiA1LAogICAg ICAgICAgJzE4MicgPT4gMiwKICAgICAgICAgICc2MScgPT4gNSwKICAgICAgICAgICcyMzAnID0+ IDQsCiAgICAgICAgICAnMTA4JyA9PiAyLAogICAgICAgICAgJzExNScgPT4gNiwKICAgICAgICAg ICc5MicgPT4gNSwKICAgICAgICAgICcxMDMnID0+IDUsCiAgICAgICAgICAnMjAxJyA9PiAyLAog ICAgICAgICAgJzIzMicgPT4gNCwKICAgICAgICAgICcxMCcgPT4gMywKICAgICAgICAgICcxMTMn ID0+IDYsCiAgICAgICAgICAnMTUyJyA9PiAyLAogICAgICAgICAgJzE4OScgPT4gNiwKICAgICAg ICAgICcyMjUnID0+IDMsCiAgICAgICAgICAnMjA3JyA9PiAyLAogICAgICAgICAgJzE0MicgPT4g NSwKICAgICAgICAgICc5MScgPT4gMSwKICAgICAgICAgICcxNjcnID0+IDUsCiAgICAgICAgICAn NDgnID0+IDYsCiAgICAgICAgICAnMTA3JyA9PiA0LAogICAgICAgICAgJzg3JyA9PiAzLAogICAg ICAgICAgJzc3JyA9PiAyLAogICAgICAgICAgJzE3NCcgPT4gNiwKICAgICAgICAgICcyMTQnID0+ IDQsCiAgICAgICAgICAnMTMzJyA9PiA0LAogICAgICAgICAgJzE0OScgPT4gMywKICAgICAgICAg ICcxMjMnID0+IDQsCiAgICAgICAgICAnMjIxJyA9PiAyLAogICAgICAgICAgJzUwJyA9PiA3LAog ICAgICAgICAgJzM5JyA9PiAxLAogICAgICAgICAgJzIxMCcgPT4gMiwKICAgICAgICAgICc2NCcg PT4gMiwKICAgICAgICAgICc5NycgPT4gNSwKICAgICAgICAgICc0MScgPT4gNCwKICAgICAgICAg ICcxMicgPT4gNCwKICAgICAgICAgICc1MicgPT4gNCwKICAgICAgICAgICcxNzMnID0+IDEsCiAg ICAgICAgICAnNTYnID0+IDMsCiAgICAgICAgICAnMjI5JyA9PiAyLAogICAgICAgICAgJzY2JyA9 PiA0LAogICAgICAgICAgJzQ1JyA9PiA2LAogICAgICAgICAgJzE5JyA9PiA0LAogICAgICAgICAg JzU0JyA9PiA0LAogICAgICAgICAgJzIzNycgPT4gMiwKICAgICAgICAgICc3MCcgPT4gNCwKICAg ICAgICAgICcxODgnID0+IDQsCiAgICAgICAgICAnNjgnID0+IDQsCiAgICAgICAgICAnMTY2JyA9 PiAyLAogICAgICAgICAgJzEnID0+IDIsCiAgICAgICAgICAnMTM2JyA9PiA2LAogICAgICAgICAg JzExNicgPT4gOCwKICAgICAgICAgICc4OCcgPT4gMiwKICAgICAgICAgICczMCcgPT4gMiwKICAg ICAgICAgICcxNDEnID0+IDQsCiAgICAgICAgICAnMTQ0JyA9PiA1LAogICAgICAgICAgJzEwMCcg PT4gNCwKICAgICAgICAgICcyMjInID0+IDYsCiAgICAgICAgICAnMTI4JyA9PiAzLAogICAgICAg ICAgJzI1JyA9PiA1LAogICAgICAgICAgJzI1MicgPT4gMywKICAgICAgICAgICcyOCcgPT4gNSwK ICAgICAgICAgICcxMjAnID0+IDIsCiAgICAgICAgICAnNzUnID0+IDIsCiAgICAgICAgICAnODMn ID0+IDUsCiAgICAgICAgICAnNDAnID0+IDIsCiAgICAgICAgICAnMTM0JyA9PiA1LAogICAgICAg ICAgJzE1NicgPT4gNSwKICAgICAgICAgICcxOTInID0+IDYsCiAgICAgICAgICAnMjUwJyA9PiA4 LAogICAgICAgICAgJzU5JyA9PiA3LAogICAgICAgICAgJzIxNScgPT4gNCwKICAgICAgICAgICcy NTQnID0+IDMsCiAgICAgICAgICAnMTc3JyA9PiAyLAogICAgICAgICAgJzE1MCcgPT4gMywKICAg ICAgICAgICcxMzAnID0+IDMsCiAgICAgICAgICAnMTU1JyA9PiA0LAogICAgICAgICAgJzUzJyA9 PiA0LAogICAgICAgICAgJzIxNycgPT4gNiwKICAgICAgICAgICcyNDUnID0+IDQsCiAgICAgICAg ICAnMjM5JyA9PiA0LAogICAgICAgICAgJzEyMicgPT4gMSwKICAgICAgICAgICcxNDMnID0+IDYs CiAgICAgICAgICAnMjA1JyA9PiAyLAogICAgICAgICAgJzQyJyA9PiAzLAogICAgICAgICAgJzE1 OCcgPT4gNSwKICAgICAgICAgICcyMicgPT4gNCwKICAgICAgICAgICc0NicgPT4gOSwKICAgICAg ICAgICcyMTknID0+IDUsCiAgICAgICAgICAnMTMnID0+IDIsCiAgICAgICAgICAnMTA1JyA9PiAz LAogICAgICAgICAgJzIzNScgPT4gOSwKICAgICAgICAgICc2JyA9PiAxLAogICAgICAgICAgJzg1 JyA9PiA0LAogICAgICAgICAgJzE4NScgPT4gNSwKICAgICAgICAgICczJyA9PiA1LAogICAgICAg ICAgJzM2JyA9PiA1LAogICAgICAgICAgJzE4MycgPT4gNiwKICAgICAgICAgICc5NCcgPT4gNywK ICAgICAgICAgICcyMTMnID0+IDUsCiAgICAgICAgICAnMjQ4JyA9PiA1LAogICAgICAgICAgJzE0 NicgPT4gNCwKICAgICAgICAgICcxMTEnID0+IDUsCiAgICAgICAgICAnOScgPT4gNiwKICAgICAg ICAgICczOCcgPT4gNSwKICAgICAgICAgICc0JyA9PiA2LAogICAgICAgICAgJzM0JyA9PiA5LAog ICAgICAgICAgJzEzMicgPT4gMywKICAgICAgICAgICcxNjknID0+IDcsCiAgICAgICAgICAnMTY0 JyA9PiA2LAogICAgICAgICAgJzE5NicgPT4gNSwKICAgICAgICAgICcxNzEnID0+IDQsCiAgICAg ICAgICAnMjQyJyA9PiA1CiAgICAgICAgfTsK --------_425383F105F906134008_MULTIPART_MIXED_-- From didier@barvaux.org Wed Apr 6 01:04:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 01:05:05 -0700 (PDT) Received: from mail.b2i-toulouse.com (host.97.67.23.62.rev.coltfrance.com [62.23.67.97]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3684wdA012642 for ; Wed, 6 Apr 2005 01:04:59 -0700 Received: from catherine.b2i-toulouse.com ([62.23.67.99]) by mail.b2i-toulouse.com (8.12.5/8.12.5) with SMTP id j3684uZ3000508 for ; Wed, 6 Apr 2005 10:04:57 +0200 Date: Wed, 6 Apr 2005 10:04:01 +0200 From: Didier Barvaux To: netdev@oss.sgi.com Subject: [IPv6] policy routing ? Message-Id: <20050406100401.0eab9374.didier@barvaux.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 20:22:26 2005 on mail.b2i-toulouse.com X-Virus-Status: Clean X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: didier@barvaux.org Precedence: bulk X-list: netdev Hello, I'm trying to do policy routing with IPv6 (source routing) on a 2.6.11 kernel. It works perfectly well with IPv4 using iproute2 (iproute2-2.6.11-050330), but it doesn't seem to work with IPv6. # ip -6 rule add from fec0:6::/64 priority 2000 table 100 RTNETLINK answers: Invalid argument # echo $? 2 # ip -6 route add fec0:7::/64 via fec0:2::1 table 100 # echo $? 0 # ip -6 route show table 100 (no output) # ip -6 route show table main (snip) fec0:7::/64 via fec0:2::1 dev eth1 metric 1024 mtu 1500 advmss 1440 metric10 64 (snip) To add an IPv6 routing rule fails. To add an IPv6 route succeeds, but route is not added to the desired table ('main' instead of '100'). My kernel configuration contains: CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y I searched on the web and in the netdev archives without great success (I found some messages of guys with the same problem, but no solution/answer). Did I make a mistake ? Doesn't iproute2 manage IPv6 policy routing yet ? Or, is it a problem related to my 2.6 kernel configuration ? Could libnl be the solution ? Regards, Didier Barvaux From herbert@gondor.apana.org.au Wed Apr 6 01:33:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 01:33:56 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j368Xkcu014120 for ; Wed, 6 Apr 2005 01:33:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJ5yY-0006iG-00; Wed, 06 Apr 2005 18:33:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJ5y2-0003rF-00; Wed, 06 Apr 2005 18:32:54 +1000 From: Herbert Xu To: christoph@lameter.com (Christoph Lameter) Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 06 Apr 2005 18:32:54 +1000 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Christoph Lameter wrote: > > The atomic_dec_and_test is needed because as soon as the refcnt reaches > zero the dst entry may potentially be freed by the garbage collector. Thus > no future access to the dst entry is possible and the dec_and_test is the > only safe way to figure out if the counter reached zero. > > I hope I got it now. Thanks. Yep you're totally correct. In fact, the atomic_dec_and_test is really only needed for unhashed entries (i.e., IPsec). So we could do something like this so that all hashed entries undergo atomic_dec. This would only make sense if there were architectures where atomic_dec is significantly cheaper compared to atomic_dec_and_test. Do such beasts exist? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- --- linux-2.6/net/core/dst.c.orig 2005-04-06 18:29:00.000000000 +1000 +++ linux-2.6/net/core/dst.c 2005-04-06 18:26:46.000000000 +1000 @@ -197,20 +197,21 @@ kmem_cache_free(dst->ops->kmem_cachep, dst); dst = child; - if (dst) { - int nohash = dst->flags & DST_NOHASH; + if (!dst) + return NULL; + if (dst->flags & DST_NOHASH) { if (atomic_dec_and_test(&dst->__refcnt)) { /* We were real parent of this dst, so kill child. */ - if (nohash) - goto again; + goto again; } else { /* Child is still referenced, return it for freeing. */ - if (nohash) - return dst; - /* Child is still in his hash table */ + return dst; } } + + /* Child is still in his hash table or on the GC list. */ + atomic_dec(&dst->__refcnt); return NULL; } From pravins@calsoftinc.com Wed Apr 6 01:49:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 01:49:58 -0700 (PDT) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j368no2F015106 for ; Wed, 6 Apr 2005 01:49:51 -0700 Received: from [172.16.0.108] (unknown [172.16.0.108]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id 19C13DB58A; Wed, 6 Apr 2005 14:12:08 +0530 (IST) Message-ID: <4253A3A0.800@calsoftinc.com> Date: Wed, 06 Apr 2005 14:23:52 +0530 From: pravin b shelar User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christoph Lameter"@calsoftinc.com, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: Fwd: atomic_dec_and_test for child dst needed in dst_destroy? References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030904020801050603070305" X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravins@calsoftinc.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030904020801050603070305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > >This is racy (albeit very unlikely) because dst may be freed by >dst_run_gc after the atomic_dec. > >When we are not the real parent of the dst (e.g., when we're xfrm_dst >and the child is an rtentry), it may already be on the GC list. > >In fact the current code is buggy to, we need to check dst->flags >before the dec as dst may no longer be valid afterwards. > > > > This patch will remove the need for atomic_dec_and_test for this particular case. Now we can break down the atomic_dec_and_test to atomic_dec & atomic_read. Please comment. Regards Pravin. --------------030904020801050603070305 Content-Type: text/plain; name="dst-atomic" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dst-atomic" Index: linux-2.6.11-dsta/net/core/dst.c =================================================================== --- linux-2.6.11-dsta.orig/net/core/dst.c 2005-04-06 00:18:32.000000000 -0700 +++ linux-2.6.11-dsta/net/core/dst.c 2005-04-06 01:31:10.000000000 -0700 @@ -198,17 +198,19 @@ dst = child; if (dst) { - if (atomic_dec_and_test(&dst->__refcnt)) { - /* We were real parent of this dst, so kill child. */ - if (dst->flags&DST_NOHASH) - goto again; - } else { - /* Child is still referenced, return it for freeing. */ - if (dst->flags&DST_NOHASH) - return dst; - /* Child is still in his hash table */ + if (dst->flags&DST_NOHASH) { + atomic_dec(&dst->__refcnt); + if (atomic_read(&dst->__refcnt)) + /* Child is still referenced, return it for freeing. */ + return dst; + + /*We were real parent of this dst, so kill child. */ + goto again; } + else /* Child is still in his hash table */ + atomic_dec(&dst->__refcnt); } + return NULL; } --------------030904020801050603070305-- From uucp@ganesha.gnumonks.org Wed Apr 6 02:26:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 02:26:26 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j369QGLc016943 for ; Wed, 6 Apr 2005 02:26:17 -0700 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.34) id 1DJ6ne-0006BY-5c for netdev@oss.sgi.com; Wed, 06 Apr 2005 11:26:14 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1DIqRZ-00016q-00; Tue, 05 Apr 2005 17:58:21 +0200 Date: Tue, 5 Apr 2005 17:58:20 +0200 From: Harald Welte To: "Veeraiyan, Ayyappan" Cc: Harald Welte , Robert Olsson , netdev@oss.sgi.com Subject: Re: pktgen problem (skb refcount) in 2.6.12-rc1 Message-ID: <20050405155820.GB3261@obroa-skai.de.gnumonks.org> References: <9D602ABCE51B0B488BF857A4787939B5042E7396@orsmsx410> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JWEK1jqKZ6MHAcjA" Content-Disposition: inline In-Reply-To: <9D602ABCE51B0B488BF857A4787939B5042E7396@orsmsx410> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.11gm1 X-Date: Today is Setting Orange, the 22nd day of Discord in the YOLD 3171 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev --JWEK1jqKZ6MHAcjA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2005 at 10:26:18AM -0700, Veeraiyan, Ayyappan wrote: > Harald, >=20 > >=20 > > As for e1000 and or generic TX path changes, I don't have the time to > > review them now, sorry :( That's why I posted it to netdev, to let > > people who have an idea about the committed changes know that there is > > an issue. > > >=20 > What version of e1000 you are using?=20 as indicated before, I've observed the problem in 2.6.12-rc1. No modifications to e1000. So whatever is in 2.6.12-rc1, that's what showed the problems. > If you are using e1000 5.7.6-k2 and haven't tried older versions, Could > you please try e1000 version 5.6.10.1-k2 (available in kernel 2.6.11) > and inform us the result? I have tried a 2.6.11 kernel which works fine. I have not tested patching e1000 in 2.6.12-rc1 to go back to whatever was shipped in 2.6.11. I'll try to remember testing that once I'm back from my current business trip (friday), though > Thanks, > Ayyappan V. --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --JWEK1jqKZ6MHAcjA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCUrWcXaXGVTD0i/8RAnIeAKCswTwsBAWvq2ZPxu/8Xo8j3AwCRgCePcVM 2fCGl7IAUKVIl+jSZK2/EG0= =SnlO -----END PGP SIGNATURE----- --JWEK1jqKZ6MHAcjA-- From akpm@osdl.org Wed Apr 6 02:36:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 02:36:35 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j369aUo0017902 for ; Wed, 6 Apr 2005 02:36:31 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j369aCs4030051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 6 Apr 2005 02:36:17 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j369ZfMU020025; Wed, 6 Apr 2005 02:35:51 -0700 Date: Wed, 6 Apr 2005 02:35:15 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: yoann.allain@thomson.net Subject: Fw: [Bugme-new] [Bug 4449] New: IPSec tunnel forwarding problem Message-Id: <20050406023515.538d73c1.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1474 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 Begin forwarded message: Date: Wed, 6 Apr 2005 02:28:56 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4449] New: IPSec tunnel forwarding problem http://bugme.osdl.org/show_bug.cgi?id=4449 Summary: IPSec tunnel forwarding problem Kernel Version: 2.6.11-uml Status: NEW Severity: blocking Owner: shemminger@osdl.org Submitter: yoann.allain@thomson.net Distribution: Debian sarge Hardware Environment: x86 Software Environment: ipsec-tools-0.5 Problem Description: IP packets that should be forwarded after being decrypted out of a IPSec tunnel are not forwarded. Steps to reproduce: Lets take three hosts A B and C: B is the gateway between A and C. A<------->B<------->C First check that ping from A to C are working. If not check forwarding options in B. Then create an Ipsec tunnel between two hosts A and B. A<========>B<------->C Once the IPSec tunnel established, and iptables configured on B to print logs (for hooks Input Forward and Pre-Routing), try again to ping C from A. You should see that packets arrives to B in ESP format and goes to: hook ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From cranium2003@yahoo.com Wed Apr 6 04:33:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 04:33:52 -0700 (PDT) Received: from web41426.mail.yahoo.com (web41426.mail.yahoo.com [66.218.94.124]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j36BXjXN032188 for ; Wed, 6 Apr 2005 04:33:46 -0700 Received: (qmail 20997 invoked by uid 60001); 6 Apr 2005 11:33:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DHthjs8s3MO82lBUkjWNtUVxfeQhFMCknXkMpw2GQQfldICiyGRpzMMhQT06f2+ehsM5gYE4UwrsTjBc9w3UwGgnZOfHFj0vLOLiCtPkUuD/S1m/OSSaptKCR7mauGqtsCY+lL8BY/mNx/01aGMqgLD/XkNvfdlZM0QDKXxiY7o= ; Message-ID: <20050406113340.20995.qmail@web41426.mail.yahoo.com> Received: from [203.199.141.99] by web41426.mail.yahoo.com via HTTP; Wed, 06 Apr 2005 04:33:40 PDT Date: Wed, 6 Apr 2005 04:33:40 -0700 (PDT) From: cranium2003 Subject: kernel routing tables To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Hello, I want to know the structure where kernel stores kernel routing table. When i browse code i found fib_hash.c,fib_sematics.c and fib_frontend.c which contains functions to display routing table by /proc/net/route. I want to know is that possible for me to write a kernel module and take the instance of routing table and display whole routing table in my kernel module program? How to do that? does i use struct fib_info in my kernel modules and us it to print its contents as kernel routing table? regards, cranium. __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest From hadi@cyberus.ca Wed Apr 6 05:13:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 05:13:04 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36CCxr7003928 for ; Wed, 6 Apr 2005 05:12:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJ9Oy-0001rs-60 for netdev@oss.sgi.com; Wed, 06 Apr 2005 08:12:56 -0400 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 1DJ9Ov-00056r-Gj; Wed, 06 Apr 2005 08:12:53 -0400 Subject: Re: [RFC] QoS: new per flow queue From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050406123117.0265.LARK@linux.net.cn> References: <20050405224956.0258.LARK@linux.net.cn> <1112723858.1076.46.camel@jzny.localdomain> <20050406123117.0265.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112789570.1099.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2005 08:12:50 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1477 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: 4641 Lines: 111 Wang, On Wed, 2005-04-06 at 01:12, Wang Jian wrote: > Hi jamal, > > I know your concern. Actually, I first try to implement it like you > point out, but then I dismiss that scheme, because it is hard to > maintain for the userspace. > > But if the dynfwmark can dynamically alloc htb class in the given class > id range. For example > > tc filter ip u32 tc filter ip u32 match ip sport 80 0xffff flowid 1:12 \ > action dynfwmark major 1 range 1:1000 continue > Yes, this looks better except for the part - why do you need that? The syntax may have to explicitly say min 1 max 1000 for usability, but thats not a big deal. Essentially rewrite the classid/flowid. In the action just set skb->tc_classid and u32 will make sure the packet goes to the correct major:minor queue. This already works with kernels >= 2.6.10. > When it detects a new flow, it creates the necessary htb class? So the > userspace work is simple. But when we have segmented class id space, we > may not get such an enough empty range. > Yes, I thought about this too when i was responding to you earlier. Theres two ways to do it in my opinion: 1) create apriori at setup time 1024 or whatever number of HTB classes. So when u32 selects the major:minor its already there. OR 2) do what you are suggesting to dynamically create classes; i.e "classifier returned a non-existing class, create default class using that major/minor number". Default class could be defined from user space to be one that is initialized to 10 Kbps rate burst 1kbps etc. You may have to teach the qdisc the maximum number of classes it should create. #1 above will work immediately and you dont have to hack any of the qdiscs. The disadvantage is your user space app will have to create every class individualy - so if you have 1024 queues then 1024 queues are needed. #2 is nice because it avoids the above problem - disadvantage is you need to manage creation and deletion of these queues and write code. I do think the idea of dynamically creating the flow queues is interesting and useful as well. It would be nice if it can be done for all classful qdiscs. One thing i noticed is that you dont have multiple queues actually in your code - did i misread that? i.e multiple classes go to the same queue. > I think per flow control in nature means that classifier must be > intimately coupled with scheduler. There is no way around it. If you > seperate them, you must provide a way to link them together again. The > dynfwmark way you suggested actually does so, but not clean (because you > choose to use existing nfmark infrastructure). If it carries an unique > id or something like in its own namespace, then it can be clean and > friendly for userspace, but I bet it is unnecessarily bloated. > The only unfriendliness to user space is in #1 where you end up having a script creating as many classes as you need. It is _not_ bloat because you dont add any code at all. It is anti-bloat actually ;-> Look at above - and based on your suggestion; lets reset the flowid/classid. > In my test, HTB performs very well. I intensionally requires a HTB > class to enclose a perflow queue to provide guaranteed sum bandwidth. The > queue is proven to be fair enough and can guarantee rate internally for > its flows (if the per flow rate is at or above 10kbps). > Well, HTB is just a replica of the token bucket scheduler with additional knobs - so i suspect the numbers will look the same with TB as well. Someone needs to be test all of them and see how accurate they are. The clock sources at compile time and your hardware will also affect you. > I haven't tested rate lower than 10kbps, because my test client is not > that accurate to show the number. It's simply a "lftpget ". > > There are short threads before in which someone asked for a per flow > control solution, and was suggested to use HTB + SFQ. My test reveals > that SFQ is far away from fairness and can't meet the requirement of > bandwidth assurance. > I dont think SFQ will give you per flow; actually I should say - depends on your definition of flow - seems yours is the 5 tuple { src/dst IP, src/dst port, proto=UDP/TCP/SCTP}. SFQ will work for a subset of these tuples and is therefore not fair at the granularity that you want. > For HFSC, I haven't any experience with it because the documentation is > lacked. > I am suprised no one has compared all the rate control schemes. btw, would policing also suffice for you? The only difference is it will drop packets if you exceed your rate. You can also do hierachical sharing. cheers, jamal From hadi@cyberus.ca Wed Apr 6 05:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 05:16:41 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36CGbRT004555 for ; Wed, 6 Apr 2005 05:16:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJ9SU-0003wU-CY for netdev@oss.sgi.com; Wed, 06 Apr 2005 08:16:34 -0400 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 1DJ9SS-0005c1-AE; Wed, 06 Apr 2005 08:16:32 -0400 Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: Thomas Graf , netdev In-Reply-To: <20050406143842.026B.LARK@linux.net.cn> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112789789.1097.40.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2005 08:16:29 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1478 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: 192 Lines: 14 On Wed, 2005-04-06 at 02:45, Wang Jian wrote: > The test result looks not good. See attached file. > Yes, that doesnt look too good. > So let's find a better way. Thomas? cheers, jamal From tgraf@suug.ch Wed Apr 6 05:30:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 05:30:30 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36CULJY006348 for ; Wed, 6 Apr 2005 05:30:22 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 81D328A; Wed, 6 Apr 2005 14:29:56 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id B89E11C0EA; Wed, 6 Apr 2005 14:30:36 +0200 (CEST) Date: Wed, 6 Apr 2005 14:30:36 +0200 From: Thomas Graf To: Wang Jian Cc: hadi@cyberus.ca, netdev Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050406123036.GO26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050406143842.026B.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1641 Lines: 38 * Wang Jian <20050406143842.026B.LARK@linux.net.cn> 2005-04-06 14:45 > On 05 Apr 2005 12:11:35 -0400, jamal wrote: > > i.e if you fed the jenkins hash with 256 buckets - lets pick the number 1024 > > samples of the data you showed earlier for how fwmark looks like, > > how well would the result look like. > > And what if you fed it with something like 1024 incremental fwmark from > > say 1..1024? > > > > The test result looks not good. See attached file. > > So let's find a better way. We need to provide some kind of option to the user so he can specify the needs. The & 0xFF will suit most just fine but has one essential drawback which is that no distribution is done at all if the lower 8 bits are set to 0. For static marks this is no issue at all and even for enumerated marks growing it takes quite some time to grow into an area where it starts hurting. The problem obviously is if someone splits the mark field into 2 parts and uses the upper 16 bits for some special purpose just like you did. In such as case it would make sense to either take all bits into account or let the user specify a bitmask + shift. So here is the same idea I posted before but revised: Let the user specify one of the hash tables via a new TLV: - default: & 0xFF - ((mark & mask) >> shift) & 0xFF - jenkins for 16, 32, and 64 bits - FNV for 16, 32, and 64 bits Why variations for type sizes? The chance of collisions reduces a lot if the user exactly knows he'll never use more than 16bits but 255 marks are not enough. I'm cooking up a patch for this today together with a fix to allow 64bit values for the mark. From lark@linux.net.cn Wed Apr 6 06:01:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:02:00 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36D1mMT007775 for ; Wed, 6 Apr 2005 06:01:50 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id F3A5A3ED42; Wed, 6 Apr 2005 21:01:42 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 25723-02-9; Wed, 6 Apr 2005 21:01:38 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 5D1143EC0B; Wed, 6 Apr 2005 21:01:38 +0800 (CST) Date: Wed, 06 Apr 2005 21:01:38 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: hadi@cyberus.ca, netdev In-Reply-To: <20050406123036.GO26731@postel.suug.ch> References: <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> Message-Id: <20050406205943.0290.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 1907 Lines: 51 Hi Thomas Graf, On Wed, 6 Apr 2005 14:30:36 +0200, Thomas Graf wrote: > * Wang Jian <20050406143842.026B.LARK@linux.net.cn> 2005-04-06 14:45 > > On 05 Apr 2005 12:11:35 -0400, jamal wrote: > > > i.e if you fed the jenkins hash with 256 buckets - lets pick the number 1024 > > > samples of the data you showed earlier for how fwmark looks like, > > > how well would the result look like. > > > And what if you fed it with something like 1024 incremental fwmark from > > > say 1..1024? > > > > > > > The test result looks not good. See attached file. > > > > So let's find a better way. > > We need to provide some kind of option to the user so he can specify > the needs. The & 0xFF will suit most just fine but has one essential > drawback which is that no distribution is done at all if the lower 8 > bits are set to 0. For static marks this is no issue at all and even > for enumerated marks growing it takes quite some time to grow into > an area where it starts hurting. The problem obviously is if someone > splits the mark field into 2 parts and uses the upper 16 bits for > some special purpose just like you did. In such as case it would make > sense to either take all bits into account or let the user specify > a bitmask + shift. > > So here is the same idea I posted before but revised: > > Let the user specify one of the hash tables via a new TLV: > - default: & 0xFF > - ((mark & mask) >> shift) & 0xFF > - jenkins for 16, 32, and 64 bits > - FNV for 16, 32, and 64 bits > > Why variations for type sizes? The chance of collisions reduces > a lot if the user exactly knows he'll never use more than 16bits > but 255 marks are not enough. > > I'm cooking up a patch for this today together with a fix to > allow 64bit values for the mark. Given that no 1-hash-fit-all solution exists, I think your solution is quite elegant. -- lark From hadi@cyberus.ca Wed Apr 6 06:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:29:22 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36DTDwA009134 for ; Wed, 6 Apr 2005 06:29:13 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJAak-0004O3-4I for netdev@oss.sgi.com; Wed, 06 Apr 2005 09:29:10 -0400 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 1DJAaf-0006bm-JF; Wed, 06 Apr 2005 09:29:05 -0400 Subject: PATCH: Allow Simple actions WAS(Re: patch: introduce simple actions From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: kaber@trash.net, netdev , tgraf@suug.ch In-Reply-To: <1111550799.1116.28.camel@jzny.localdomain> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> <20050322195827.5ecd0c33.davem@davemloft.net> <1111550799.1116.28.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-kbyROQh80Y7V+WN2x4yB" Organization: jamalopolous Message-Id: <1112794142.1098.56.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2005 09:29:02 -0400 X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1481 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: 9639 Lines: 371 --=-kbyROQh80Y7V+WN2x4yB Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-03-22 at 23:06, Jamal Hadi Salim wrote: > On Tue, 2005-03-22 at 22:58, David S. Miller wrote: > > I'm waiting for this, send whenever it's ready. > > > > I will tommorow - need to plonk tonight That was some plonk ;-> Anyways, here it is with suggestions incorporated. I could probably split it into two patches one for the base and the other for the simple action. Let me know if you want me to do this. description: -Allow simple actions -introduce a simple action example to demonstrate usage signed off by: Jamal Hadi Salim cheers, jamal --=-kbyROQh80Y7V+WN2x4yB Content-Disposition: attachment; filename=simp_p Content-Type: text/plain; name=simp_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- /dev/null 2005-04-06 08:24:31.814336808 -0400 +++ b/include/net/act_generic.h 2005-04-06 08:51:52.000000000 -0400 @@ -0,0 +1,142 @@ +/* + * include/net/act_generic.h + * +*/ +#ifndef ACT_GENERIC_H +#define ACT_GENERIC_H +static inline int tcf_defact_release(struct tcf_defact *p, int bind) +{ + int ret = 0; + if (p) { + if (bind) { + p->bindcnt--; + } + p->refcnt--; + if (p->bindcnt <= 0 && p->refcnt <= 0) { + kfree(p->defdata); + tcf_hash_destroy(p); + ret = 1; + } + } + return ret; +} + +static inline int +alloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + p->defdata = kmalloc(datalen, GFP_KERNEL); + if (p->defdata == NULL) + return -ENOMEM; + p->datalen = datalen; + memcpy(p->defdata, defdata, datalen); + return 0; +} + +static inline int +realloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + /* safer to be just brute force for now */ + kfree(p->defdata); + return alloc_defdata(p, datalen, defdata); +} + +static inline int +tcf_defact_init(struct rtattr *rta, struct rtattr *est, + struct tc_action *a, int ovr, int bind) +{ + struct rtattr *tb[TCA_DEF_MAX]; + struct tc_defact *parm; + struct tcf_defact *p; + void *defdata; + u32 datalen = 0; + int ret = 0; + + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) + return -EINVAL; + + if (tb[TCA_DEF_PARMS - 1] == NULL || + RTA_PAYLOAD(tb[TCA_DEF_PARMS - 1]) < sizeof(*parm)) + return -EINVAL; + + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); + defdata = RTA_DATA(tb[TCA_DEF_DATA - 1]); + if (defdata == NULL) + return -EINVAL; + + datalen = RTA_PAYLOAD(tb[TCA_DEF_DATA - 1]); + if (datalen <= 0) + return -EINVAL; + + p = tcf_hash_check(parm->index, a, ovr, bind); + if (p == NULL) { + p = tcf_hash_create(parm->index, est, a, sizeof(*p), ovr, bind); + if (p == NULL) + return -ENOMEM; + + ret = alloc_defdata(p, datalen, defdata); + if (ret < 0) { + kfree(p); + return ret; + } + ret = ACT_P_CREATED; + } else { + if (!ovr) { + tcf_defact_release(p, bind); + return -EEXIST; + } + realloc_defdata(p, datalen, defdata); + } + + spin_lock_bh(&p->lock); + p->action = parm->action; + spin_unlock_bh(&p->lock); + if (ret == ACT_P_CREATED) + tcf_hash_insert(p); + return ret; +} + +static inline int tcf_defact_cleanup(struct tc_action *a, int bind) +{ + struct tcf_defact *p = PRIV(a, defact); + + if (p != NULL) + return tcf_defact_release(p, bind); + return 0; +} + +static inline int +tcf_defact_dump(struct sk_buff *skb, struct tc_action *a, int bind, int ref) +{ + unsigned char *b = skb->tail; + struct tc_defact opt; + struct tcf_defact *p = PRIV(a, defact); + struct tcf_t t; + + opt.index = p->index; + opt.refcnt = p->refcnt - ref; + opt.bindcnt = p->bindcnt - bind; + opt.action = p->action; + RTA_PUT(skb, TCA_DEF_PARMS, sizeof(opt), &opt); + RTA_PUT(skb, TCA_DEF_DATA, p->datalen, p->defdata); + t.install = jiffies_to_clock_t(jiffies - p->tm.install); + t.lastuse = jiffies_to_clock_t(jiffies - p->tm.lastuse); + t.expires = jiffies_to_clock_t(p->tm.expires); + RTA_PUT(skb, TCA_DEF_TM, sizeof(t), &t); + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +#define tca_use_default_ops \ + .dump = tcf_defact_dump, \ + .cleanup = tcf_defact_cleanup, \ + .init = tcf_defact_init, \ + .walk = tcf_generic_walker, \ + +#define tca_use_default_defines(name) \ + static u32 idx_gen; \ + static struct tcf_defact *tcf_##name_ht[MY_TAB_SIZE]; \ + static DEFINE_RWLOCK(##name_lock); +#endif /* _NET_ACT_GENERIC_H */ --- /dev/null 2005-04-06 08:24:31.814336808 -0400 +++ b/include/net/tc_act/tc_defact.h 2005-04-06 08:38:47.000000000 -0400 @@ -0,0 +1,13 @@ +#ifndef __NET_TC_DEF_H +#define __NET_TC_DEF_H + +#include + +struct tcf_defact +{ + tca_gen(defact); + u32 datalen; + void *defdata; +}; + +#endif --- /dev/null 2005-04-06 08:24:31.814336808 -0400 +++ b/include/linux/tc_act/tc_defact.h 2005-04-06 08:38:47.000000000 -0400 @@ -0,0 +1,21 @@ +#ifndef __LINUX_TC_DEF_H +#define __LINUX_TC_DEF_H + +#include + +struct tc_defact +{ + tc_gen; +}; + +enum +{ + TCA_DEF_UNSPEC, + TCA_DEF_TM, + TCA_DEF_PARMS, + TCA_DEF_DATA, + __TCA_DEF_MAX +}; +#define TCA_DEF_MAX (__TCA_DEF_MAX - 1) + +#endif --- /dev/null 2005-04-06 08:24:31.814336808 -0400 +++ b/net/sched/simple.c 2005-04-06 08:53:31.000000000 -0400 @@ -0,0 +1,107 @@ +/* + * net/sched/simp.c Simple example of an action + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Jamal Hadi Salim (2005) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TCA_ACT_SIMP 22 + +/* XXX: Hide all these common elements under some macro + * probably +*/ +#include +#include + +/* use generic hash table with 8 buckets */ +#define MY_TAB_SIZE 8 +#define MY_TAB_MASK (MY_TAB_SIZE - 1) +static u32 idx_gen; +static struct tcf_defact *tcf_simp_ht[MY_TAB_SIZE]; +static DEFINE_RWLOCK(simp_lock); + +/* override the defaults */ +#define tcf_st tcf_defact +#define tc_st tc_defact +#define tcf_t_lock simp_lock +#define tcf_ht tcf_simp_ht + +#define CONFIG_NET_ACT_INIT 1 +#include +#include + +static int tcf_simp(struct sk_buff **pskb, struct tc_action *a) +{ + struct sk_buff *skb = *pskb; + struct tcf_defact *p = PRIV(a, defact); + + spin_lock(&p->lock); + p->tm.lastuse = jiffies; + p->bstats.bytes += skb->len; + p->bstats.packets++; + + /* print policy string followed by _ then packet count + * Example if this was the 3rd packet and the string was "hello" + * then it would look like "hello_3" (without quotes) + **/ + printk("simple: %s_%d\n", (char *)p->defdata, p->bstats.packets); + spin_unlock(&p->lock); + return p->action; +} + +static struct tc_action_ops act_simp_ops = { + .kind = "simple", + .type = TCA_ACT_SIMP, + .capab = TCA_CAP_NONE, + .owner = THIS_MODULE, + .act = tcf_simp, + tca_use_default_ops +}; + +MODULE_AUTHOR("Jamal Hadi Salim(2005)"); +MODULE_DESCRIPTION("Simple example action"); +MODULE_LICENSE("GPL"); + +static int __init simp_init_module(void) +{ + int ret = tcf_register_action(&act_simp_ops); + if (!ret) + printk("Simple TC action Loaded\n"); + return ret; +} + +static void __exit simp_cleanup_module(void) +{ + tcf_unregister_action(&act_simp_ops); +} + +module_init(simp_init_module); +module_exit(simp_cleanup_module); --- b/net/sched/Kconfig 2005/04/06 12:58:03 1.1 +++ b/net/sched/Kconfig 2005/04/06 13:04:03 @@ -506,3 +506,13 @@ Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. +config NET_ACT_SIMP + tristate "Simple action" + depends on NET_CLS_ACT + ---help--- + You must have new iproute2 to use this feature. + This adds a very simple action for demonstration purposes + The idea is to give action authors a basic example to look at. + All this action will do is print on the console the configured + policy string followed by _ then packet count. + --- b/net/sched/Makefile 2005/04/06 13:10:39 1.1 +++ b/net/sched/Makefile 2005/04/06 13:12:25 @@ -6,13 +6,14 @@ obj-$(CONFIG_NET_SCHED) += sch_api.o sch_fifo.o obj-$(CONFIG_NET_CLS) += cls_api.o -obj-$(CONFIG_NET_CLS_ACT) += act_api.o +obj-$(CONFIG_NET_CLS_ACT) += act_api.o obj-$(CONFIG_NET_ACT_POLICE) += police.o obj-$(CONFIG_NET_CLS_POLICE) += police.o -obj-$(CONFIG_NET_ACT_GACT) += gact.o -obj-$(CONFIG_NET_ACT_MIRRED) += mirred.o -obj-$(CONFIG_NET_ACT_IPT) += ipt.o -obj-$(CONFIG_NET_ACT_PEDIT) += pedit.o +obj-$(CONFIG_NET_ACT_GACT) += gact.o +obj-$(CONFIG_NET_ACT_MIRRED) += mirred.o +obj-$(CONFIG_NET_ACT_IPT) += ipt.o +obj-$(CONFIG_NET_ACT_PEDIT) += pedit.o +obj-$(CONFIG_NET_ACT_SIMP) += simple.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o --=-kbyROQh80Y7V+WN2x4yB-- From hadi@cyberus.ca Wed Apr 6 06:34:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:34:33 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36DYSAc009805 for ; Wed, 6 Apr 2005 06:34:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DJAfm-0003Kq-0E for netdev@oss.sgi.com; Wed, 06 Apr 2005 07:34:22 -0600 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 1DJAfm-0007mo-PK; Wed, 06 Apr 2005 09:34:23 -0400 Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Wang Jian , netdev In-Reply-To: <20050406123036.GO26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112794459.1096.61.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2005 09:34:19 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1482 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: 535 Lines: 20 On Wed, 2005-04-06 at 08:30, Thomas Graf wrote: > Let the user specify one of the hash tables via a new TLV: > - default: & 0xFF > - ((mark & mask) >> shift) & 0xFF > - jenkins for 16, 32, and 64 bits > - FNV for 16, 32, and 64 bits When does the user specify this? i would think you need to set it once only per bootup. After that it will be quiet complex to reset. It could be done but sounds complex and unnecessary. i.e it may be a boot or module parameter more than it is a netlink controlled value, no? cheers, jamal From emann@mrv.com Wed Apr 6 06:34:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:35:02 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36DYrEe009850 for ; Wed, 6 Apr 2005 06:34:54 -0700 Received: from [194.90.139.38] by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA2038; Wed, 6 Apr 2005 15:40:06 +0200 Message-ID: <4253E5D4.60504@mrv.com> Date: Wed, 06 Apr 2005 16:36:20 +0300 From: emann@mrv.com (Eran Mann) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf CC: Wang Jian , hadi@cyberus.ca, netdev Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> In-Reply-To: <20050406123036.GO26731@postel.suug.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev Content-Length: 1498 Lines: 43 Thomas Graf wrote: > We need to provide some kind of option to the user so he can specify > the needs. The & 0xFF will suit most just fine but has one essential > drawback which is that no distribution is done at all if the lower 8 > bits are set to 0. For static marks this is no issue at all and even > for enumerated marks growing it takes quite some time to grow into > an area where it starts hurting. The problem obviously is if someone > splits the mark field into 2 parts and uses the upper 16 bits for > some special purpose just like you did. In such as case it would make > sense to either take all bits into account or let the user specify > a bitmask + shift. > > So here is the same idea I posted before but revised: > > Let the user specify one of the hash tables via a new TLV: > - default: & 0xFF > - ((mark & mask) >> shift) & 0xFF > - jenkins for 16, 32, and 64 bits > - FNV for 16, 32, and 64 bits > > Why variations for type sizes? The chance of collisions reduces > a lot if the user exactly knows he'll never use more than 16bits > but 255 marks are not enough. > > I'm cooking up a patch for this today together with a fix to > allow 64bit values for the mark. > Maybe you could add to the list of options a XOR of bytes hash, something like: static inline u8 bytes_xor_u32( u32 key ) { u8 *dummy_array = (u8 *)&key; u8 hash = dummy_array[0] ^ dummy_array[1] ^ dummy_array[2] ^ dummy_array[3]; return hash; } -- Eran Mann MRV International www.mrv.com From tgraf@suug.ch Wed Apr 6 06:44:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:44:47 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36DigCC011180 for ; Wed, 6 Apr 2005 06:44:42 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id ECC148A; Wed, 6 Apr 2005 15:44:18 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 33D7C1C0EA; Wed, 6 Apr 2005 15:45:02 +0200 (CEST) Date: Wed, 6 Apr 2005 15:45:02 +0200 From: Thomas Graf To: jamal Cc: Wang Jian , netdev Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050406134502.GP26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112794459.1096.61.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 739 Lines: 16 * jamal <1112794459.1096.61.camel@jzny.localdomain> 2005-04-06 09:34 > On Wed, 2005-04-06 at 08:30, Thomas Graf wrote: > > > Let the user specify one of the hash tables via a new TLV: > > - default: & 0xFF > > - ((mark & mask) >> shift) & 0xFF > > - jenkins for 16, 32, and 64 bits > > - FNV for 16, 32, and 64 bits > > When does the user specify this? i would think you need to set it once > only per bootup. After that it will be quiet complex to reset. It could > be done but sounds complex and unnecessary. i.e it may be a boot or > module parameter more than it is a netlink controlled value, no? I'm not 100% sure about this yet but I think during fw_change so we can have different hashes for different qdiscs filter chains. From lark@linux.net.cn Wed Apr 6 06:45:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:45:35 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36DjOEB011230 for ; Wed, 6 Apr 2005 06:45:25 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id BCC193ED42; Wed, 6 Apr 2005 21:45:22 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 26362-01-14; Wed, 6 Apr 2005 21:45:17 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 557EA3EC0B; Wed, 6 Apr 2005 21:45:17 +0800 (CST) Date: Wed, 06 Apr 2005 21:45:17 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [RFC] QoS: new per flow queue Cc: netdev In-Reply-To: <1112789570.1099.37.camel@jzny.localdomain> References: <20050406123117.0265.LARK@linux.net.cn> <1112789570.1099.37.camel@jzny.localdomain> Message-Id: <20050406210800.0296.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 6803 Lines: 177 Hi jamal, On 06 Apr 2005 08:12:50 -0400, jamal wrote: > Wang, > > On Wed, 2005-04-06 at 01:12, Wang Jian wrote: > > Hi jamal, > > > > I know your concern. Actually, I first try to implement it like you > > point out, but then I dismiss that scheme, because it is hard to > > maintain for the userspace. > > > > But if the dynfwmark can dynamically alloc htb class in the given class > > id range. For example > > > > tc filter ip u32 tc filter ip u32 match ip sport 80 0xffff flowid 1:12 \ > > action dynfwmark major 1 range 1:1000 continue > > > > Yes, this looks better except for the part - why do you > need that? The syntax may have to explicitly say min 1 max 1000 for > usability, but thats not a big deal. The is used to dynamically create htb class, see below. > Essentially rewrite the classid/flowid. In the action just set > skb->tc_classid and u32 will make sure the packet goes to the correct > major:minor queue. This already works with kernels >= 2.6.10. > One question: Can I set skb->tc_classid in a qdisc and pass this skb to the specified class to handle? > > When it detects a new flow, it creates the necessary htb class? So the > > userspace work is simple. But when we have segmented class id space, we > > may not get such an enough empty range. > > > > Yes, I thought about this too when i was responding to you earlier. > Theres two ways to do it in my opinion: > 1) create apriori at setup time 1024 or whatever number of HTB classes. > So when u32 selects the major:minor its already there. > OR > 2) do what you are suggesting to dynamically create classes; i.e > "classifier returned a non-existing class, create default class > using that major/minor number". > Default class could be defined from user space to be one that is > initialized to 10 Kbps rate burst 1kbps etc. You may have to teach the > qdisc the maximum number of classes it should create. > > #1 above will work immediately and you dont have to hack any of the > qdiscs. The disadvantage is your user space app will have to > create every class individualy - so if you have 1024 queues then 1024 > queues are needed. > #2 is nice because it avoids the above problem - disadvantage is you > need to manage creation and deletion of these queues and write code. > My idea is that the action itself dynamically creates classes. So you don't need any other rules. It is looks like #2 but the work is done in dynfwmark action. The workflow 0. setup, and create flow entry hash; 1. when a packet arrives, check if it is a flow or should be a new flow; 2. alloc a class id for this flow; 3. dynamically create a htb class using the 4. skb->tc_classid = allocated_ht_class_id 1.5 if can't create flow, skb->tc_classid = default_class_id > I do think the idea of dynamically creating the flow queues is > interesting and useful as well. It would be nice if it can be done for > all classful qdiscs. > > One thing i noticed is that you dont have multiple queues actually in > your code - did i misread that? i.e multiple classes go to the same > queue. > Didn't you notice that it is a classless qdisc? The queue is per qdisc, not per class :) It is the parent class's duty to define what kind of flow this qdisc handle. It is very generic, you can even mix UDP/TCP flows together but I don't think it is good idea. Think the scenario 1. You have VoIP flows (UDP) 2. You have pptp vpn flows (eh, per flow can't handle it at this time, I think) You create HTBs for them, and use filter to classify them. And then, use per flow qdisc as the only child of these HTBs. per flow qdisc will guarantee the per flow QoS. > > > I think per flow control in nature means that classifier must be > > intimately coupled with scheduler. There is no way around it. If you > > seperate them, you must provide a way to link them together again. The > > dynfwmark way you suggested actually does so, but not clean (because you > > choose to use existing nfmark infrastructure). If it carries an unique > > id or something like in its own namespace, then it can be clean and > > friendly for userspace, but I bet it is unnecessarily bloated. > > > > The only unfriendliness to user space is in #1 where you end up having a > script creating as many classes as you need. It is _not_ bloat because > you dont add any code at all. It is anti-bloat actually ;-> > In this way, it is very hard to write good user interface in userspace. My current implementation takes good user-friendly (or user space scripter/programmer friendly) into serious consideration. The 'bloated' comment is on the "If it carries an unique id or something like in its own namespace, then it can be clean and friendly for userspace" I think too much and my thought is jumpy ;) You even didn't notice that I gave another suggestion on implementation in this sentence. > Look at above - and based on your suggestion; lets reset the > flowid/classid. > > > In my test, HTB performs very well. I intensionally requires a HTB > > class to enclose a perflow queue to provide guaranteed sum bandwidth. The > > queue is proven to be fair enough and can guarantee rate internally for > > its flows (if the per flow rate is at or above 10kbps). > > > > Well, HTB is just a replica of the token bucket scheduler with > additional knobs - so i suspect the numbers will look the same with TB > as well. Someone needs to be test all of them and see how accurate they > are. The clock sources at compile time and your hardware will also > affect you. > > > I haven't tested rate lower than 10kbps, because my test client is not > > that accurate to show the number. It's simply a "lftpget ". > > > > There are short threads before in which someone asked for a per flow > > control solution, and was suggested to use HTB + SFQ. My test reveals > > that SFQ is far away from fairness and can't meet the requirement of > > bandwidth assurance. > > > > I dont think SFQ will give you per flow; actually I should say - depends > on your definition of flow - seems yours is the 5 tuple { src/dst IP, > src/dst port, proto=UDP/TCP/SCTP}. SFQ will work for a subset of these > tuples and is therefore not fair at the granularity that you want. > > > For HFSC, I haven't any experience with it because the documentation is > > lacked. > > > > I am suprised no one has compared all the rate control schemes. > > btw, would policing also suffice for you? The only difference is it will > drop packets if you exceed your rate. You can also do hierachical > sharing. policy suffices, but doesn't serve the purpose of per flow queue. And thanks for your discussion with me. It seems that few people is interested in it. -- lark From lark@linux.net.cn Wed Apr 6 06:54:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 06:54:08 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36Ds0CS012545 for ; Wed, 6 Apr 2005 06:54:02 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 6A57B3ED42; Wed, 6 Apr 2005 21:53:58 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 26362-01-32; Wed, 6 Apr 2005 21:53:56 +0800 (CST) Received: from [192.168.0.120] (unknown [61.51.151.86]) by mx.linux.net.cn (Postfix) with ESMTP id 1E8EB3EC0B; Wed, 6 Apr 2005 21:53:56 +0800 (CST) Date: Wed, 06 Apr 2005 21:53:55 +0800 From: Wang Jian To: emann@mrv.com (Eran Mann) Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Cc: Thomas Graf , hadi@cyberus.ca, netdev In-Reply-To: <4253E5D4.60504@mrv.com> References: <20050406123036.GO26731@postel.suug.ch> <4253E5D4.60504@mrv.com> Message-Id: <20050406214848.029A.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 595 Lines: 31 Hi Eran Mann, On Wed, 06 Apr 2005 16:36:20 +0300, emann@mrv.com (Eran Mann) wrote: > > Maybe you could add to the list of options a XOR of bytes hash, > something like: > static inline u8 bytes_xor_u32( u32 key ) > { > u8 *dummy_array = (u8 *)&key; > u8 hash = dummy_array[0] ^ dummy_array[1] ^ > dummy_array[2] ^ dummy_array[3]; > > return hash; > } > Ha, then this hi-or-lo word hash, which assumes that high or low word is 0, and key is distributed in the old fashion (0..255, etc) static inline u32 hi_or_lo_hash(u32 key) { return (key >> 16 ^ key) & 0xFF; } -- lark From tgraf@suug.ch Wed Apr 6 07:10:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 07:10:07 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36EA1hf013760 for ; Wed, 6 Apr 2005 07:10:01 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 4F0C58B; Wed, 6 Apr 2005 16:09:38 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 75C5E1C0EA; Wed, 6 Apr 2005 16:10:20 +0200 (CEST) Date: Wed, 6 Apr 2005 16:10:20 +0200 From: Thomas Graf To: jamal Cc: Wang Jian , netdev Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050406141020.GQ26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050406134502.GP26731@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 904 Lines: 15 * Thomas Graf <20050406134502.GP26731@postel.suug.ch> 2005-04-06 15:45 > * jamal <1112794459.1096.61.camel@jzny.localdomain> 2005-04-06 09:34 > > When does the user specify this? i would think you need to set it once > > only per bootup. After that it will be quiet complex to reset. It could > > be done but sounds complex and unnecessary. i.e it may be a boot or > > module parameter more than it is a netlink controlled value, no? > > I'm not 100% sure about this yet but I think during fw_change so > we can have different hashes for different qdiscs filter chains. The thing I'm worrying about is that I don't want to break the perfect alignment of fw_head to good slab obj sizes but I guess there is no way around. I'd really like to make hash size and hash function configureable. For example a hash size of 1024 would perform much better and would still fit into a single page on most systems. From vanco@satro.sk Wed Apr 6 07:27:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 07:27:29 -0700 (PDT) Received: from mail.satronet.sk (mail.satronet.sk [217.144.16.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36ERNEq014801 for ; Wed, 6 Apr 2005 07:27:23 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.satronet.sk (Postfix) with ESMTP id EE7AF1604FE00 for ; Wed, 6 Apr 2005 16:27:21 +0200 (CEST) Received: from mail.satronet.sk ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23018-02 for ; Wed, 6 Apr 2005 16:27:21 +0200 (CEST) Received: from [147.175.51.163] (unknown [147.175.51.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.satronet.sk (Postfix) with ESMTP id E166816050717 for ; Wed, 6 Apr 2005 16:27:20 +0200 (CEST) Message-ID: <4253F1C5.2090203@satro.sk> Date: Wed, 06 Apr 2005 16:27:17 +0200 From: Michal Vanco Organization: Satro, s.r.o. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: e1000 packet corruption problem X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B8D84CEE253ECADAA3D4E31" X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Scanned: by ANTIvirus at satronet.sk X-Virus-Status: Clean X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vanco@satro.sk Precedence: bulk X-list: netdev Content-Length: 1081 Lines: 37 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B8D84CEE253ECADAA3D4E31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I've made some more testing. This one was pretty surprising: >From 192.168.0.2: # sudo ping 192.168.0.1 -p fefffefffefffeff -i 0.01 -c 100 100 packets transmitted, 100 received, 0% packet loss, time 901ms # sudo ping 192.168.0.1 -p fffefffefffefffe -i 0.01 -c 100 100 packets transmitted, 18 received, 82% packet loss, time 1068ms Any ideas of how to solve this? regards, michal --------------enig4B8D84CEE253ECADAA3D4E31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCU/HI2/VqJwUsLAMRAovXAKCmFiyuXZJ1Xd1oO43U94V5zorX0QCeMJ7b w16LIMIw8AibB+fZ4KOdCp8= =aRIa -----END PGP SIGNATURE----- --------------enig4B8D84CEE253ECADAA3D4E31-- From dmitry_yus@yahoo.com Wed Apr 6 08:16:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 08:16:51 -0700 (PDT) Received: from smtp103.mail.sc5.yahoo.com (smtp103.mail.sc5.yahoo.com [66.163.169.222]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j36FGkrS032208 for ; Wed, 6 Apr 2005 08:16:47 -0700 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp103.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 15:16:46 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050406060343.GA14059@gondor.apana.org.au> References: <1112766901.7488.16.camel@mylaptop> <20050406060343.GA14059@gondor.apana.org.au> Content-Type: text/plain Date: Wed, 06 Apr 2005 08:16:42 -0700 Message-Id: <1112800602.9213.27.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1731 Lines: 36 On Wed, 2005-04-06 at 16:03 +1000, Herbert Xu wrote: > On Tue, Apr 05, 2005 at 10:55:01PM -0700, Dmitry Yusupov wrote: > > > > main reason for this is to have clear way to notify netlink user that > > new socket created and bound. > > Why do you want to exclude sockets that listen to multicast > messages? They can still do unicast transactions. this probably makes sense. I didn't do that intentionally, all I wanted is to have the clean way to initialize control structures in proper time - NETLINK_UESTABLISHED so it will work with my application. If you want to extent change for multicast - feel free. > > one reason is for consistency with sock interface. sk_allocation is > > equal to GFP_KERNEL by default, so nothing changed. but. in some cases > > application might require non-blocking kmalloc behavior. one real life > > example is networking block device used for swap partition. this way any > > GFP_KERENL allocation on recovery path might lead to deadlock condition. > > Setting of sk_allocation is controlled by the protocol itself. In this > case this is af_netlink.c. As you can see, we never set this to anything > other than GFP_KERNEL. > > Using sk_allocation will only confuse those who are not familiar with > netlink into thinking that this can be atomic. I don't think so. It is not clean enough to call alloc_skb() with hard- coded vm priority. And it limits netlink in the way I described before. If we want to defer critical processing to the user-space(like number of applications includes: iscsi, lvm, multipath, fuse...), this change is essential. Having GFP_KERNEL hard-coded will lead to deadlock on "down" calls in some cases. So, we do need this change to make a progress. > Cheers, From cndougla@purdue.edu Wed Apr 6 08:37:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 08:37:41 -0700 (PDT) Received: from mailhub128.itcs.purdue.edu (mailhub128.itcs.purdue.edu [128.210.5.128]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36FbaUT004255 for ; Wed, 6 Apr 2005 08:37:37 -0700 Received: from localhost (mailhub199.itcs.purdue.edu [128.210.5.199]) by mailhub128.itcs.purdue.edu (8.13.3/8.13.3/avscan-smtp) with ESMTP id j36FbUH9012537; Wed, 6 Apr 2005 10:37:30 -0500 Received: from cary-d-067.resnet.purdue.edu (cary-d-067.resnet.purdue.edu [128.211.250.67]) by webmail.purdue.edu (IMP) with HTTP for ; Wed, 6 Apr 2005 10:37:30 -0500 Message-ID: <1112801850.4254023a192c5@webmail.purdue.edu> Date: Wed, 6 Apr 2005 10:37:30 -0500 From: Chase Douglas To: netdev@oss.sgi.com, cndougla@purdue.edu Subject: Beginner's information on 2.6 implementation of networking MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2-cvs X-PMX-Version: 4.7.1.128075 X-PerlMx-Virus-Scanned: Yes X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cndougla@purdue.edu Precedence: bulk X-list: netdev Content-Length: 546 Lines: 9 I have an idea for linux networking at the level of manipulation of how sk_buffs are used. However, I do not know where in the linux kernel code to begin looking for where sk_buffs are manipulated. I was wondering if there were any good resources on the 2.6 implementation of the tcp/ip protocol. I have found a few documents on 2.2 and 2.4, but many of the functions listed do not seem to be present in the 2.6 kernel. Even if I could have a list of function calls from send to receive using the tcp/ip protocol, it would help a lot. Thank you From michaelc@cs.wisc.edu Wed Apr 6 10:23:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 10:23:44 -0700 (PDT) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36HNd0e008997 for ; Wed, 6 Apr 2005 10:23:39 -0700 Received: from [192.168.0.2] ([199.108.226.254]) (authenticated bits=0) by sabe.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j36HN0wI004418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 6 Apr 2005 12:23:01 -0500 Message-ID: <42540CF3.7070501@cs.wisc.edu> Date: Wed, 06 Apr 2005 09:23:15 -0700 From: Mike Christie User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Dmitry Yusupov , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michaelc@cs.wisc.edu Precedence: bulk X-list: netdev Content-Length: 718 Lines: 18 Herbert Xu wrote: > Dmitry Yusupov wrote: >>* netlink alloc_skb() now uses sk_allocation instead of hard-coded >>GFP_KERNEL > > > Why? We never set it to anything else for netlink. > It is due to where it is being used. open-iscsi uses netlink sockets for communication in a block (scsi specificically) driver that has pushed much of its code to usersapce. Forcing open-iscsi to use GFP_KERNEL causes a couple of problems. The worst would be where a GFP_KERNEL allocation causes a write, and that write is to an iscsi disk that open-iscsi is managing. The write could then hit the same code path and cause another GFP_KERNEL allocation and we could loop like that until the system locks up. From davem@davemloft.net Wed Apr 6 11:17:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 11:17:12 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36IH5Z8011087 for ; Wed, 6 Apr 2005 11:17:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJF3W-0004X3-00; Wed, 06 Apr 2005 11:15:10 -0700 Date: Wed, 6 Apr 2005 11:15:09 -0700 From: "David S. Miller" To: Thomas Graf Cc: hadi@cyberus.ca, lark@linux.net.cn, netdev@oss.sgi.com Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-Id: <20050406111509.0462abcf.davem@davemloft.net> In-Reply-To: <20050406141020.GQ26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 24 On Wed, 6 Apr 2005 16:10:20 +0200 Thomas Graf wrote: > The thing I'm worrying about is that I don't want to break the perfect > alignment of fw_head to good slab obj sizes but I guess there is no > way around. I'd really like to make hash size and hash function > configureable. For example a hash size of 1024 would perform much > better and would still fit into a single page on most systems. I think a hash xor'ing in the high bits into the low 8 bits, as has been suggested a few times already, meets your criteria and solves Lark's problem. The hash table size, if still an issue, can be dynamically sized based upon some criteria with some reasonable default initial selection (such as the current 256). I think dynamic hash function selection is madness. You have a key that needs to be hashed, you are aware of one very common usage (the one that perfectly hashes currently) and you are also aware of a method by which the cases that don't fit into that mold can be made to perform acceptably too (xor'ing in the upper bits). We can thus do this with one single hash function. From davem@davemloft.net Wed Apr 6 11:19:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 11:19:47 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36IJcCP011642 for ; Wed, 6 Apr 2005 11:19:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJF5d-0004XP-00; Wed, 06 Apr 2005 11:17:21 -0700 Date: Wed, 6 Apr 2005 11:17:21 -0700 From: "David S. Miller" To: Herbert Xu Cc: christoph@lameter.com, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-Id: <20050406111721.3ac67605.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 721 Lines: 19 On Wed, 06 Apr 2005 18:32:54 +1000 Herbert Xu wrote: > In fact, the atomic_dec_and_test is really only needed for unhashed > entries (i.e., IPsec). So we could do something like this so that > all hashed entries undergo atomic_dec. > > This would only make sense if there were architectures where > atomic_dec is significantly cheaper compared to atomic_dec_and_test. > > Do such beasts exist? See his other emails in this thread. If it can be converted to atomic_dec() then he wants to change the counter into an array of counters on NUMA systems. But his trick only works if the atomic_dec_and_test() can be eliminated for all cases, which we're now quite certain is not possible. From tgraf@suug.ch Wed Apr 6 11:31:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 11:31:21 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36IVFXN012637 for ; Wed, 6 Apr 2005 11:31:15 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 57F8B8A; Wed, 6 Apr 2005 20:30:51 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 5B40A1C0EA; Wed, 6 Apr 2005 20:31:34 +0200 (CEST) Date: Wed, 6 Apr 2005 20:31:34 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, lark@linux.net.cn, netdev@oss.sgi.com Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function Message-ID: <20050406183134.GR26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050406111509.0462abcf.davem@davemloft.net> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1276 Lines: 27 * David S. Miller <20050406111509.0462abcf.davem@davemloft.net> 2005-04-06 11:15 > On Wed, 6 Apr 2005 16:10:20 +0200 > Thomas Graf wrote: > > > The thing I'm worrying about is that I don't want to break the perfect > > alignment of fw_head to good slab obj sizes but I guess there is no > > way around. I'd really like to make hash size and hash function > > configureable. For example a hash size of 1024 would perform much > > better and would still fit into a single page on most systems. > > I think a hash xor'ing in the high bits into the low 8 bits, as has > been suggested a few times already, meets your criteria and solves > Lark's problem. Yes, it sounds pretty good. I can't find any scenario where it would perform unacceptable, it's not perfect but fair enough for everyone I guess. > The hash table size, if still an issue, can be dynamically sized based > upon some criteria with some reasonable default initial selection > (such as the current 256). I guess sometimes it would make a lot of sense to spend a few dozen pages for the hashtable but it's not worth to play games with the perfectly aligned fw_head just in case. PAGESIZE/address_size would make sense though. If someone needs something bigger it can be changed in the source. From asimshankar@gmail.com Wed Apr 6 11:34:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 11:34:43 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36IYaDl013260 for ; Wed, 6 Apr 2005 11:34:36 -0700 Received: by wproxy.gmail.com with SMTP id 68so340427wri for ; Wed, 06 Apr 2005 11:34:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Zebhho0IAC1eue4HgZsmECw/vzAc1Bz/yUhZT83NHiOX/Eg9Sfxa6HHSfgo6tcxKD8ZbyNNkFVPkXxMVkaS5CxlLC2Zlwk/XbD+VAAhst5pLOrbM4Gv6aRv4P8Y8/yAGnc6lHzaVcqnxxfGL6LZe9waFlPkudc141S4chLFg1Z0= Received: by 10.54.36.76 with SMTP id j76mr650734wrj; Wed, 06 Apr 2005 11:34:28 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Wed, 6 Apr 2005 11:34:28 -0700 (PDT) Message-ID: <7bca1cb505040611343cd60c6c@mail.gmail.com> Date: Wed, 6 Apr 2005 13:34:28 -0500 From: Asim Shankar Reply-To: Asim Shankar To: Chase Douglas Subject: Re: Beginner's information on 2.6 implementation of networking Cc: netdev@oss.sgi.com In-Reply-To: <1112801850.4254023a192c5@webmail.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1112801850.4254023a192c5@webmail.purdue.edu> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 403 Lines: 13 > present in the 2.6 kernel. Even if I could have a list of function calls from > send to receive using the tcp/ip protocol, it would help a lot. Have you looked at: http://datatag.web.cern.ch/datatag/papers/tr-datatag-2004-1.pdf Though this document is based on 2.4.20, it is similar to 2.6 and as you go about looking at the code, the changes would be easy to understand. Hope that helps, -- Asim From christoph@graphe.net Wed Apr 6 11:49:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 11:49:31 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36InR9r014200 for ; Wed, 6 Apr 2005 11:49:27 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJFa6-0001rb-Bj; Wed, 06 Apr 2005 11:48:51 -0700 Date: Wed, 6 Apr 2005 11:48:50 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: "David S. Miller" cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050406111721.3ac67605.davem@davemloft.net> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 535 Lines: 14 On Wed, 6 Apr 2005, David S. Miller wrote: > See his other emails in this thread. If it can be converted to > atomic_dec() then he wants to change the counter into an array > of counters on NUMA systems. Correct. > But his trick only works if the atomic_dec_and_test() can be eliminated > for all cases, which we're now quite certain is not possible. Some changes to the way locking is done between the garbage collector and dst_destroy would be necessary. Lets see if the author of the patch can come up with a solution to this. From jean-mickael.guerin@6wind.com Wed Apr 6 12:36:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 12:37:01 -0700 (PDT) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36Jarvl028583 for ; Wed, 6 Apr 2005 12:36:54 -0700 Received: from [82.225.148.74] (michelet-10-82-225-148-74.fbx.proxad.net [82.225.148.74]) by eagle.6wind.com (Postfix) with ESMTP id 6F8A124E; Wed, 6 Apr 2005 21:36:52 +0200 (CEST) Message-ID: <42543A54.7030504@6wind.com> Date: Wed, 06 Apr 2005 21:36:52 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Didier Barvaux Cc: netdev@oss.sgi.com Subject: Re: [IPv6] policy routing ? References: <20050406100401.0eab9374.didier@barvaux.org> In-Reply-To: <20050406100401.0eab9374.didier@barvaux.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-mickael.guerin@6wind.com Precedence: bulk X-list: netdev Content-Length: 480 Lines: 15 Didier Barvaux wrote: > Hello, > > > I'm trying to do policy routing with IPv6 (source routing) on a 2.6.11 kernel. It works perfectly well with IPv4 using iproute2 (iproute2-2.6.11-050330), but it doesn't seem to work with IPv6. Hi Didier, I beleive policy routing for IPv6 is not yet supported in the kernel. FYI a patch is included in the implementation of Mobile IPv6 provided by MIPL: http://www.mobile-ipv6.org/ Online patch is based on 2.6.8.1. Regards, Jean-Mickael From didier@barvaux.org Wed Apr 6 13:19:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 13:19:48 -0700 (PDT) Received: from barvaux.org (AToulouse-206-1-14-79.w81-50.abo.wanadoo.fr [81.50.217.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36KJcVT030313 for ; Wed, 6 Apr 2005 13:19:39 -0700 Received: (qmail 30631 invoked by uid 210); 6 Apr 2005 22:20:44 +0200 Received: from 192.168.0.2 by maat (envelope-from , uid 201) with qmail-scanner-1.25st (clamdscan: 0.83/808. spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(192.168.0.2):. Processed in 0.046964 secs); 06 Apr 2005 20:20:44 -0000 Received: from unknown (HELO nefertiti.barvaux.org) (192.168.0.2) by 192.168.0.1 with AES256-SHA encrypted SMTP; 6 Apr 2005 22:20:44 +0200 Date: Wed, 6 Apr 2005 22:20:48 +0200 From: Didier Barvaux To: netdev@oss.sgi.com Subject: Re: [IPv6] policy routing ? Message-Id: <20050406222048.46c1e997.didier@barvaux.org> In-Reply-To: <42543A54.7030504@6wind.com> References: <20050406100401.0eab9374.didier@barvaux.org> <42543A54.7030504@6wind.com> X-Mailer: Sylpheed version 1.0.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-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: didier@barvaux.org Precedence: bulk X-list: netdev Content-Length: 423 Lines: 14 Hello, > I beleive policy routing for IPv6 is not yet supported in the kernel. > FYI a patch is included in the implementation of Mobile IPv6 provided by > MIPL: http://www.mobile-ipv6.org/ I have just looked at the patch provided by MIPL. It seems you are right. It adds multiple tables and rule for IPv6 support to the kernel. I will test the MIPL patch tomorrow. Thank you, Jean-Mickael ! Regards, Didier Barvaux From akpm@osdl.org Wed Apr 6 14:22:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 14:22:42 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36LMZuJ001333 for ; Wed, 6 Apr 2005 14:22:36 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j36LMLs4022531 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 6 Apr 2005 14:22:22 -0700 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j36LMJIg021397; Wed, 6 Apr 2005 14:22:19 -0700 Date: Wed, 6 Apr 2005 14:22:32 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: rl@hellgate.ch, thomas@easyspeedy.com Subject: Fw: [Bugme-new] [Bug 4451] New: VIA Rhine II: media detection fails on reboot. Message-Id: <20050406142232.7a8803fe.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1499 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: 1728 Lines: 53 Begin forwarded message: Date: Wed, 6 Apr 2005 05:35:33 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4451] New: VIA Rhine II: media detection fails on reboot. http://bugme.osdl.org/show_bug.cgi?id=4451 Summary: VIA Rhine II: media detection fails on reboot. Kernel Version: 2.6.9 Status: NEW Severity: normal Owner: jgarzik@pobox.com Submitter: thomas@easyspeedy.com Distribution: Fedora Core 3 / RIP Linux 11.8 / RIP Linux 12.3 Hardware Environment: DFI PM12-TL Software Environment: Kernel 2.6.9+ Problem Description: The changes introduced in 2.6.9 cause media detection to fail after reboot on DFI PM12-TL. Doing a halt -p results in the same problem on next boot. It is necessary to disconnect power completely to restore the chip to a working state. Snip from changelog: ----------------------------------- [PATCH] Restructure reset code Restructure code to make it easier to maintain. rhine_hw_init: resets chip, reloads eeprom rhine_chip_reset: chip reset + what used to be wait_for_reset rhine_reload_eeprom: reload eeprom, re-enable MMIO, disable EEPROM-controlled WOL Note: Chip reset clears a bunch of registers that should be reloaded from EEPROM (which turns off MMIO). Deal with that later. Signed-off-by: Roger Luethi --------------------------------- Kernels tested: 2.6.9, 2.6.11.6, 2.6.12-rc2 Steps to reproduce: Boot 2.6.9 or later on DFI PM12-TL and reboot. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From herbert@gondor.apana.org.au Wed Apr 6 14:29:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 14:30:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36LTpEL002040 for ; Wed, 6 Apr 2005 14:29:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJI5e-0004sT-00; Thu, 07 Apr 2005 07:29:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJI5D-0006Rv-00; Thu, 07 Apr 2005 07:29:07 +1000 Date: Thu, 7 Apr 2005 07:29:07 +1000 To: Mike Christie Cc: Dmitry Yusupov , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050406212906.GA24775@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42540CF3.7070501@cs.wisc.edu> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 916 Lines: 19 On Wed, Apr 06, 2005 at 09:23:15AM -0700, Mike Christie wrote: > > It is due to where it is being used. open-iscsi uses netlink > sockets for communication in a block (scsi specificically) > driver that has pushed much of its code to usersapce. Forcing > open-iscsi to use GFP_KERNEL causes a couple of problems. The > worst would be where a GFP_KERNEL allocation causes a write, > and that write is to an iscsi disk that open-iscsi is managing. > The write could then hit the same code path and cause another > GFP_KERNEL allocation and we could loop like that until the > system locks up. In that case it's not enough to just use sk_allocation here. You'll need a way to actually set it to GFP_ATOMIC. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dmitry_yus@yahoo.com Wed Apr 6 14:37:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 14:37:40 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j36LbZfw003238 for ; Wed, 6 Apr 2005 14:37:35 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp015.mail.yahoo.com with SMTP; 6 Apr 2005 21:37:31 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050406212906.GA24775@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> Content-Type: text/plain Date: Wed, 06 Apr 2005 14:37:21 -0700 Message-Id: <1112823442.16753.68.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 975 Lines: 22 On Thu, 2005-04-07 at 07:29 +1000, Herbert Xu wrote: > On Wed, Apr 06, 2005 at 09:23:15AM -0700, Mike Christie wrote: > > > > It is due to where it is being used. open-iscsi uses netlink > > sockets for communication in a block (scsi specificically) > > driver that has pushed much of its code to usersapce. Forcing > > open-iscsi to use GFP_KERNEL causes a couple of problems. The > > worst would be where a GFP_KERNEL allocation causes a write, > > and that write is to an iscsi disk that open-iscsi is managing. > > The write could then hit the same code path and cause another > > GFP_KERNEL allocation and we could loop like that until the > > system locks up. > > In that case it's not enough to just use sk_allocation here. > You'll need a way to actually set it to GFP_ATOMIC. correct. That's why in my patch I provided NETLINK_UESTABLISHED event. It is a right way and time to set sk->sk_allocation to GFP_ATOMIC for newly established netlink connection. imho. From herbert@gondor.apana.org.au Wed Apr 6 15:05:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 15:05:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36M5iUW004899 for ; Wed, 6 Apr 2005 15:05:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJIeN-0005C2-00; Thu, 07 Apr 2005 08:05:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJIdG-0001AA-00; Thu, 07 Apr 2005 08:04:18 +1000 Date: Thu, 7 Apr 2005 08:04:17 +1000 To: Dmitry Yusupov Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050406220417.GA4443@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112823442.16753.68.camel@beastie> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1076 Lines: 26 On Wed, Apr 06, 2005 at 02:37:21PM -0700, Dmitry Yusupov wrote: > > > In that case it's not enough to just use sk_allocation here. > > You'll need a way to actually set it to GFP_ATOMIC. > > That's why in my patch I provided NETLINK_UESTABLISHED event. It is a > right way and time to set sk->sk_allocation to GFP_ATOMIC for newly > established netlink connection. imho. Right. In that case I think you're going about this the wrong way. It's unmanageable to have some external kernel module fiddle with netlink's sk_allocation upon the receipt of a notification. If you really want to do this, do it as a setsockopt. It's the owner of the socket that wants the GFP_ATOMIC, not anybody else. However, I'd like to know more about how open-iscsi uses this. In particular, what are these messages and what do you do when the GFP_ATOMIC alloc_skb fails? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dmitry_yus@yahoo.com Wed Apr 6 15:26:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 15:26:38 -0700 (PDT) Received: from smtp105.mail.sc5.yahoo.com (smtp105.mail.sc5.yahoo.com [66.163.169.225]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j36MQYFT005969 for ; Wed, 6 Apr 2005 15:26:34 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp105.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 22:26:34 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050406220417.GA4443@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> Content-Type: text/plain Date: Wed, 06 Apr 2005 15:26:25 -0700 Message-Id: <1112826385.16753.99.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1578 Lines: 35 On Thu, 2005-04-07 at 08:04 +1000, Herbert Xu wrote: > On Wed, Apr 06, 2005 at 02:37:21PM -0700, Dmitry Yusupov wrote: > > > > > In that case it's not enough to just use sk_allocation here. > > > You'll need a way to actually set it to GFP_ATOMIC. > > > > That's why in my patch I provided NETLINK_UESTABLISHED event. It is a > > right way and time to set sk->sk_allocation to GFP_ATOMIC for newly > > established netlink connection. imho. > > Right. In that case I think you're going about this the wrong way. > It's unmanageable to have some external kernel module fiddle with > netlink's sk_allocation upon the receipt of a notification. > > If you really want to do this, do it as a setsockopt. It's the owner > of the socket that wants the GFP_ATOMIC, not anybody else. I see. yes. either way is OK for me. yours is cleaner. We probably should provide new optname for netlink proto. > However, I'd like to know more about how open-iscsi uses this. In > particular, what are these messages and what do you do when the > GFP_ATOMIC alloc_skb fails? Messages from kernel are asynchronous and there are no alloc_skb on "up" calls. It is "mempooled out" on interface level. (see Open-iSCSI interface). Messages to kernel requires copy_from_user to newly allocated skb, here is where we need sk_allocation bit set. Those messages are synchronous from daemon perspective. If "down" call fails, we will re-try later or take some other management action. We assuming that later OOM-killer will free some memory for us and atomic allocation will succeed eventually. Dmitry From alessandro.suardi@gmail.com Wed Apr 6 15:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 15:30:36 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36MUVJ0006629 for ; Wed, 6 Apr 2005 15:30:31 -0700 Received: by rproxy.gmail.com with SMTP id r35so267234rna for ; Wed, 06 Apr 2005 15:30:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IprhtPClUW3gK4OLZdHWBckj2AmmqaZ1kIOUPZMMOlz6kREghBWpH/9j1CvTSvp71JrOYhSjSX+XJTpeYnePU/Isc0m5yJqshm1lOU655oukm6N8vZD9YiL3UiU6oMbNgB/5JbZShR9LYaCpDEQP/RQv7NGPeJDkIIWXvBXyAyg= Received: by 10.38.5.73 with SMTP id 73mr126674rne; Wed, 06 Apr 2005 15:30:29 -0700 (PDT) Received: by 10.38.13.25 with HTTP; Wed, 6 Apr 2005 15:30:28 -0700 (PDT) Message-ID: <5a4c581d05040615306f12ebde@mail.gmail.com> Date: Thu, 7 Apr 2005 00:30:28 +0200 From: Alessandro Suardi Reply-To: Alessandro Suardi To: Linux Kernel Mailing List Subject: Re: non-fatal oops with EIP at skb_release_data, available for debugging Cc: netdev@oss.sgi.com In-Reply-To: <5a4c581d05030412482a596ee5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <5a4c581d05030412482a596ee5@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alessandro.suardi@gmail.com Precedence: bulk X-list: netdev Content-Length: 5113 Lines: 115 Quoting my post of over a month ago, hit another non-fatal oops this time with 2.6.12-rc1-bk2... [17330.816664] Adding 232932k swap on /dev/hdb4. Priority:-2 extents:1 [42120.713332] UDP: bad checksum. From 84.188.199.xxx:57483 to 192.168.1.7:10600 ulen 27 [56984.872784] UDP: bad checksum. From 216.155.90.xxx:11417 to 192.168.1.7:10600 ulen 28 [383152.586711] scsi: unknown opcode 0x01 [630539.047761] UDP: short packet: From 4.46.101.xxx:5431 58/27 to 192.168.1.7:1 0600 [681405.777002] ------------[ cut here ]------------ [681405.777337] kernel BUG at include/linux/mm.h:343! [681405.777642] invalid operand: 0000 [#1] [681405.777885] PREEMPT [681405.778041] Modules linked in: parport_pc parport 8139too floppy [681405.778488] CPU: 0 [681405.778491] EIP: 0060:[] Not tainted VLI [681405.778494] EFLAGS: 00210256 (2.6.12-rc1-bk2) [681405.779293] EIP is at skb_release_data+0xa3/0xb0 [681405.779593] eax: 00000000 ebx: 00000002 ecx: ceb1af80 edx: c10eeb40 [681405.780027] esi: c30785c0 edi: c30785c0 ebp: ccd95d28 esp: ccd95d20 [681405.780458] ds: 007b es: 007b ss: 0068 [681405.780723] Process metacity (pid: 2190, threadinfo=ccd94000 task=cb501a40) [681405.781164] Stack: c30785c0 00000020 ccd95d34 c02dcd3b cec7a6c0 ccd95d54 c02 dcdb7 ccd95f3c [681405.781807] 00001620 c30785c0 506c6f85 c30785c0 506c6f85 ccd95da8 c03 0100a 00000000 [681405.782448] c02dc46f caf7d420 ccd95d80 00000001 caf7d46c ccd94000 000 00001 00000000 [681405.783088] Call Trace: [681405.783258] [] show_stack+0x7a/0x90 [681405.783574] [] show_registers+0x14d/0x1c0 [681405.783915] [] die+0xe4/0x170 [681405.784192] [] do_invalid_op+0xa3/0xb0 [681405.784517] [] error_code+0x2b/0x30 [681405.785009] [] kfree_skbmem+0xb/0x20 [681405.785494] [] __kfree_skb+0x67/0xf0 [681405.785978] [] tcp_recvmsg+0x5fa/0x720 [681405.786477] [] sock_common_recvmsg+0x46/0x60 [681405.787004] [] sock_recvmsg+0xbd/0xf0 [681405.787493] [] sock_readv_writev+0x83/0x90 [681405.788009] [] sock_readv+0x3b/0x50 [681405.788487] [] do_readv_writev+0x205/0x230 [681405.789004] [] vfs_readv+0x3d/0x50 [681405.789476] [] sys_readv+0x3d/0xa0 [681405.789947] [] sysenter_past_esp+0x54/0x75 [681405.790461] Code: 8b 86 98 00 00 00 5e c9 e9 7b e9 e5 ff 89 d0 e8 44 f7 e5 f f eb d6 89 f0 e8 fb fe ff ff 5b 8b 86 98 00 00 00 5e c9 e9 5d e9 e5 ff <0f> 0b 5 7 01 32 ed 35 c0 eb ac 8d 76 00 55 89 e5 53 89 c3 e8 45 [681405.857278] <7>UDP: short packet: From 213.23.1.xxx:11236 2814/33 to 192.168. 1.7:10600 On Mar 4, 2005 10:48 PM, Alessandro Suardi wrote: > This is my K7-800, 256MB RAM machine running as > ed2k/bittorrent 24/7 box... metacity died, but the > windows are still alive (and working) so if someone > wants to get more info about it, just ping me... > > [root@donkey ~]# cat /proc/version > Linux version 2.6.11-rc3-bk8 (asuardi@donkey) (gcc version 3.4.2 > 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 > [root@donkey ~]# lsmod > Module Size Used by > loop 15368 - > nls_iso8859_1 3840 - > parport_pc 29444 - > parport 24704 - > 8139too 24896 - > floppy 57392 - > > From the dmesg ring: > > kernel BUG at include/linux/mm.h:343! > invalid operand: 0000 [#1] > PREEMPT > Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00210256 (2.6.11-rc3-bk8) > EIP is at skb_release_data+0x92/0xa0 > eax: 00000000 ebx: 00000000 ecx: cca36f80 edx: c11a97c0 > esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 > ds: 007b es: 007b ss: 0068 > Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) > Stack: c4205f20 00000000 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 > 00000000 c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 00000000 > 00000040 cc68c454 00000000 00000001 cc68c444 cd148000 00000001 00000000 > Call Trace: > [] show_stack+0x7a/0x90 > [] show_registers+0x14d/0x1c0 > [] die+0xe4/0x180 > [] do_invalid_op+0xa3/0xb0 > [] error_code+0x2b/0x30 > [] kfree_skbmem+0xb/0x20 > [] __kfree_skb+0x67/0xf0 > [] tcp_recvmsg+0x5f6/0x710 > [] sock_common_recvmsg+0x46/0x60 > [] sock_aio_read+0xee/0x100 > [] do_sync_read+0x97/0xf0 > [] vfs_read+0x91/0x120 > [] sys_read+0x3d/0x70 > [] sysenter_past_esp+0x52/0x75 > Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb > cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> > 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 --alessandro "I want to know if it's you I don't trust 'cause I damn sure don't trust myself" (Bruce Springsteen, "Brilliant Disguise") From akpm@osdl.org Wed Apr 6 15:58:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 15:58:33 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36MwRYO007977 for ; Wed, 6 Apr 2005 15:58:27 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j36MwGs4030301 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 6 Apr 2005 15:58:17 -0700 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j36MwFkp026650; Wed, 6 Apr 2005 15:58:15 -0700 Date: Wed, 6 Apr 2005 15:58:28 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: mailinglist.chris@gmail.com Subject: Fw: kernel 2.6 libipq kernel hang Message-Id: <20050406155828.1584d7cd.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1505 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: 2263 Lines: 51 Begin forwarded message: Date: Wed, 6 Apr 2005 15:12:05 -0400 From: Mailing List To: linux-kernel@vger.kernel.org Subject: kernel 2.6 libipq kernel hang All, I am having a kernel hang with all the latest versions of the 2.6 kernel (2.6.8.1, 2.6.9, 2.6.10, and 2.6.12-rc2). Basically, my test is this: I have a simple ipq program that just takes packets in, makes a copy of them (using memcpy), then accepts the packets with the new buffer (which happens to be a copy of the old buffer). I run this program on two machines, with the following iptables rules: /sbin/iptables -t mangle -A POSTROUTING -d 192.168.3.0/24 -j QUEUE /sbin/iptables -t mangle -A PREROUTING -s 192.168.3.0/24 -j QUEUE I then have a simple server and client program; the server just accepts a connection, recv's some data, and then closes the connection (in a while(1) loop). The client connects to the server, send's some data, then closes the connection (in a while(1) loop). With this test running, on all of the kernels mentioned above, the kernel will always hang after some length of time (it seems to be more or less random). No oops, no stack trace, just a hard kernel lock. I saw in the ChangeLog for 2.6.12-rc2 that they may have fixed a race condition in netlink; however, 2.6.12-rc2 still did not work for me. I have also tried running a server program that just accepts a connection, and recv's data forever, with a client that connects once, and send's data forever. This also locked up the machine, although with slightly different behavior (basically the queue program sucked up 100% of the processor for a while, then the whole kernel hung). All of the code I am using, along with the scripts can be found at http://www.ontologistics.net/OpenSource/libipq If anyone has any suggestions about what I am doing wrong in either the libipq program or the client or server programs, or any ideas about what is going on with netlink, please let me know. Thank you, Chris Lalancette - 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 tgraf@suug.ch Wed Apr 6 17:55:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Apr 2005 17:55:12 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j370t4f5015753 for ; Wed, 6 Apr 2005 17:55:05 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C31808A; Thu, 7 Apr 2005 02:54:38 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 5F9941C0EA; Thu, 7 Apr 2005 02:55:19 +0200 (CEST) Date: Thu, 7 Apr 2005 02:55:19 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, lark@linux.net.cn, netdev@oss.sgi.com Subject: [RFC] dynamic hash table size & xor hash function for cls_fw Message-ID: <20050407005519.GS26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> <20050406183134.GR26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050406183134.GR26731@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2550 Lines: 85 * Thomas Graf <20050406183134.GR26731@postel.suug.ch> 2005-04-06 20:31 > Yes, it sounds pretty good. I can't find any scenario where it > would perform unacceptable, it's not perfect but fair enough > for everyone I guess. Changes the hashtable size to PAGE_SIZE/sizeof(unsigned long) and adapts the hashing algorithm to xor various buckets in order to maintain collision free hashing for the most common use case while providing some kind of distribution for more rare cases. The hashing function looks really ugly, it is, but gcc will optimize away all the uneeded branches which will make it short again. The hash case for 10bits hash table ignores the most significant 2 bits, I don't think this has any impact but would rather be wasted cycles. It looks inefficient but the manual shifting & xoring only takes one instruction more than the HTSIZE == 256 case on my x86 box so the increased hashing area should be worth it. Thoughts? ===== net/sched/cls_fw.c 1.21 vs edited ===== --- 1.21/net/sched/cls_fw.c 2005-03-29 02:45:46 +02:00 +++ edited/net/sched/cls_fw.c 2005-04-07 02:41:46 +02:00 @@ -46,9 +46,11 @@ #include #include +#define HTSIZE (PAGE_SIZE/sizeof(struct fw_filter *)) + struct fw_head { - struct fw_filter *ht[256]; + struct fw_filter *ht[HTSIZE]; }; struct fw_filter @@ -69,7 +71,28 @@ static __inline__ int fw_hash(u32 handle) { - return handle&0xFF; + if (HTSIZE == 4096) + return ((handle >> 24) & 0xFFF) ^ + ((handle >> 12) & 0xFFF) ^ + (handle & 0xFFF); + else if (HTSIZE == 2048) + return ((handle >> 22) & 0x7FF) ^ + ((handle >> 11) & 0x7FF) ^ + (handle & 0x7FF); + else if (HTSIZE == 1024) + return ((handle >> 20) & 0x3FF) ^ + ((handle >> 10) & 0x3FF) ^ + (handle & 0x3FF); + else if (HTSIZE == 512) + return (handle >> 27) ^ + ((handle >> 18) & 0x1FF) ^ + ((handle >> 9) & 0x1FF) ^ + (handle & 0x1FF); + else if (HTSIZE == 256) { + u8 *t = (u8 *) &handle; + return t[0] ^ t[1] ^ t[2] ^ t[3]; + } else + return handle & (HTSIZE - 1); } static int fw_classify(struct sk_buff *skb, struct tcf_proto *tp, @@ -152,7 +175,7 @@ if (head == NULL) return; - for (h=0; h<256; h++) { + for (h=0; hht[h]) != NULL) { head->ht[h] = f->next; fw_delete_filter(tp, f); @@ -291,7 +314,7 @@ if (arg->stop) return; - for (h = 0; h < 256; h++) { + for (h = 0; h < HTSIZE; h++) { struct fw_filter *f; for (f = head->ht[h]; f; f = f->next) { From hadi@cyberus.ca Thu Apr 7 03:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 03:38:41 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37AcaXS021667 for ; Thu, 7 Apr 2005 03:38:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DJUPB-0007F2-J1 for netdev@oss.sgi.com; Thu, 07 Apr 2005 06:38:33 -0400 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 1DJUP8-0004rU-Bm; Thu, 07 Apr 2005 06:38:30 -0400 Subject: Re: [RFC] dynamic hash table size & xor hash function for cls_fw From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , lark@linux.net.cn, netdev In-Reply-To: <20050407005519.GS26731@postel.suug.ch> References: <20050405213023.0256.LARK@linux.net.cn> <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> <20050406183134.GR26731@postel.suug.ch> <20050407005519.GS26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112870307.1118.91.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 06:38:27 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1507 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: 1116 Lines: 39 On Wed, 2005-04-06 at 20:55, Thomas Graf wrote: > > static __inline__ int fw_hash(u32 handle) > { > - return handle&0xFF; > + if (HTSIZE == 4096) > + return ((handle >> 24) & 0xFFF) ^ > + ((handle >> 12) & 0xFFF) ^ > + (handle & 0xFFF); > + else if (HTSIZE == 2048) > + return ((handle >> 22) & 0x7FF) ^ > + ((handle >> 11) & 0x7FF) ^ > + (handle & 0x7FF); > + else if (HTSIZE == 1024) > + return ((handle >> 20) & 0x3FF) ^ > + ((handle >> 10) & 0x3FF) ^ > + (handle & 0x3FF); > + else if (HTSIZE == 512) > + return (handle >> 27) ^ > + ((handle >> 18) & 0x1FF) ^ > + ((handle >> 9) & 0x1FF) ^ > + (handle & 0x1FF); > + else if (HTSIZE == 256) { > + u8 *t = (u8 *) &handle; > + return t[0] ^ t[1] ^ t[2] ^ t[3]; > + } else > + return handle & (HTSIZE - 1); > } Does HTSIZE change at runtime? How does migrating from one to other take place? Also why not have a function pointer with a series of these being separate instead of doing the if checks? BTW it does seem any one of those hashes maybe sufficient, no? cheers, jamal From lark@linux.net.cn Thu Apr 7 03:47:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 03:47:24 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37AlDam022446 for ; Thu, 7 Apr 2005 03:47:14 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id DE9423EE70; Thu, 7 Apr 2005 18:47:10 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 11979-01-5; Thu, 7 Apr 2005 18:47:08 +0800 (CST) Received: from [192.168.0.120] (unknown [221.221.5.129]) by mx.linux.net.cn (Postfix) with ESMTP id 875AC3EC0B; Thu, 7 Apr 2005 18:47:08 +0800 (CST) Date: Thu, 07 Apr 2005 18:47:08 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [RFC] dynamic hash table size & xor hash function for cls_fw Cc: Thomas Graf , "David S. Miller" , netdev In-Reply-To: <1112870307.1118.91.camel@jzny.localdomain> References: <20050407005519.GS26731@postel.suug.ch> <1112870307.1118.91.camel@jzny.localdomain> Message-Id: <20050407184456.02CC.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 1484 Lines: 55 Hi jamal, I think Thomas decide to only support one hash function at compile time, and no switch at runtime. HSIZE is a constant so the if branch will be optimized by gcc at compile time. only one hash is left. On 07 Apr 2005 06:38:27 -0400, jamal wrote: > On Wed, 2005-04-06 at 20:55, Thomas Graf wrote: > > > > > static __inline__ int fw_hash(u32 handle) > > { > > - return handle&0xFF; > > + if (HTSIZE == 4096) > > + return ((handle >> 24) & 0xFFF) ^ > > + ((handle >> 12) & 0xFFF) ^ > > + (handle & 0xFFF); > > + else if (HTSIZE == 2048) > > + return ((handle >> 22) & 0x7FF) ^ > > + ((handle >> 11) & 0x7FF) ^ > > + (handle & 0x7FF); > > + else if (HTSIZE == 1024) > > + return ((handle >> 20) & 0x3FF) ^ > > + ((handle >> 10) & 0x3FF) ^ > > + (handle & 0x3FF); > > + else if (HTSIZE == 512) > > + return (handle >> 27) ^ > > + ((handle >> 18) & 0x1FF) ^ > > + ((handle >> 9) & 0x1FF) ^ > > + (handle & 0x1FF); > > + else if (HTSIZE == 256) { > > + u8 *t = (u8 *) &handle; > > + return t[0] ^ t[1] ^ t[2] ^ t[3]; > > + } else > > + return handle & (HTSIZE - 1); > > } > > Does HTSIZE change at runtime? How does migrating from one to other take > place? > Also why not have a function pointer with a series of these being > separate instead of doing the if checks? BTW it does seem any one of > those hashes maybe sufficient, no? > > cheers, > jamal -- lark From tgraf@suug.ch Thu Apr 7 03:51:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 03:51:38 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37ApWHG023096 for ; Thu, 7 Apr 2005 03:51:33 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9F5F58D; Thu, 7 Apr 2005 12:51:07 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id C3CA61C0EA; Thu, 7 Apr 2005 12:51:49 +0200 (CEST) Date: Thu, 7 Apr 2005 12:51:49 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , lark@linux.net.cn, netdev Subject: Re: [RFC] dynamic hash table size & xor hash function for cls_fw Message-ID: <20050407105149.GT26731@postel.suug.ch> References: <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> <20050406183134.GR26731@postel.suug.ch> <20050407005519.GS26731@postel.suug.ch> <1112870307.1118.91.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112870307.1118.91.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1754 Lines: 49 * jamal <1112870307.1118.91.camel@jzny.localdomain> 2005-04-07 06:38 > On Wed, 2005-04-06 at 20:55, Thomas Graf wrote: > > > > > static __inline__ int fw_hash(u32 handle) > > { > > - return handle&0xFF; > > + if (HTSIZE == 4096) > > + return ((handle >> 24) & 0xFFF) ^ > > + ((handle >> 12) & 0xFFF) ^ > > + (handle & 0xFFF); > > + else if (HTSIZE == 2048) > > + return ((handle >> 22) & 0x7FF) ^ > > + ((handle >> 11) & 0x7FF) ^ > > + (handle & 0x7FF); > > + else if (HTSIZE == 1024) > > + return ((handle >> 20) & 0x3FF) ^ > > + ((handle >> 10) & 0x3FF) ^ > > + (handle & 0x3FF); > > + else if (HTSIZE == 512) > > + return (handle >> 27) ^ > > + ((handle >> 18) & 0x1FF) ^ > > + ((handle >> 9) & 0x1FF) ^ > > + (handle & 0x1FF); > > + else if (HTSIZE == 256) { > > + u8 *t = (u8 *) &handle; > > + return t[0] ^ t[1] ^ t[2] ^ t[3]; > > + } else > > + return handle & (HTSIZE - 1); > > } > > Does HTSIZE change at runtime? How does migrating from one to other take > place? No, the size is static (PAGE_SIZE/sizeof(unsigned long)) (typically 1024). > Also why not have a function pointer with a series of these being > separate instead of doing the if checks? Because it is static, gcc will optimize and remove all branches leaving only the one that is actually needed, i.e. on most systems the hash function will get down to the contents of the if (HTSIZE == 1024) branch. > BTW it does seem any one of those hashes maybe sufficient, no? If we want to do the xor'ing to maintain collision free hashing for the most common case we need to separate. It would be possible to play games and calculate the shifts etc but gcc has a hard time optimizing such things. From hadi@cyberus.ca Thu Apr 7 04:06:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 04:06:22 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37B6Ak5024673 for ; Thu, 7 Apr 2005 04:06:10 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DJUpq-0000m0-A9 for netdev@oss.sgi.com; Thu, 07 Apr 2005 07:06:06 -0400 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 1DJUpo-0007fm-H4; Thu, 07 Apr 2005 07:06:04 -0400 Subject: Re: [RFC] QoS: new per flow queue From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050406210800.0296.LARK@linux.net.cn> References: <20050406123117.0265.LARK@linux.net.cn> <1112789570.1099.37.camel@jzny.localdomain> <20050406210800.0296.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112871961.1117.121.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 07:06:01 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1510 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: 5132 Lines: 151 Wang, On Wed, 2005-04-06 at 09:45, Wang Jian wrote: > Hi jamal, > > > On 06 Apr 2005 08:12:50 -0400, jamal wrote: > > > Essentially rewrite the classid/flowid. In the action just set > > skb->tc_classid and u32 will make sure the packet goes to the correct > > major:minor queue. This already works with kernels >= 2.6.10. > > > > One question: > > Can I set skb->tc_classid in a qdisc and pass this skb to the specified > class to handle? > Well, remember the qdisc asks the filter what class a packet belongs to every time. The best place to change things is at that point. Why not tell the qdisc whatever class you want it to know instead of passing metadata like skb->tc_classid for it to further intepret? > > My idea is that the action itself dynamically creates classes. So you > don't need any other rules. It is looks like #2 but the work is done in > dynfwmark action. The workflow > > 0. setup, and create flow entry hash; > 1. when a packet arrives, check if it is a flow or should be a new flow; > 2. alloc a class id for this flow; so far so good. But you probably wanna drop the packet after a certain upper bound for number of flows is reached. > 3. dynamically create a htb class using the > 4. skb->tc_classid = allocated_ht_class_id > > 1.5 if can't create flow, skb->tc_classid = default_class_id > This may be a little tricky with locks etc. Maybe you could send a netlink message to the qdisc. Perhaps a workthread which creates these classes etc. My suggestion was: a) qdisc asks filter "what class is this packet?" b) filter responds "class 1:234" c) qdisc says "hrm, dont have that class. call create_default_class" d) qdisc::create_default_class() create class and set default parameters. Default parameters are passed from user space (eg 10kbps rate etc). e) enqueue packet on new queue. Also now you have to create the dynamic class rewriter action and change a qdisc ;-> What i was saying earlier is that the create_default_class maybe a good addition to qdiscs. The question is do you keep those queues forver or kill them after a period of no activity? The idea of creating them permanently upto a certain max numbers is probably ok. It will be no different than creating them via a script. > > One thing i noticed is that you dont have multiple queues actually in > > your code - did i misread that? i.e multiple classes go to the same > > queue. > > > > Didn't you notice that it is a classless qdisc? The queue is per qdisc, > not per class :) Sorry missed that ;-> > It is the parent class's duty to define what kind of > flow this qdisc handle. It is very generic, you can even mix UDP/TCP > flows together but I don't think it is good idea. > Doesnt that defeat the purpose of it being "per flow queue" ;-> > Think the scenario > > 1. You have VoIP flows (UDP) > 2. You have pptp vpn flows (eh, per flow can't handle it at this time, I > think) > > You create HTBs for them, and use filter to classify them. And then, use > per flow qdisc as the only child of these HTBs. per flow qdisc will > guarantee the per flow QoS. > I got this. Of course you understand creating all these filters and queues is taking system resources. It may be sufficient to create heuristics like a simple priority qdisc where you put voip as first class citizen, vpn as second and rest as best effort. > > The only unfriendliness to user space is in #1 where you end up having a > > script creating as many classes as you need. It is _not_ bloat because > > you dont add any code at all. It is anti-bloat actually ;-> > > > > In this way, it is very hard to write good user interface in userspace. > My current implementation takes good user-friendly (or user space > scripter/programmer friendly) into serious consideration. > It is not hard - its annoying in user space ;-> You could write a for loop to produce them. such as: for i stating from 1 to 1000 tc class add .... rate 10Kbps classid 1:$i endfor Trying to list those classes will list at least a 1000 lines of course. But this listing issue will happen even when you dynamically create these classes. So annoyance is more descriptive. > The 'bloated' comment is on the > > "If it carries an unique id or something like in its own namespace, then > it can be clean and friendly for userspace" > I am not disagreeing with you. If you want to go that path instead what i am saying is its more coding. > I think too much and my thought is jumpy ;) You even didn't notice that > I gave another suggestion on implementation in this sentence. > What? You did? just kidding;-> > > I am suprised no one has compared all the rate control schemes. > > > > btw, would policing also suffice for you? The only difference is it will > > drop packets if you exceed your rate. You can also do hierachical > > sharing. > > policy suffices, but doesn't serve the purpose of per flow queue. > Policing will achieve the goal of rate control without worrying about any queueing. I like the idea of someone trying to create dynamic queues though ;-> cheers, jamal From hadi@cyberus.ca Thu Apr 7 04:07:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 04:07:51 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37B7h4C025113 for ; Thu, 7 Apr 2005 04:07:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJUrL-0003os-Vy for netdev@oss.sgi.com; Thu, 07 Apr 2005 07:07:39 -0400 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 1DJUrK-0007qz-DI; Thu, 07 Apr 2005 07:07:38 -0400 Subject: Re: [RFC] dynamic hash table size & xor hash function for cls_fw From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , lark@linux.net.cn, netdev In-Reply-To: <20050407105149.GT26731@postel.suug.ch> References: <1112717495.1076.22.camel@jzny.localdomain> <20050406143842.026B.LARK@linux.net.cn> <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> <20050406183134.GR26731@postel.suug.ch> <20050407005519.GS26731@postel.suug.ch> <1112870307.1118.91.camel@jzny.localdomain> <20050407105149.GT26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112872055.1117.123.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 07:07:35 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1511 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: 1964 Lines: 58 ok, gotcha - good idea to leave it as is.. cheers, jamal On Thu, 2005-04-07 at 06:51, Thomas Graf wrote: > * jamal <1112870307.1118.91.camel@jzny.localdomain> 2005-04-07 06:38 > > On Wed, 2005-04-06 at 20:55, Thomas Graf wrote: > > > > > > > > static __inline__ int fw_hash(u32 handle) > > > { > > > - return handle&0xFF; > > > + if (HTSIZE == 4096) > > > + return ((handle >> 24) & 0xFFF) ^ > > > + ((handle >> 12) & 0xFFF) ^ > > > + (handle & 0xFFF); > > > + else if (HTSIZE == 2048) > > > + return ((handle >> 22) & 0x7FF) ^ > > > + ((handle >> 11) & 0x7FF) ^ > > > + (handle & 0x7FF); > > > + else if (HTSIZE == 1024) > > > + return ((handle >> 20) & 0x3FF) ^ > > > + ((handle >> 10) & 0x3FF) ^ > > > + (handle & 0x3FF); > > > + else if (HTSIZE == 512) > > > + return (handle >> 27) ^ > > > + ((handle >> 18) & 0x1FF) ^ > > > + ((handle >> 9) & 0x1FF) ^ > > > + (handle & 0x1FF); > > > + else if (HTSIZE == 256) { > > > + u8 *t = (u8 *) &handle; > > > + return t[0] ^ t[1] ^ t[2] ^ t[3]; > > > + } else > > > + return handle & (HTSIZE - 1); > > > } > > > > Does HTSIZE change at runtime? How does migrating from one to other take > > place? > > No, the size is static (PAGE_SIZE/sizeof(unsigned long)) (typically 1024). > > > Also why not have a function pointer with a series of these being > > separate instead of doing the if checks? > > Because it is static, gcc will optimize and remove all branches leaving > only the one that is actually needed, i.e. on most systems the hash > function will get down to the contents of the if (HTSIZE == 1024) branch. > > > BTW it does seem any one of those hashes maybe sufficient, no? > > If we want to do the xor'ing to maintain collision free hashing > for the most common case we need to separate. It would be possible > to play games and calculate the shifts etc but gcc has a hard > time optimizing such things. > From herbert@gondor.apana.org.au Thu Apr 7 04:08:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 04:08:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37B8bDi025579 for ; Thu, 7 Apr 2005 04:08:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJUrX-00012U-00; Thu, 07 Apr 2005 21:07:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJUr6-0002JV-00; Thu, 07 Apr 2005 21:07:24 +1000 Date: Thu, 7 Apr 2005 21:07:24 +1000 To: "David S. Miller" Cc: christoph@lameter.com, netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: <20050407110724.GA8760@gondor.apana.org.au> References: <20050406111721.3ac67605.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20050406111721.3ac67605.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2348 Lines: 88 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 06, 2005 at 11:17:21AM -0700, David S. Miller wrote: > > See his other emails in this thread. If it can be converted to > atomic_dec() then he wants to change the counter into an array > of counters on NUMA systems. > > But his trick only works if the atomic_dec_and_test() can be eliminated > for all cases, which we're now quite certain is not possible. OK I've thought more about this and indeed it is possible to get rid of atomic_dec_and_test. As you can see from my previous patch, it is possible to restrict the use of atomic_dec_and_test to the NOHASH path. However, for NOHASH dst entries we know that 1) They're not in a hash table. 2) They're not on the GC list. Therefore it is safe to look at the entry even after dropping our reference count. This is what the following patch does. I added the unlikely on dst since entries with child pointers are rare in most systems. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- linux-2.6/net/core/dst.c.orig 2005-04-07 20:48:25.000000000 +1000 +++ linux-2.6/net/core/dst.c 2005-04-07 20:57:33.000000000 +1000 @@ -169,9 +169,9 @@ struct neighbour *neigh; struct hh_cache *hh; +again: smp_rmb(); -again: neigh = dst->neighbour; hh = dst->hh; child = dst->child; @@ -197,19 +197,19 @@ kmem_cache_free(dst->ops->kmem_cachep, dst); dst = child; - if (dst) { + if (unlikely(dst)) { int nohash = dst->flags & DST_NOHASH; - if (atomic_dec_and_test(&dst->__refcnt)) { + atomic_dec(&dst->__refcnt); + + if (nohash) { /* We were real parent of this dst, so kill child. */ - if (nohash) + if (!atomic_read(&dst->__refcnt)) goto again; - } else { /* Child is still referenced, return it for freeing. */ - if (nohash) - return dst; - /* Child is still in his hash table */ + return dst; } + /* Child is still in his hash table or on the GC list. */ } return NULL; } --u3/rZRmxL6MmkK24-- From herbert@gondor.apana.org.au Thu Apr 7 04:24:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 04:24:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37BOddG031319 for ; Thu, 7 Apr 2005 04:24:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJV7L-0001A4-00; Thu, 07 Apr 2005 21:24:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJV6r-0002Nu-00; Thu, 07 Apr 2005 21:23:41 +1000 From: Herbert Xu To: pravins@calsoftinc.com (pravin b shelar) Subject: Re: Fwd: atomic_dec_and_test for child dst needed in dst_destroy? Cc: christoph@lameter.com, netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <4253A3A0.800@calsoftinc.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 07 Apr 2005 21:23:41 +1000 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 696 Lines: 22 pravin b shelar wrote: > > This patch will remove the need for atomic_dec_and_test for this > particular case. > Now we can break down the atomic_dec_and_test to atomic_dec & atomic_read. Sorry I overlooked your patch. Otherwise we could have solved this one day earlier :) > Please comment. There is just one problem. We need an extra barrier before or after the goto since we no longer have the implicit barrier given by atomic_dec_and_test. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Thu Apr 7 04:31:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 04:31:10 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37BV6Qr032093 for ; Thu, 7 Apr 2005 04:31:06 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DJVDy-0004wg-Fe for netdev@oss.sgi.com; Thu, 07 Apr 2005 07:31:02 -0400 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 1DJVDw-00034d-Sb; Thu, 07 Apr 2005 07:31:01 -0400 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: jamal Reply-To: hadi@cyberus.ca To: Dmitry Yusupov Cc: Herbert Xu , Mike Christie , netdev , "David S. Miller" In-Reply-To: <1112826385.16753.99.camel@beastie> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112873457.1119.129.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 07:30:57 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1514 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: 104 Lines: 9 On Wed, 2005-04-06 at 18:26, Dmitry Yusupov wrote: > (see Open-iSCSI interface). url? cheers, jamal From herbert@gondor.apana.org.au Thu Apr 7 05:19:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 05:19:32 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37CJMv6004253 for ; Thu, 7 Apr 2005 05:19:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJVyU-0001YV-00; Thu, 07 Apr 2005 22:19:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJVy3-0004L9-00; Thu, 07 Apr 2005 22:18:39 +1000 Date: Thu, 7 Apr 2005 22:18:39 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [2/*] [NET] Shave 8 bytes off dst_entry on 64-bit Message-ID: <20050407121839.GA9641@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2576 Lines: 85 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This series of patches will be dedicated to the routing cache. Before I start working on the routing cache itself, I need to fix some of the issues with the multipath caching code (it happens to be in the critical places where I'll be changing the code). I've already sent you one patch that disables the multipath cache addition on the input path until we actually start using it. The next problem I'm going to tackle is to do with how the multipath cache entries are handled. Currently they're added one by one and live a semi-independent life once they're in the cache. This is buggy since two CPUs could both get a routing cache miss and then decide to add the multipath entries for the same route. We will then end up with two copies of the same route. The solution is to create them all and then insert them all at once. However, the fact that one route can now spawn a large number of routing entries on the chain is bad for chain length management since 1) It may look like hash collision when it isn't. 2) It means that we have to walk over more entries when there is a collision. The solution is to put the multipath entries of the same route onto its own linked list and only link the head of the list into the routing cache. This solution requires the addition of a new pointer into rtable. Well I felt guilty for doing that so that's why I'm sending you this patch :) This rearranges dst_entry so that we shave off 8 bytes on 64-bit platforms when CLS_ROUTE is enabled. Signed-off-by: Herbert Xu I'll rearrange rtable next which will save us some more. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=route-2 ===== include/net/dst.h 1.32 vs edited ===== --- 1.32/include/net/dst.h 2005-03-19 05:44:52 +11:00 +++ edited/include/net/dst.h 2005-04-07 11:06:20 +10:00 @@ -61,14 +61,14 @@ unsigned long rate_last; /* rate limiting for ICMP */ unsigned long rate_tokens; - int error; - struct neighbour *neighbour; struct hh_cache *hh; struct xfrm_state *xfrm; int (*input)(struct sk_buff*); int (*output)(struct sk_buff*); + + int error; #ifdef CONFIG_NET_CLS_ROUTE __u32 tclassid; --fUYQa+Pmc3FrFX/N-- From pravins@calsoftinc.com Thu Apr 7 05:26:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 05:26:29 -0700 (PDT) Received: from ganesha.intranet.calsoftinc.com ([220.225.34.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37CQK4T005036 for ; Thu, 7 Apr 2005 05:26:21 -0700 Received: from [172.16.0.108] (unknown [172.16.0.108]) by ganesha.intranet.calsoftinc.com (Postfix) with ESMTP id C31FADB58A; Thu, 7 Apr 2005 17:48:36 +0530 (IST) Message-ID: <425527D8.4030408@calsoftinc.com> Date: Thu, 07 Apr 2005 18:00:16 +0530 From: pravin b shelar User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: christoph@lameter.com, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: Fwd: atomic_dec_and_test for child dst needed in dst_destroy? References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040604060301020209000207" X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pravins@calsoftinc.com Precedence: bulk X-list: netdev Content-Length: 2258 Lines: 88 This is a multi-part message in MIME format. --------------040604060301020209000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: >pravin b shelar wrote: > > >>This patch will remove the need for atomic_dec_and_test for this >>particular case. >>Now we can break down the atomic_dec_and_test to atomic_dec & atomic_read. >> >> > >Sorry I overlooked your patch. Otherwise we could have solved this >one day earlier :) > > ah ... I was just waiting :) > > >>Please comment. >> >> > >There is just one problem. We need an extra barrier before or after >the goto since we no longer have the implicit barrier given by >atomic_dec_and_test. > > I am attaching updated patch with barrier. Regards, Pravin. --------------040604060301020209000207 Content-Type: text/x-patch; name="dst-atomic_dec_and_test-removed.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dst-atomic_dec_and_test-removed.patch" This patch removes atomic_dec_and_test from dst_destroy, used to test child dst __refcnt. Signed-off by: Pravin B. Shelar Index: linux-2.6.11-dsta/net/core/dst.c =================================================================== --- linux-2.6.11-dsta.orig/net/core/dst.c 2005-04-06 00:18:32.000000000 -0700 +++ linux-2.6.11-dsta/net/core/dst.c 2005-04-07 04:53:28.000000000 -0700 @@ -198,17 +198,21 @@ dst = child; if (dst) { - if (atomic_dec_and_test(&dst->__refcnt)) { - /* We were real parent of this dst, so kill child. */ - if (dst->flags&DST_NOHASH) - goto again; - } else { - /* Child is still referenced, return it for freeing. */ - if (dst->flags&DST_NOHASH) - return dst; - /* Child is still in his hash table */ + if (dst->flags&DST_NOHASH) { + atomic_dec(&dst->__refcnt); + smp_mb__after_atomic_dec(); + + if (atomic_read(&dst->__refcnt)) + /*-- Child is still referenced, return it for freeing. */ + return dst; + + /*We were real parent of this dst, so kill child. */ + goto again; } + else /* Child is still in his hash table */ + atomic_dec(&dst->__refcnt); } + return NULL; } --------------040604060301020209000207-- From tgraf@suug.ch Thu Apr 7 06:09:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 06:09:16 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37D98Rk007494 for ; Thu, 7 Apr 2005 06:09:08 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id F3AFA8D; Thu, 7 Apr 2005 15:08:43 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id A24271C0EA; Thu, 7 Apr 2005 15:09:25 +0200 (CEST) Date: Thu, 7 Apr 2005 15:09:25 +0200 From: Thomas Graf To: "David S. Miller" Cc: lark@linux.net.cn, Jamal Hadi Salim , netdev Subject: [PATCH] [PKT_SCHED]: improve hashing performance of cls_fw Message-ID: <20050407130925.GU26731@postel.suug.ch> References: <20050406123036.GO26731@postel.suug.ch> <1112794459.1096.61.camel@jzny.localdomain> <20050406134502.GP26731@postel.suug.ch> <20050406141020.GQ26731@postel.suug.ch> <20050406111509.0462abcf.davem@davemloft.net> <20050406183134.GR26731@postel.suug.ch> <20050407005519.GS26731@postel.suug.ch> <1112870307.1118.91.camel@jzny.localdomain> <20050407105149.GT26731@postel.suug.ch> <1112872055.1117.123.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112872055.1117.123.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4183 Lines: 143 Some test results for the new hashing Test-1: hash 0..2147483648 old 256 buckets hash (enum): empty buckets: 0 average chain length: 8388607.996 min: 8388607 max: 8388608 new 1024 buckets hash (enum): empty buckets: 0 average chain length: 2097151.999 min: 2097151 max: 2097152 Test-2: hash 65536*rand() old 256 buckets hash (rand): empty buckets: 0 average chain length: 256.000 min: 222 max: 296 new 1024 buckets hash (rand): empty buckets: 0 average chain length: 64.000 min: 40 max: 93 Test-3: hash 1024*rand() old 256 buckets hash (rand): empty buckets: 3 average chain length: 4.047 min: 0 max: 9 new 1024 buckets hash (rand): empty buckets: 380 average chain length: 1.590 min: 0 max: 5 Test-4: total time for 2147483648 hashes, 10 runs old hashing algorithm new hashing algorithm 1.619s 1.610s 1.623s 1.611s 1.625s 1.612s 1.629s 1.614s 1.633s 1.616s 1.637s 1.621s 1.638s 1.625s 1.639s 1.630s 1.644s 1.632s 1.737s 1.658s Please do a bk pull bk://kernel.bkbits.net/tgraf/net-2.6-cls_fw This will update the following files: net/sched/cls_fw.c | 31 +++++++++++++++++++++++++++---- 1 files changed, 27 insertions(+), 4 deletions(-) through these ChangeSets: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/07 14:23:09+02:00 tgraf@suug.ch # [PKT_SCHED]: improve hashing performance of cls_fw # # Calculate hashtable size to fit into a page instead of a hardcoded # 256 buckets hash table. Results in a 1024 buckets hashtable on # most systems. # # Replace old naive extract-8-lsb-bits algorithm with a better # algorithm xor'ing 3 or 4 bit fields at the size of the hashtable # array index in order to improve distribution if the majority of # the lower bits are unused while keeping zero collision behaviour # for the most common use case. # # Thanks to Wang Jian for bringing this issue # to attention and to Eran Mann for the initial # idea for this new algorithm. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/sched/cls_fw.c # 2005/04/07 14:22:58+02:00 tgraf@suug.ch +27 -4 # [PKT_SCHED]: improve hashing performance of cls_fw # diff -Nru a/net/sched/cls_fw.c b/net/sched/cls_fw.c --- a/net/sched/cls_fw.c 2005-04-07 14:55:55 +02:00 +++ b/net/sched/cls_fw.c 2005-04-07 14:55:55 +02:00 @@ -46,9 +46,11 @@ #include #include +#define HTSIZE (PAGE_SIZE/sizeof(struct fw_filter *)) + struct fw_head { - struct fw_filter *ht[256]; + struct fw_filter *ht[HTSIZE]; }; struct fw_filter @@ -69,7 +71,28 @@ static __inline__ int fw_hash(u32 handle) { - return handle&0xFF; + if (HTSIZE == 4096) + return ((handle >> 24) & 0xFFF) ^ + ((handle >> 12) & 0xFFF) ^ + (handle & 0xFFF); + else if (HTSIZE == 2048) + return ((handle >> 22) & 0x7FF) ^ + ((handle >> 11) & 0x7FF) ^ + (handle & 0x7FF); + else if (HTSIZE == 1024) + return ((handle >> 20) & 0x3FF) ^ + ((handle >> 10) & 0x3FF) ^ + (handle & 0x3FF); + else if (HTSIZE == 512) + return (handle >> 27) ^ + ((handle >> 18) & 0x1FF) ^ + ((handle >> 9) & 0x1FF) ^ + (handle & 0x1FF); + else if (HTSIZE == 256) { + u8 *t = (u8 *) &handle; + return t[0] ^ t[1] ^ t[2] ^ t[3]; + } else + return handle & (HTSIZE - 1); } static int fw_classify(struct sk_buff *skb, struct tcf_proto *tp, @@ -152,7 +175,7 @@ if (head == NULL) return; - for (h=0; h<256; h++) { + for (h=0; hht[h]) != NULL) { head->ht[h] = f->next; fw_delete_filter(tp, f); @@ -291,7 +314,7 @@ if (arg->stop) return; - for (h = 0; h < 256; h++) { + for (h = 0; h < HTSIZE; h++) { struct fw_filter *f; for (f = head->ht[h]; f; f = f->next) { From lark@linux.net.cn Thu Apr 7 06:14:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 06:14:58 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37DElX4008162 for ; Thu, 7 Apr 2005 06:14:48 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 20FF33EE70; Thu, 7 Apr 2005 21:14:43 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 23412-03; Thu, 7 Apr 2005 21:14:38 +0800 (CST) Received: from [192.168.0.120] (unknown [221.221.5.129]) by mx.linux.net.cn (Postfix) with ESMTP id 1EE013EC0B; Thu, 7 Apr 2005 21:14:38 +0800 (CST) Date: Thu, 07 Apr 2005 21:14:38 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [RFC] QoS: new per flow queue Cc: netdev In-Reply-To: <1112871961.1117.121.camel@jzny.localdomain> References: <20050406210800.0296.LARK@linux.net.cn> <1112871961.1117.121.camel@jzny.localdomain> Message-Id: <20050407203631.02CF.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 4835 Lines: 143 Hi jamal, On 07 Apr 2005 07:06:01 -0400, jamal wrote: > > > > One question: > > > > Can I set skb->tc_classid in a qdisc and pass this skb to the specified > > class to handle? > > > > Well, remember the qdisc asks the filter what class a packet belongs to > every time. The best place to change things is at that point. Why not > tell the qdisc whatever class you want it to know instead of passing > metadata like skb->tc_classid for it to further intepret? > 1. a flow (in my perflow queue implementation) is a tuple of five elements, but, for some reason, if the users misused this queue and send non-flow packet, e.g. ICMP packet here; 2. a queue is configured to handle 100 flows, but the 101st flow comes; For this two situations, currently, the implementation just drops packets. However, a clean way is to reclassify the packet into another class (default) and provides no per flow guarantee. > > > > Didn't you notice that it is a classless qdisc? The queue is per qdisc, > > not per class :) > > Sorry missed that ;-> > > > It is the parent class's duty to define what kind of > > flow this qdisc handle. It is very generic, you can even mix UDP/TCP > > flows together but I don't think it is good idea. > > > > Doesnt that defeat the purpose of it being "per flow queue" ;-> Per flow queue, is not one queue per flow ;) It is queue which can provide bandwidth assurance and constraint per flow. The implementation can be either one queue per flow, or all flows fit into one queue. > > > Think the scenario > > > > 1. You have VoIP flows (UDP) > > 2. You have pptp vpn flows (eh, per flow can't handle it at this time, I > > think) > > > > You create HTBs for them, and use filter to classify them. And then, use > > per flow qdisc as the only child of these HTBs. per flow qdisc will > > guarantee the per flow QoS. > > > > I got this. Of course you understand creating all these filters and > queues is taking system resources. It may be sufficient to create > heuristics like a simple priority qdisc where you put voip as first > class citizen, vpn as second and rest as best effort. As I already said, this approach has drawbacks 1. when flow count overlimit, no guarantee 2. when flow count is underlimit, the guaranteed sum bandwidth can be exploited to waste bandwidth. So, thinking of per flow queue, it is "queue which can provide bandwidth assurance and constraint per flow", and with only one queue! You only need to create one HTB, one filter and one per flow queue for VoIP; and one HTB, one filter and one per flow queue for VPN. I think the "per flow" name does confuse you ;) My fault. > > > > The only unfriendliness to user space is in #1 where you end up having a > > > script creating as many classes as you need. It is _not_ bloat because > > > you dont add any code at all. It is anti-bloat actually ;-> > > > > > > > In this way, it is very hard to write good user interface in userspace. > > My current implementation takes good user-friendly (or user space > > scripter/programmer friendly) into serious consideration. > > > > It is not hard - its annoying in user space ;-> > You could write a for loop to produce them. such as: > > for i stating from 1 to 1000 > tc class add .... rate 10Kbps classid 1:$i > endfor > > Trying to list those classes will list at least a 1000 lines of course. > But this listing issue will happen even when you dynamically create > these classes. > So annoyance is more descriptive. > The problem occurs when you delete and add, and so on. It not good idea to reuse a used classid when there is stream classified as old. For example, you give class 1:1000 htb rate 200kbps ceil 200kbps for http, and you delete the class 1:1000 and redefine 1:1000 htb rate 30kbps ceil 30kbps for ftp. At this time, the remained http streams carries a CONNMARK and restore to MARK and then classified as 1:0000. Then 1:1000 is not what you want. > > > > I am suprised no one has compared all the rate control schemes. > > > > > > btw, would policing also suffice for you? The only difference is it will > > > drop packets if you exceed your rate. You can also do hierachical > > > sharing. > > > > policy suffices, but doesn't serve the purpose of per flow queue. > > > > Policing will achieve the goal of rate control without worrying about > any queueing. I like the idea of someone trying to create dynamic queues > though ;-> > You need per flow queue to control something, like VoIP streams, or VPN streams. If you just use policy, mixed traffic is send to per flow queue. That is definitely not the purpose of per flow queue. The dynamic queue creating is another way to implement the per flow control (yes, one class and queue per flow). I think it is more complex and wastes resources. -- lark From herbert@gondor.apana.org.au Thu Apr 7 06:26:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 06:26:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37DQ6ba009009 for ; Thu, 7 Apr 2005 06:26:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJX15-00023j-00; Thu, 07 Apr 2005 23:25:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJX0d-000619-00; Thu, 07 Apr 2005 23:25:23 +1000 Date: Thu, 7 Apr 2005 23:25:23 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [2/*] [NET] Shave 8 bytes off dst_entry on 64-bit Message-ID: <20050407132523.GA20795@gondor.apana.org.au> References: <20050407121839.GA9641@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20050407121839.GA9641@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1678 Lines: 62 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 07, 2005 at 10:18:39PM +1000, herbert wrote: > > This rearranges dst_entry so that we shave off 8 bytes on 64-bit > platforms when CLS_ROUTE is enabled. > > Signed-off-by: Herbert Xu > > I'll rearrange rtable next which will save us some more. Unfortunately that turned out to be a nightmare due to the way rt_flags is used. So I came back to dst_entry to look for things to axe :) So instead of moving error down let's move it up and shrink it and obsolete which saves a pointer width on both 32-bit and 64-bit platforms. Signed-off-by: Herbert Xu Please note that this is NOT incremental to the last patch. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=route-2 ===== include/net/dst.h 1.32 vs edited ===== --- 1.32/include/net/dst.h 2005-03-19 05:44:52 +11:00 +++ edited/include/net/dst.h 2005-04-07 23:24:19 +10:00 @@ -42,7 +42,8 @@ int __use; struct dst_entry *child; struct net_device *dev; - int obsolete; + short error; + short obsolete; int flags; #define DST_HOST 1 #define DST_NOXFRM 2 @@ -60,8 +61,6 @@ unsigned long rate_last; /* rate limiting for ICMP */ unsigned long rate_tokens; - - int error; struct neighbour *neighbour; struct hh_cache *hh; --VS++wcV0S1rZb1Fb-- From lark@linux.net.cn Thu Apr 7 06:31:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 06:32:00 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37DVlA4009684 for ; Thu, 7 Apr 2005 06:31:52 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id A18F63EE70; Thu, 7 Apr 2005 21:31:42 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 23412-04-12; Thu, 7 Apr 2005 21:31:38 +0800 (CST) Received: from [192.168.0.120] (unknown [221.221.5.129]) by mx.linux.net.cn (Postfix) with ESMTP id 6960A3EC0B; Thu, 7 Apr 2005 21:31:38 +0800 (CST) Date: Thu, 07 Apr 2005 21:31:38 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] [PKT_SCHED]: improve hashing performance of cls_fw Cc: "David S. Miller" , Jamal Hadi Salim , netdev In-Reply-To: <20050407130925.GU26731@postel.suug.ch> References: <1112872055.1117.123.camel@jzny.localdomain> <20050407130925.GU26731@postel.suug.ch> Message-Id: <20050407212340.02D2.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 4767 Lines: 163 Hi Thomas Graf, Would you please test this case? (0..1024) << 16 The old hash gives a 1024 depth bucket for this case. And I am not sure if there is a bad range (0..n) << s which is mapped into one bucket. On Thu, 7 Apr 2005 15:09:25 +0200, Thomas Graf wrote: > Some test results for the new hashing > > Test-1: hash 0..2147483648 > > old 256 buckets hash (enum): > empty buckets: 0 average chain length: 8388607.996 min: 8388607 max: 8388608 > > new 1024 buckets hash (enum): > empty buckets: 0 average chain length: 2097151.999 min: 2097151 max: 2097152 > > Test-2: hash 65536*rand() > > old 256 buckets hash (rand): > empty buckets: 0 average chain length: 256.000 min: 222 max: 296 > > new 1024 buckets hash (rand): > empty buckets: 0 average chain length: 64.000 min: 40 max: 93 > > Test-3: hash 1024*rand() > > old 256 buckets hash (rand): > empty buckets: 3 average chain length: 4.047 min: 0 max: 9 > > new 1024 buckets hash (rand): > empty buckets: 380 average chain length: 1.590 min: 0 max: 5 > > Test-4: total time for 2147483648 hashes, 10 runs > > old hashing algorithm new hashing algorithm > 1.619s 1.610s > 1.623s 1.611s > 1.625s 1.612s > 1.629s 1.614s > 1.633s 1.616s > 1.637s 1.621s > 1.638s 1.625s > 1.639s 1.630s > 1.644s 1.632s > 1.737s 1.658s > > > Please do a > > bk pull bk://kernel.bkbits.net/tgraf/net-2.6-cls_fw > > This will update the following files: > > net/sched/cls_fw.c | 31 +++++++++++++++++++++++++++---- > 1 files changed, 27 insertions(+), 4 deletions(-) > > through these ChangeSets: > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2005/04/07 14:23:09+02:00 tgraf@suug.ch > # [PKT_SCHED]: improve hashing performance of cls_fw > # > # Calculate hashtable size to fit into a page instead of a hardcoded > # 256 buckets hash table. Results in a 1024 buckets hashtable on > # most systems. > # > # Replace old naive extract-8-lsb-bits algorithm with a better > # algorithm xor'ing 3 or 4 bit fields at the size of the hashtable > # array index in order to improve distribution if the majority of > # the lower bits are unused while keeping zero collision behaviour > # for the most common use case. > # > # Thanks to Wang Jian for bringing this issue > # to attention and to Eran Mann for the initial > # idea for this new algorithm. > # > # Signed-off-by: Thomas Graf > # Signed-off-by: David S. Miller > # > # net/sched/cls_fw.c > # 2005/04/07 14:22:58+02:00 tgraf@suug.ch +27 -4 > # [PKT_SCHED]: improve hashing performance of cls_fw > # > diff -Nru a/net/sched/cls_fw.c b/net/sched/cls_fw.c > --- a/net/sched/cls_fw.c 2005-04-07 14:55:55 +02:00 > +++ b/net/sched/cls_fw.c 2005-04-07 14:55:55 +02:00 > @@ -46,9 +46,11 @@ > #include > #include > > +#define HTSIZE (PAGE_SIZE/sizeof(struct fw_filter *)) > + > struct fw_head > { > - struct fw_filter *ht[256]; > + struct fw_filter *ht[HTSIZE]; > }; > > struct fw_filter > @@ -69,7 +71,28 @@ > > static __inline__ int fw_hash(u32 handle) > { > - return handle&0xFF; > + if (HTSIZE == 4096) > + return ((handle >> 24) & 0xFFF) ^ > + ((handle >> 12) & 0xFFF) ^ > + (handle & 0xFFF); > + else if (HTSIZE == 2048) > + return ((handle >> 22) & 0x7FF) ^ > + ((handle >> 11) & 0x7FF) ^ > + (handle & 0x7FF); > + else if (HTSIZE == 1024) > + return ((handle >> 20) & 0x3FF) ^ > + ((handle >> 10) & 0x3FF) ^ > + (handle & 0x3FF); > + else if (HTSIZE == 512) > + return (handle >> 27) ^ > + ((handle >> 18) & 0x1FF) ^ > + ((handle >> 9) & 0x1FF) ^ > + (handle & 0x1FF); > + else if (HTSIZE == 256) { > + u8 *t = (u8 *) &handle; > + return t[0] ^ t[1] ^ t[2] ^ t[3]; > + } else > + return handle & (HTSIZE - 1); > } > > static int fw_classify(struct sk_buff *skb, struct tcf_proto *tp, > @@ -152,7 +175,7 @@ > if (head == NULL) > return; > > - for (h=0; h<256; h++) { > + for (h=0; h while ((f=head->ht[h]) != NULL) { > head->ht[h] = f->next; > fw_delete_filter(tp, f); > @@ -291,7 +314,7 @@ > if (arg->stop) > return; > > - for (h = 0; h < 256; h++) { > + for (h = 0; h < HTSIZE; h++) { > struct fw_filter *f; > > for (f = head->ht[h]; f; f = f->next) { -- lark From tgraf@suug.ch Thu Apr 7 06:52:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 06:52:26 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37DqKFk010757 for ; Thu, 7 Apr 2005 06:52:21 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id B0A3A8D; Thu, 7 Apr 2005 15:51:57 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9497E1C0EA; Thu, 7 Apr 2005 15:52:40 +0200 (CEST) Date: Thu, 7 Apr 2005 15:52:40 +0200 From: Thomas Graf To: Wang Jian Cc: "David S. Miller" , Jamal Hadi Salim , netdev Subject: Re: [PATCH] [PKT_SCHED]: improve hashing performance of cls_fw Message-ID: <20050407135240.GV26731@postel.suug.ch> References: <1112872055.1117.123.camel@jzny.localdomain> <20050407130925.GU26731@postel.suug.ch> <20050407212340.02D2.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050407212340.02D2.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 452 Lines: 15 * Wang Jian <20050407212340.02D2.LARK@linux.net.cn> 2005-04-07 21:31 > Would you please test this case? > > (0..1024) << 16 > > The old hash gives a 1024 depth bucket for this case. > > And I am not sure if there is a bad range (0..n) << s which is mapped > into one bucket. old hash (enum shift): empty buckets: 255 average chain length: 1024.000 min: 0 max: 1024 new hash (enum shift): empty buckets: 0 average chain length: 1.000 min: 1 max: 1 From lark@linux.net.cn Thu Apr 7 07:03:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 07:03:50 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37E3f8s011574 for ; Thu, 7 Apr 2005 07:03:44 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 0C2A13EE70; Thu, 7 Apr 2005 22:03:36 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 24177-01; Thu, 7 Apr 2005 22:03:33 +0800 (CST) Received: from [192.168.0.120] (unknown [221.221.5.129]) by mx.linux.net.cn (Postfix) with ESMTP id 862C83EC0B; Thu, 7 Apr 2005 22:03:33 +0800 (CST) Date: Thu, 07 Apr 2005 22:03:33 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [PATCH] [PKT_SCHED]: improve hashing performance of cls_fw Cc: "David S. Miller" , Jamal Hadi Salim , netdev In-Reply-To: <20050407135240.GV26731@postel.suug.ch> References: <20050407212340.02D2.LARK@linux.net.cn> <20050407135240.GV26731@postel.suug.ch> Message-Id: <20050407220244.02D5.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 598 Lines: 28 Hi Thomas Graf, Thanks :-) On Thu, 7 Apr 2005 15:52:40 +0200, Thomas Graf wrote: > * Wang Jian <20050407212340.02D2.LARK@linux.net.cn> 2005-04-07 21:31 > > Would you please test this case? > > > > (0..1024) << 16 > > > > The old hash gives a 1024 depth bucket for this case. > > > > And I am not sure if there is a bad range (0..n) << s which is mapped > > into one bucket. > > old hash (enum shift): > empty buckets: 255 average chain length: 1024.000 min: 0 max: 1024 > > new hash (enum shift): > empty buckets: 0 average chain length: 1.000 min: 1 max: 1 -- lark From dmitry_yus@yahoo.com Thu Apr 7 08:05:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 08:05:25 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j37F5Krk014500 for ; Thu, 7 Apr 2005 08:05:20 -0700 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp015.mail.yahoo.com with SMTP; 7 Apr 2005 15:05:16 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: hadi@cyberus.ca Cc: Herbert Xu , Mike Christie , netdev , "David S. Miller" In-Reply-To: <1112873457.1119.129.camel@jzny.localdomain> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <1112873457.1119.129.camel@jzny.localdomain> Content-Type: text/plain Date: Thu, 07 Apr 2005 08:05:12 -0700 Message-Id: <1112886312.14063.0.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 198 Lines: 13 http://www.open-iscsi.org On Thu, 2005-04-07 at 07:30 -0400, jamal wrote: > On Wed, 2005-04-06 at 18:26, Dmitry Yusupov wrote: > > > (see Open-iSCSI interface). > > url? > > cheers, > jamal > From christoph@graphe.net Thu Apr 7 09:01:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 09:01:36 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37G1Vg3020594 for ; Thu, 7 Apr 2005 09:01:31 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJZR5-0007qm-CG; Thu, 07 Apr 2005 09:00:55 -0700 Date: Thu, 7 Apr 2005 09:00:51 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050407110724.GA8760@gondor.apana.org.au> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 1133 Lines: 37 On Thu, 7 Apr 2005, Herbert Xu wrote: > However, for NOHASH dst entries we know that > > 1) They're not in a hash table. > 2) They're not on the GC list. > > Therefore it is safe to look at the entry even after dropping our > reference count. In an earlier email you said that there was a slight chance that child entries (typically NOHASH from what I can see in the code) could be on the gc list. If its not on the hash table and not on the gc list then how could the refcnt be > 1 ? Doesnt the refcnt > 1 imply that multiple concurrent accesses are possible? Also if this is as you say then both types of entries better be treated in a distinct way for clarity in the code. This also avoids having a nohash variable: if ((dst->flags & DST_NOHASH)) { /* dst not on hash and also not on gc list */ atomic_dec(&dst->__refcnt); if (!atomic_read(&dst->refcnt)) /* We were the only reference kill child */ goto again; /* return child to put it on the gc list */ return dst; } /* dst on the hashed list. Decrement refcnt and rely on garbage collector * to eventually remove it */ atomic_dec(&dst->__refcnt); return NULL; From baruch@ev-en.org Thu Apr 7 09:41:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 09:41:57 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37Gfp5V022661 for ; Thu, 7 Apr 2005 09:41:52 -0700 Received: by galon.ev-en.org (Postfix, from userid 1002) id 10FB411AA34; Thu, 7 Apr 2005 19:41:46 +0300 (IDT) Date: Thu, 7 Apr 2005 19:41:46 +0300 From: Baruch Even To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: [PATCH] Too aggressive cwnd backoff Message-ID: <20050407164146.GA6479@ev-en.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1152 Lines: 36 The cwnd backoff is down in two places and drops the cwnd to one quarter instead of to one half. On congestion events we reset tp->ssthresh to the result of tcp_recalc_ssthresh. This cuts the cwnd by half for (New)Reno or to a convoluted calculation for BIC. Later we will call tcp_cwnd_down for each ack and reduce the cwnd by one for every two acks. However, in tcp_cwnd_down we will not stop reducing the cwnd until we get to limit which is set to tp->ssthresh/2. The provided patch will set limit to tp->ssthresh. This was the original behaviour in some older version of Linux. The patch is against 2.6.11 Signed-Off-By: Baruch Even net/ipv4/tcp_input.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: 2.6.11-perf/net/ipv4/tcp_input.c =================================================================== --- 2.6.11-perf.orig/net/ipv4/tcp_input.c +++ 2.6.11-perf/net/ipv4/tcp_input.c @@ -1621,7 +1621,7 @@ static void tcp_cwnd_down(struct tcp_soc */ if (!(limit = tcp_westwood_bw_rttmin(tp))) - limit = tp->snd_ssthresh/2; + limit = tp->snd_ssthresh; tp->snd_cwnd_cnt = decr&1; decr >>= 1; From shemminger@osdl.org Thu Apr 7 10:17:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 10:17:51 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37HHiaV024296 for ; Thu, 7 Apr 2005 10:17:44 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j37HGts4017118 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 10:16:56 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j37HGr7T009423; Thu, 7 Apr 2005 10:16:53 -0700 Date: Thu, 7 Apr 2005 10:16:53 -0700 From: Stephen Hemminger To: Baruch Even Cc: "David S. Miller" , netdev@oss.sgi.com, Werner Almesberger Subject: Re: [PATCH] Too aggressive cwnd backoff Message-ID: <20050407101653.2cc68db1@dxpl.pdx.osdl.net> In-Reply-To: <20050407164146.GA6479@ev-en.org> References: <20050407164146.GA6479@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1526 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: 1387 Lines: 44 On Thu, 7 Apr 2005 19:41:46 +0300 Baruch Even wrote: > The cwnd backoff is down in two places and drops the cwnd to one quarter > instead of to one half. > > On congestion events we reset tp->ssthresh to the result of > tcp_recalc_ssthresh. This cuts the cwnd by half for (New)Reno or to > a convoluted calculation for BIC. > > Later we will call tcp_cwnd_down for each ack and reduce the cwnd by one > for every two acks. > > However, in tcp_cwnd_down we will not stop reducing the cwnd until we > get to limit which is set to tp->ssthresh/2. > > The provided patch will set limit to tp->ssthresh. This was the original > behaviour in some older version of Linux. > > The patch is against 2.6.11 > > Signed-Off-By: Baruch Even I think this is a real problem, and was observed by Werner with umlsim. Don't know when it got introduced because it appears to pre-date the '04 work in adding Westwood, BIC, Vegas. Perhaps Alexey can shed some light on this. Going back to the pre-westwood code in BK, the /2 is still there. ---------------- static void tcp_cwnd_down(struct tcp_opt *tp) { int decr = tp->snd_cwnd_cnt + 1; tp->snd_cwnd_cnt = decr&1; decr >>= 1; if (decr && tp->snd_cwnd > tp->snd_ssthresh/2) tp->snd_cwnd -= decr; tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1); tp->snd_cwnd_stamp = tcp_time_stamp; } From baruch@ev-en.org Thu Apr 7 11:14:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 11:15:01 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37IEukY026695 for ; Thu, 7 Apr 2005 11:14:56 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 910D511AA35; Thu, 7 Apr 2005 21:14:50 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 63B9E11A606; Thu, 7 Apr 2005 21:14:47 +0300 (IDT) Message-ID: <42557895.8040004@ev-en.org> Date: Thu, 07 Apr 2005 19:14:45 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, Werner Almesberger Subject: Re: [PATCH] Too aggressive cwnd backoff References: <20050407164146.GA6479@ev-en.org> <20050407101653.2cc68db1@dxpl.pdx.osdl.net> In-Reply-To: <20050407101653.2cc68db1@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1081 Lines: 25 Stephen Hemminger wrote: > On Thu, 7 Apr 2005 19:41:46 +0300 > Baruch Even wrote: >>The provided patch will set limit to tp->ssthresh. This was the original >>behaviour in some older version of Linux. > > I think this is a real problem, and was observed by Werner with umlsim. > Don't know when it got introduced because it appears to pre-date the > '04 work in adding Westwood, BIC, Vegas. Perhaps Alexey can shed some > light on this. > > Going back to the pre-westwood code in BK, the /2 is still there. This wasn't there in 2.4.23 on which on the original work of H-TCP was done. I've encountered it in my work on the 2.6.6 version, but didn't understand all the implications at the time. I've re-encountered it now that I'm redoing the patches to 2.6.11, and it's as good a time as ever to resolve it. The effect is not catastrophic, but it does mean that we leave recovery into slow-start like ascend of cwnd until we get to ssthresh again. It does mean that after recovery we inject a lot of packets to the network at a very fast rate. Baruch From davem@davemloft.net Thu Apr 7 11:33:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 11:33:42 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37IXaml028228 for ; Thu, 7 Apr 2005 11:33:37 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJbmj-0004LD-00; Thu, 07 Apr 2005 11:31:21 -0700 Date: Thu, 7 Apr 2005 11:31:21 -0700 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, netdev@oss.sgi.com, werner@almesberger.net Subject: Re: [PATCH] Too aggressive cwnd backoff Message-Id: <20050407113121.31b71a94.davem@davemloft.net> In-Reply-To: <42557895.8040004@ev-en.org> References: <20050407164146.GA6479@ev-en.org> <20050407101653.2cc68db1@dxpl.pdx.osdl.net> <42557895.8040004@ev-en.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 475 Lines: 17 On Thu, 07 Apr 2005 19:14:45 +0100 Baruch Even wrote: > > Going back to the pre-westwood code in BK, the /2 is still there. > > This wasn't there in 2.4.23 on which on the original work of H-TCP was > done. Not true, that division by 2 is in the 2.4.23 sources, I just checked. It is there as far back as BK logs go in both the 2.4.x and 2.6.x trees. Perhaps the WEB100 guys patched that test, I bet that's why you don't remember it being in 2.4.23 From davem@davemloft.net Thu Apr 7 11:35:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 11:35:55 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37IZmRB028830 for ; Thu, 7 Apr 2005 11:35:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJbp9-0004LX-00; Thu, 07 Apr 2005 11:33:51 -0700 Date: Thu, 7 Apr 2005 11:33:51 -0700 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Too aggressive cwnd backoff Message-Id: <20050407113351.17f8c094.davem@davemloft.net> In-Reply-To: <20050407164146.GA6479@ev-en.org> References: <20050407164146.GA6479@ev-en.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 809 Lines: 20 On Thu, 7 Apr 2005 19:41:46 +0300 Baruch Even wrote: > However, in tcp_cwnd_down we will not stop reducing the cwnd until we > get to limit which is set to tp->ssthresh/2. > > The provided patch will set limit to tp->ssthresh. This was the original > behaviour in some older version of Linux. As stated in another email, it is still unknown where this "changed" or if it even "changed" at all in the vanilla sources. Could you track this down? I still strongly believe this is some WEB100 change you actually had in your tree, or something like that. I don't disagree with your analysis at all. I just want to find out if it did change in the vanilla sources. Because if it did we can track down a changelog message and perhaps learn something about what the code is the way it is. From jheffner@psc.edu Thu Apr 7 11:37:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 11:38:00 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37Ibtkx029510 for ; Thu, 7 Apr 2005 11:37:55 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j37Ib83U016294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2005 14:37:08 -0400 (EDT) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j37Ib8PU017577; Thu, 7 Apr 2005 14:37:08 -0400 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j37Ib8LK017574; Thu, 7 Apr 2005 14:37:08 -0400 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Thu, 7 Apr 2005 14:37:08 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Baruch Even , shemminger@osdl.org, netdev@oss.sgi.com, werner@almesberger.net Subject: Re: [PATCH] Too aggressive cwnd backoff In-Reply-To: <20050407113121.31b71a94.davem@davemloft.net> Message-ID: References: <20050407164146.GA6479@ev-en.org> <20050407101653.2cc68db1@dxpl.pdx.osdl.net> <42557895.8040004@ev-en.org> <20050407113121.31b71a94.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 749 Lines: 24 On Thu, 7 Apr 2005, David S. Miller wrote: > On Thu, 07 Apr 2005 19:14:45 +0100 > Baruch Even wrote: > > > > Going back to the pre-westwood code in BK, the /2 is still there. > > > > This wasn't there in 2.4.23 on which on the original work of H-TCP was > > done. > > Not true, that division by 2 is in the 2.4.23 sources, I just > checked. > > It is there as far back as BK logs go in both the 2.4.x and 2.6.x > trees. > > Perhaps the WEB100 guys patched that test, I bet that's why you don't > remember it being in 2.4.23 This test looks correct to me. (We never touched it.) It is the bounding parameter specified in rate halving. If you actually get down that far, then rate halving is getting confused, though. -John From shemminger@osdl.org Thu Apr 7 12:02:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 12:03:01 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37J2t2q003513 for ; Thu, 7 Apr 2005 12:02:55 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j37J2ds4027840 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 12:02:40 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j37J2cae016215; Thu, 7 Apr 2005 12:02:38 -0700 Date: Thu, 7 Apr 2005 12:02:38 -0700 From: Stephen Hemminger To: Baruch Even Cc: Andrew Morton , "David S. Miller" , netdev@oss.sgi.com, Injong Rhee Subject: Re: [PATCH 2/5] TCP BIC 1.1 support Message-ID: <20050407120238.47f953fb@dxpl.pdx.osdl.net> In-Reply-To: <423B9415.2010906@ev-en.org> References: <20050318162211.366ca490@dxpl.pdx.osdl.net> <423B9415.2010906@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1531 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: 705 Lines: 16 On Sat, 19 Mar 2005 02:53:09 +0000 Baruch Even wrote: > Stephen Hemminger wrote: > > This patch adds TCP BIC back in as a pluggable TCP congestion mechanism. > > This version is closer to the TCP BIC 1.1 released for Web100. > > The changes from 2.6.11 are: > > * congestion window undo fix > > * delayed ack compensation The delayed ack calculation code in this patch sequence doesn't work quite right. It over estimates the number of delayed acks and this causes BIC to clamp down too hard. I'll look into it later, but just wanted to let people know that it this version of BIC performs worse under delay. The problem is in the calculation of ack_ratio not in the BIC portion. From shemminger@osdl.org Thu Apr 7 12:04:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 12:04:33 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37J4QEE003807 for ; Thu, 7 Apr 2005 12:04:26 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j37J4Is4027954 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 12:04:18 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j37J4H2F016340; Thu, 7 Apr 2005 12:04:18 -0700 Date: Thu, 7 Apr 2005 12:04:17 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen Message-ID: <20050407120417.4297cd14@dxpl.pdx.osdl.net> In-Reply-To: <4252EB9D.9070305@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1532 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: 6122 Lines: 212 On Tue, 05 Apr 2005 21:48:45 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Netem has a private queue for delayed packets, and currently, packets > > in this queue are not accounted for in the qdisc qlen statistics. > > This is a problem if netem is used inside another qdisc doing rate > > control that peeks at the qlen. > > > > This patch changes the statistics to include the packets held but > > not ready to send. > > There is one troublesome spot left, netem_watchdog() decreases q.qlen > when the packet couldn't be enqueued. I don't think it is possible > to make netem useable as leaf-qdisc, it will always have to touch > q.qlen from timer context and classful qdiscs can't deal with this > since they all maintain their own q.qlen counters and expect changes > only in the +-1 range in enqueue/dequeue/requeue/drop. Best thing IMO > would be to refuse to work as anything but root qdisc. > Would this work better.? It just increases qlen by +/- 1 on enqueue, dequeue. It also allows < 1ms delays if there is enough traffic going through. --- linux-2.6.12-rc2/net/sched/sch_netem.c 2005-04-04 09:39:41.000000000 -0700 +++ netem-2.6.12-rc2/net/sched/sch_netem.c 2005-04-06 15:39:16.000000000 -0700 @@ -138,38 +138,78 @@ static long tabledist(unsigned long mu, } /* Put skb in the private delayed queue. */ -static int delay_skb(struct Qdisc *sch, struct sk_buff *skb) +static int netem_delay(struct Qdisc *sch, struct sk_buff *skb) { struct netem_sched_data *q = qdisc_priv(sch); - struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; psched_tdiff_t td; psched_time_t now; PSCHED_GET_TIME(now); td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - PSCHED_TADD2(now, td, cb->time_to_send); /* Always queue at tail to keep packets in order */ if (likely(q->delayed.qlen < q->limit)) { + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + PSCHED_TADD2(now, td, cb->time_to_send); + + pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, + now, cb->time_to_send); + __skb_queue_tail(&q->delayed, skb); - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); - add_timer(&q->timer); - } return NET_XMIT_SUCCESS; } + pr_debug("netem_delay: queue over limit %d\n", q->limit); + sch->qstats.overlimits++; kfree_skb(skb); return NET_XMIT_DROP; } +/* + * Move a packet that is ready to send from the delay holding + * list to the underlying qdisc. + */ +static int netem_run(struct Qdisc *sch) +{ + struct netem_sched_data *q = qdisc_priv(sch); + struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + + skb = skb_peek(&q->delayed); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + return 1; + } + + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) { + sch->q.qlen--; + sch->qstats.drops++; + } + } + + return 0; +} + static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb2; int ret; - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + pr_debug("netem_enqueue skb=%p\n", skb); /* Random packet drop 0 => none, ~0 => all */ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { @@ -184,7 +224,7 @@ static int netem_enqueue(struct sk_buff && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { pr_debug("netem_enqueue: dup %p\n", skb2); - if (delay_skb(sch, skb2)) { + if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -202,7 +242,8 @@ static int netem_enqueue(struct sk_buff ret = q->qdisc->enqueue(skb, q->qdisc); } else { q->counter = 0; - ret = delay_skb(sch, skb); + ret = netem_delay(sch, skb); + netem_run(sch); } if (likely(ret == NET_XMIT_SUCCESS)) { @@ -241,56 +282,35 @@ static unsigned int netem_drop(struct Qd return len; } -/* Dequeue packet. - * Move all packets that are ready to send from the delay holding - * list to the underlying qdisc, then just call dequeue - */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; + int pending; + + pending = netem_run(sch); skb = q->qdisc->dequeue(q->qdisc); - if (skb) + if (skb) { + pr_debug("netem_dequeue: return skb=%p\n", skb); sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + } + else if (pending) { + pr_debug("netem_dequeue: throttling\n"); + sch->flags |= TCQ_F_THROTTLED; + } + return skb; } static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - struct netem_sched_data *q = qdisc_priv(sch); - struct net_device *dev = sch->dev; - struct sk_buff *skb; - psched_time_t now; - pr_debug("netem_watchdog: fired @%lu\n", jiffies); - - spin_lock_bh(&dev->queue_lock); - PSCHED_GET_TIME(now); - - while ((skb = skb_peek(&q->delayed)) != NULL) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_watchdog: skb %p@%lu %ld\n", - skb, jiffies, delay); - - /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - break; - } - __skb_unlink(skb, &q->delayed); - - if (q->qdisc->enqueue(skb, q->qdisc)) { - sch->q.qlen--; - sch->qstats.drops++; - } - } - qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); } static void netem_reset(struct Qdisc *sch) @@ -301,6 +321,7 @@ static void netem_reset(struct Qdisc *sc skb_queue_purge(&q->delayed); sch->q.qlen = 0; + sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); } From baruch@ev-en.org Thu Apr 7 12:18:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 12:18:27 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37JILnM005225 for ; Thu, 7 Apr 2005 12:18:21 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id D8E1C11AA35; Thu, 7 Apr 2005 22:18:15 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 55C6311A606; Thu, 7 Apr 2005 22:18:11 +0300 (IDT) Message-ID: <42558771.1050605@ev-en.org> Date: Thu, 07 Apr 2005 20:18:09 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) 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] Too aggressive cwnd backoff References: <20050407164146.GA6479@ev-en.org> <20050407113351.17f8c094.davem@davemloft.net> In-Reply-To: <20050407113351.17f8c094.davem@davemloft.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1141 Lines: 31 David S. Miller wrote: > On Thu, 7 Apr 2005 19:41:46 +0300 > Baruch Even wrote: > > >>However, in tcp_cwnd_down we will not stop reducing the cwnd until we >>get to limit which is set to tp->ssthresh/2. >> >>The provided patch will set limit to tp->ssthresh. This was the original >>behaviour in some older version of Linux. > > > As stated in another email, it is still unknown where this "changed" > or if it even "changed" at all in the vanilla sources. > > Could you track this down? I still strongly believe this is some > WEB100 change you actually had in your tree, or something like > that. This change seems to be specific to us (Hamilton), I didn't find it as far back as 2.4.12 [1], it wasn't in any 2.6.x kernel and not even in web100 version alpha 2.3.2 which corresponds to kernel 2.4.23. It does appear in the original patches that Doug Leith sent, so the only explanation left is that it's something he did in his tree originally. And for some reason I believed it was reverting an old change in the Linux kernel. Baruch [1] ftp.ie.kernel.org is missing 2.4.11 and ketchup died in my hands. From cimmo@libero.it Thu Apr 7 12:21:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 12:21:17 -0700 (PDT) Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [213.205.33.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37JLCSA009280 for ; Thu, 7 Apr 2005 12:21:12 -0700 Received: from [192.168.1.4] (84.220.99.32) by mail-relay-2.tiscali.it (7.1.021.3) id 420202CD008A62F3 for netdev@oss.sgi.com; Thu, 7 Apr 2005 21:21:02 +0200 Message-ID: <42558820.80006@libero.it> Date: Thu, 07 Apr 2005 21:21:04 +0200 From: Cimmo User-Agent: Mozilla Thunderbird 1.0.2-1 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: forcedeth issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cimmo@libero.it Precedence: bulk X-list: netdev Content-Length: 567 Lines: 31 Hi, sorry for help request, but I really don't know if there is a bug in your forcedeth module or not. I've posted this against Fedora Core 4 test 1, written in mailing list, but no response. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152566 can you help me finding the issue? thanx in advance Marco from my hwconf file: class: OTHER bus: PCI detached: 0 driver: forcedeth desc: "nVidia Corporation CK804 Ethernet Controller" vendorId: 10de deviceId: 0057 subVendorId: 1462 subDeviceId: 7100 pciType: 1 pcidom: 0 pcibus: 0 pcidev: a pcifn: 0 From fubar@us.ibm.com Thu Apr 7 12:59:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 12:59:50 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37JxiaL016281 for ; Thu, 7 Apr 2005 12:59:45 -0700 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.9) with ESMTP id j37Jxc5b476534 for ; Thu, 7 Apr 2005 15:59:38 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j37JxcwX207044 for ; Thu, 7 Apr 2005 13:59:38 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37Jxcqb004753 for ; Thu, 7 Apr 2005 13:59:38 -0600 Received: from death.nxdomain.ibm.com (sig-9-49-129-6.mts.ibm.com [9.49.129.6]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37JxbYT004729; Thu, 7 Apr 2005 13:59:37 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j37JxaNn003633; Thu, 7 Apr 2005 12:59:36 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j37JxZ8g003626; Thu, 7 Apr 2005 12:59:35 -0700 Message-Id: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> To: netdev@oss.sgi.com Cc: davem@davemloft.net Subject: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 12:59:35 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3162 Lines: 83 This patch backs out some of the calls to dev_set_mac_address and replaces them with calls to a similar function that does not call notifier_call_chain. The reason for this is that the rtnetlink event handler and its descendents make GFP_KERNEL memory allocation requests, and the bonding driver makes some of its MAC address change calls from timer context with a lock held (notably the ALB mode). Rearranging the bonding driver to not call this way is a fairly involved change; this patch merely reverts one part of bonding to the way it used to be. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh diff -ur linux-2.6.12-rc2-virgin/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2-setmac/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2-virgin/drivers/net/bonding/bond_alb.c 2005-04-05 22:04:27.000000000 -0700 +++ linux-2.6.12-rc2-setmac/drivers/net/bonding/bond_alb.c 2005-04-07 12:25:02.000000000 -0700 @@ -138,6 +138,23 @@ return hash; } +/* + * Stopgap that doesn't notifier_call_chain like real dev_set_mac_address, + * as rtnetlink event notifier makes sleepable memory allocations, and we + * call this with a lock held. + */ +static int bond_dev_set_mac_address(struct net_device *dev, struct sockaddr *sa) +{ + if (!dev->set_mac_address) + return -EOPNOTSUPP; + if (sa->sa_family != dev->type) + return -EINVAL; + if (!netif_device_present(dev)) + return -ENODEV; + return dev->set_mac_address(dev, sa); +} + + /*********************** tlb specific functions ***************************/ static inline void _lock_tx_hashtbl(struct bonding *bond) @@ -955,7 +972,7 @@ /* each slave will receive packets destined to a different mac */ memcpy(s_addr.sa_data, addr, dev->addr_len); s_addr.sa_family = dev->type; - if (dev_set_mac_address(dev, &s_addr)) { + if (bond_dev_set_mac_address(dev, &s_addr)) { printk(KERN_ERR DRV_NAME ": Error: dev_set_mac_address of dev %s failed! ALB " "mode requires that the base driver support setting " @@ -1210,7 +1227,7 @@ /* save net_device's current hw address */ memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - res = dev_set_mac_address(slave->dev, addr); + res = bond_dev_set_mac_address(slave->dev, addr); /* restore net_device's hw address */ memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); @@ -1230,7 +1247,7 @@ stop_at = slave; bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - dev_set_mac_address(slave->dev, &sa); + bond_dev_set_mac_address(slave->dev, &sa); memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); } Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bond_alb.o Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bond_main.o Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bonding.ko Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bonding.mod.c Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bonding.mod.o Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: bonding.o Only in linux-2.6.12-rc2-setmac/drivers/net/bonding/: built-in.o From werner@almesberger.net Thu Apr 7 13:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 13:29:26 -0700 (PDT) Received: from host.almesberger.net (host.almesberger.net [204.10.140.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37KTFGl018072 for ; Thu, 7 Apr 2005 13:29:20 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.12.8/8.9.3) with ESMTP id j37KQw4u008898; Thu, 7 Apr 2005 13:27:33 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id j37KQf722442; Thu, 7 Apr 2005 17:26:41 -0300 Date: Thu, 7 Apr 2005 17:26:41 -0300 From: Werner Almesberger To: Stephen Hemminger Cc: Baruch Even , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Too aggressive cwnd backoff Message-ID: <20050407172641.K11215@almesberger.net> References: <20050407164146.GA6479@ev-en.org> <20050407101653.2cc68db1@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050407101653.2cc68db1@dxpl.pdx.osdl.net>; from shemminger@osdl.org on Thu, Apr 07, 2005 at 10:16:53AM -0700 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Content-Length: 1396 Lines: 31 Stephen Hemminger wrote: > I think this is a real problem, and was observed by Werner with umlsim. > Don't know when it got introduced because it appears to pre-date the > '04 work in adding Westwood, BIC, Vegas. Perhaps Alexey can shed some > light on this. If this is still the old cwnd quartering bug, then it's very very old. Cheng Jin and I spotted it at the end of 2002 in 2.4.18, but didn't look at earlier versions. (Later, I used this problem to demonstrate how to fix bugs on the fly in umlsim.) You can find the whole discussion in the following two threads: http://thread.gmane.org/gmane.linux.network/2094 http://thread.gmane.org/gmane.linux.network/2223 Note that the fix isn't trivial (or, at least, it wasn't when we looked at it), because just eliminating the /2 would make us too aggressive in another, even weirder case, as I've described in http://article.gmane.org/gmane.linux.network/2221 (which I admit to be somewhat daunting reading). Recently, I noticed that my umlsim-based "hotfix" wouldn't improve things in recent kernels anymore. I thought "cool, someone finally sat down and fixed it", but perhaps that was premature. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From davem@davemloft.net Thu Apr 7 13:33:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 13:33:56 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37KXqG3018780 for ; Thu, 7 Apr 2005 13:33:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJdfL-00053I-00; Thu, 07 Apr 2005 13:31:51 -0700 Date: Thu, 7 Apr 2005 13:31:51 -0700 From: "David S. Miller" To: Jay Vosburgh Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-Id: <20050407133151.5887c946.davem@davemloft.net> In-Reply-To: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> References: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 774 Lines: 18 On Thu, 07 Apr 2005 12:59:35 -0700 Jay Vosburgh wrote: > This patch backs out some of the calls to dev_set_mac_address > and replaces them with calls to a similar function that does not call > notifier_call_chain. > > The reason for this is that the rtnetlink event handler and its > descendents make GFP_KERNEL memory allocation requests, and the bonding > driver makes some of its MAC address change calls from timer context > with a lock held (notably the ALB mode). > > Rearranging the bonding driver to not call this way is a fairly > involved change; this patch merely reverts one part of bonding to the > way it used to be. You can't remove that notifier call, you will break ipv4 ARP, ipv6 neighbour discovery, and bridging if you do that. From davem@davemloft.net Thu Apr 7 13:40:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 13:40:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37Ke0qF019483 for ; Thu, 7 Apr 2005 13:40:00 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJdlC-00056M-00; Thu, 07 Apr 2005 13:37:54 -0700 Date: Thu, 7 Apr 2005 13:37:54 -0700 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Too aggressive cwnd backoff Message-Id: <20050407133754.32d343b2.davem@davemloft.net> In-Reply-To: <42558771.1050605@ev-en.org> References: <20050407164146.GA6479@ev-en.org> <20050407113351.17f8c094.davem@davemloft.net> <42558771.1050605@ev-en.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 636 Lines: 16 On Thu, 07 Apr 2005 20:18:09 +0100 Baruch Even wrote: > This change seems to be specific to us (Hamilton), I didn't find it as > far back as 2.4.12 [1], it wasn't in any 2.6.x kernel and not even in > web100 version alpha 2.3.2 which corresponds to kernel 2.4.23. > > It does appear in the original patches that Doug Leith sent, so the only > explanation left is that it's something he did in his tree originally. > And for some reason I believed it was reverting an old change in the > Linux kernel. That makes sense. And as John Heffner has pointed out, this change is correct and is part of rate-halving. From fubar@us.ibm.com Thu Apr 7 13:55:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 13:55:54 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37KtgnG024910 for ; Thu, 7 Apr 2005 13:55:48 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j37KtaLg597568 for ; Thu, 7 Apr 2005 16:55:36 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j37KtaQ0249278 for ; Thu, 7 Apr 2005 14:55:36 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37KtZ3p032740 for ; Thu, 7 Apr 2005 14:55:35 -0600 Received: from death.nxdomain.ibm.com (sig-9-49-129-6.mts.ibm.com [9.49.129.6]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37KtZwr032724; Thu, 7 Apr 2005 14:55:35 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j37KtXNn003803; Thu, 7 Apr 2005 13:55:33 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j37KtXDf003795; Thu, 7 Apr 2005 13:55:33 -0700 Message-Id: <200504072055.j37KtXDf003795@death.nxdomain.ibm.com> To: "David S. Miller" cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address In-Reply-To: Message from "David S. Miller" of "Thu, 07 Apr 2005 13:31:51 PDT." <20050407133151.5887c946.davem@davemloft.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 13:55:33 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1862 Lines: 57 David S. Miller wrote: >On Thu, 07 Apr 2005 12:59:35 -0700 >Jay Vosburgh wrote: [...] >> Rearranging the bonding driver to not call this way is a fairly >> involved change; this patch merely reverts one part of bonding to the >> way it used to be. > >You can't remove that notifier call, you will break ipv4 ARP, >ipv6 neighbour discovery, and bridging if you do that. Only as they relate to bonding slave device MAC changes in the ALB and TLB modes (the "no notifier" version is only called by MAC changes that occur in those circumstances, all of which are in bond_alb.c). Until a month ago, none of the bonding calls that change MAC addresses issued notifiers, this reverts to that behavior only for ALB and TLB modes. Is that worse than going forward with a potential sleep from a timer context with a lock held? Another alternative would be to change the rtnetlink handler to not use a sleepable memory allocation, e.g., --- linux-2.6.12-rc2-virgin/net/core/rtnetlink.c 2005-03-03 15:53:48.000000000 -0800 +++ linux-2.6.12-rc2-setmac/net/core/rtnetlink.c 2005-04-07 09:30:03.000000000 -0700 @@ -441,7 +441,7 @@ sizeof(struct rtnl_link_ifmap) + sizeof(struct rtnl_link_stats) + 128); - skb = alloc_skb(size, GFP_KERNEL); + skb = alloc_skb(size, GFP_ATOMIC); if (!skb) return; @@ -450,7 +450,7 @@ return; } NETLINK_CB(skb).dst_groups = RTMGRP_LINK; - netlink_broadcast(rtnl, skb, 0, RTMGRP_LINK, GFP_KERNEL); + netlink_broadcast(rtnl, skb, 0, RTMGRP_LINK, GFP_ATOMIC); } static int rtnetlink_done(struct netlink_callback *cb) My presumption is that the above would be unacceptable, if for no other reason than other notifiers could be attached that also make sleepable memory allocations. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From davem@davemloft.net Thu Apr 7 13:59:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:00:01 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37KxvtU025569 for ; Thu, 7 Apr 2005 13:59:57 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJe4a-0005Ef-00; Thu, 07 Apr 2005 13:57:56 -0700 Date: Thu, 7 Apr 2005 13:57:56 -0700 From: "David S. Miller" To: Jay Vosburgh Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-Id: <20050407135756.2df03aaa.davem@davemloft.net> In-Reply-To: <200504072055.j37KtXDf003795@death.nxdomain.ibm.com> References: <20050407133151.5887c946.davem@davemloft.net> <200504072055.j37KtXDf003795@death.nxdomain.ibm.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 494 Lines: 14 On Thu, 07 Apr 2005 13:55:33 -0700 Jay Vosburgh wrote: > Another alternative would be to change the rtnetlink handler to > not use a sleepable memory allocation, e.g., ... > My presumption is that the above would be unacceptable, if for > no other reason than other notifiers could be attached that also make > sleepable memory allocations. You could change it instead to just use gfp_any(). Would that work? The problematic case occurs from softirq not hardirq right? From herbert@gondor.apana.org.au Thu Apr 7 14:26:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:26:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37LQ64u027081 for ; Thu, 7 Apr 2005 14:26:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJeVX-0006V1-00; Fri, 08 Apr 2005 07:25:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJeUq-0001Ij-00; Fri, 08 Apr 2005 07:25:04 +1000 Date: Fri, 8 Apr 2005 07:25:04 +1000 To: Christoph Lameter Cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: <20050407212504.GA4939@gondor.apana.org.au> References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1533 Lines: 41 On Thu, Apr 07, 2005 at 09:00:51AM -0700, Christoph Lameter wrote: > > In an earlier email you said that there was a slight chance that child > entries (typically NOHASH from what I can see in the code) could be on the > gc list. Only child entries with NOHASH unset can be on the GC list. > If its not on the hash table and not on the gc list then how could the > refcnt be > 1 ? Doesnt the refcnt > 1 imply that multiple concurrent > accesses are possible? For NOHASH entries refcnt can be greater than one due to dst_pop. Of course concurrent access is possible. However, the important thing is that only the "owner" of an entry can call dst_destroy. In the case of NOHASH entries, we are the owner. > Also if this is as you say then both types of entries better be > treated in a distinct way for clarity in the code. This also avoids > having a nohash variable: I never said that it is better to treat them differently. I wrote it like this earlier because I still had atomic_dec_and_test. > if ((dst->flags & DST_NOHASH)) { > /* dst not on hash and also not on gc list */ > atomic_dec(&dst->__refcnt); > if (!atomic_read(&dst->refcnt)) > /* We were the only reference kill child */ > goto again; > /* return child to put it on the gc list */ > return dst; > } BTW this patch is missing a barrier. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Apr 7 14:33:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:33:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37LXHii027849 for ; Thu, 7 Apr 2005 14:33:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJecU-0006cS-00; Fri, 08 Apr 2005 07:32:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJec3-0007To-00; Fri, 08 Apr 2005 07:32:31 +1000 Date: Fri, 8 Apr 2005 07:32:31 +1000 To: Dmitry Yusupov Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050407213231.GA28738@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112826385.16753.99.camel@beastie> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 997 Lines: 21 On Wed, Apr 06, 2005 at 03:26:25PM -0700, Dmitry Yusupov wrote: > > Messages from kernel are asynchronous and there are no alloc_skb on "up" > calls. It is "mempooled out" on interface level. (see Open-iSCSI > interface). Messages to kernel requires copy_from_user to newly > allocated skb, here is where we need sk_allocation bit set. Those > messages are synchronous from daemon perspective. If "down" call fails, > we will re-try later or take some other management action. We assuming > that later OOM-killer will free some memory for us and atomic allocation > will succeed eventually. I presume you only need to send one message at a time of a fixed size. Would it better to always have an skb allocated for the socket so that we don't need to allocate at sendmsg time? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From fubar@us.ibm.com Thu Apr 7 14:36:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:36:10 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37La4kq028530 for ; Thu, 7 Apr 2005 14:36:04 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j37LZwua337874 for ; Thu, 7 Apr 2005 17:35:58 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j37LZwQ0222180 for ; Thu, 7 Apr 2005 15:35:58 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37LZwbv016190 for ; Thu, 7 Apr 2005 15:35:58 -0600 Received: from death.nxdomain.ibm.com (sig-9-49-129-6.mts.ibm.com [9.49.129.6]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j37LZvxO016157; Thu, 7 Apr 2005 15:35:57 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j37LZtNn004016; Thu, 7 Apr 2005 14:35:56 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j37LZt4f004009; Thu, 7 Apr 2005 14:35:55 -0700 Message-Id: <200504072135.j37LZt4f004009@death.nxdomain.ibm.com> To: "David S. Miller" cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address In-Reply-To: Message from "David S. Miller" of "Thu, 07 Apr 2005 13:57:56 PDT." <20050407135756.2df03aaa.davem@davemloft.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 14:35:55 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1336 Lines: 45 David S. Miller wrote: >> My presumption is that the above would be unacceptable, if for >> no other reason than other notifiers could be attached that also make >> sleepable memory allocations. > >You could change it instead to just use gfp_any(). > >Would that work? The problematic case occurs from softirq >not hardirq right? Yes, that works, and yes, the troublesome calls come from softirq (timers). In that case, the rtnetlink patch would be: Signed-off-by: Jay Vosburgh --- linux-2.6.12-rc2-virgin/net/core/rtnetlink.c 2005-03-03 15:53:48.000000000 -0800 +++ linux-2.6.12-rc2-setmac/net/core/rtnetlink.c 2005-04-07 14:05:29.000000000 -0700 @@ -441,7 +441,7 @@ sizeof(struct rtnl_link_ifmap) + sizeof(struct rtnl_link_stats) + 128); - skb = alloc_skb(size, GFP_KERNEL); + skb = alloc_skb(size, gfp_any()); if (!skb) return; @@ -450,7 +450,7 @@ return; } NETLINK_CB(skb).dst_groups = RTMGRP_LINK; - netlink_broadcast(rtnl, skb, 0, RTMGRP_LINK, GFP_KERNEL); + netlink_broadcast(rtnl, skb, 0, RTMGRP_LINK, gfp_any()); } static int rtnetlink_done(struct netlink_callback *cb) This doesn't do anything about other event handlers that might also have potential sleeps. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From tgraf@suug.ch Thu Apr 7 14:38:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:38:28 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37LcLia029138 for ; Thu, 7 Apr 2005 14:38:21 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3B95C8D; Thu, 7 Apr 2005 23:37:56 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 15D121C0EA; Thu, 7 Apr 2005 23:38:39 +0200 (CEST) Date: Thu, 7 Apr 2005 23:38:38 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules Message-ID: <20050407213838.GW26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1653 Lines: 47 Dave, I would appreciate if this could go in before 2.6.12, it would allow the upcomming netconfig pre release to run on 2.6.12 out of the box. Please do a bk pull bk://kernel.bkbits.net/tgraf/net-2.6-trunk This will update the following files: net/core/rtnetlink.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) through these ChangeSets: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/07 17:41:18+02:00 tgraf@suug.ch # [RTNETLINK]: Protocol family wildcard dumping for routing rules # # Be kind to userspace and don't force them to hardcode protocol # families just to have it changed again once we support routing # rules for more than one protocol family. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/core/rtnetlink.c # 2005/04/07 17:41:07+02:00 tgraf@suug.ch +2 -1 # [RTNETLINK]: Protocol family wildcard dumping for routing rules # diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 +++ b/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 @@ -647,7 +647,8 @@ [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all } }; static int rtnetlink_event(struct notifier_block *this, unsigned long event, void *ptr) From herbert@gondor.apana.org.au Thu Apr 7 14:43:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:43:32 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37LhMdA029821 for ; Thu, 7 Apr 2005 14:43:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJem3-0006hD-00; Fri, 08 Apr 2005 07:42:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJelW-0007Vg-00; Fri, 08 Apr 2005 07:42:18 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [PATCH] Too aggressive cwnd backoff Cc: baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050407113351.17f8c094.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 08 Apr 2005 07:42:18 +1000 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 722 Lines: 21 David S. Miller wrote: > > I don't disagree with your analysis at all. I just want to find out > if it did change in the vanilla sources. Because if it did we can > track down a changelog message and perhaps learn something about what > the code is the way it is. Looking at the vger tree this was introduced back in 2000: # ChangeSet # 2000/08/09 11:59:05-00:00 davem@vger.kernel.org # Many files: # Merge in ANKs net-000808-23:20 patch. # Linus better eat this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Thu Apr 7 14:47:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 14:47:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37LlqHH030489 for ; Thu, 7 Apr 2005 14:47:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJeoF-0005Vp-00; Thu, 07 Apr 2005 14:45:07 -0700 Date: Thu, 7 Apr 2005 14:45:07 -0700 From: "David S. Miller" To: Herbert Xu Cc: baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Too aggressive cwnd backoff Message-Id: <20050407144507.3695f373.davem@davemloft.net> In-Reply-To: References: <20050407113351.17f8c094.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 382 Lines: 13 On Fri, 08 Apr 2005 07:42:18 +1000 Herbert Xu wrote: > Looking at the vger tree this was introduced back in 2000: > > # ChangeSet > # 2000/08/09 11:59:05-00:00 davem@vger.kernel.org > # Many files: > # Merge in ANKs net-000808-23:20 patch. > # Linus better eat this. Heh, wish I was better at changelog messages back in the CVS days :-) From herbert@gondor.apana.org.au Thu Apr 7 15:10:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 15:10:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37MAEja031612 for ; Thu, 7 Apr 2005 15:10:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJfBy-0006rI-00; Fri, 08 Apr 2005 08:09:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJfBR-0007Ym-00; Fri, 08 Apr 2005 08:09:05 +1000 From: Herbert Xu To: tgraf@suug.ch (Thomas Graf) Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050407213838.GW26731@postel.suug.ch> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 08 Apr 2005 08:09:05 +1000 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1035 Lines: 23 Thomas Graf wrote: > > diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c > --- a/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 > +++ b/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 > @@ -647,7 +647,8 @@ > [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, > [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, > [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, > - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } > + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, > + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all } > }; Just a trivial comment. How about adding a comma at the end of the last entry so that the next patch won't have to touch it? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From christoph@graphe.net Thu Apr 7 15:31:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 15:31:13 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37MV84s032682 for ; Thu, 7 Apr 2005 15:31:08 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJfW9-00017y-1C; Thu, 07 Apr 2005 15:30:30 -0700 Date: Thu, 7 Apr 2005 15:30:28 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050407212504.GA4939@gondor.apana.org.au> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 918 Lines: 22 On Fri, 8 Apr 2005, Herbert Xu wrote: > Only child entries with NOHASH unset can be on the GC list. > > > If its not on the hash table and not on the gc list then how could the > > refcnt be > 1 ? Doesnt the refcnt > 1 imply that multiple concurrent > > accesses are possible? > > For NOHASH entries refcnt can be greater than one due to dst_pop. > Of course concurrent access is possible. However, the important > thing is that only the "owner" of an entry can call dst_destroy. > > In the case of NOHASH entries, we are the owner. So in case f.e. the refcnt was 2 for a child NOHASH entry, then we decrement the refcnt for the child but do not free it. However after dst_destroy the parent is gone and presumably some skb->dst are still pointing to the dst entry (or is there something else accounting for the remaining __refcnt)? What happens to the child dst entry? Will the system simply never deallocate it? From tgraf@suug.ch Thu Apr 7 15:38:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 15:38:36 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37McSND000933 for ; Thu, 7 Apr 2005 15:38:29 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E106E8D; Fri, 8 Apr 2005 00:38:05 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9E1701C0EA; Fri, 8 Apr 2005 00:38:47 +0200 (CEST) Date: Fri, 8 Apr 2005 00:38:47 +0200 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules Message-ID: <20050407223847.GX26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2408 Lines: 52 * Herbert Xu 2005-04-08 08:09 > Thomas Graf wrote: > > > > diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c > > --- a/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 > > +++ b/net/core/rtnetlink.c 2005-04-07 23:13:33 +02:00 > > @@ -647,7 +647,8 @@ > > [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, > > [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, > > [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, > > - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } > > + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, > > + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all } > > }; > > Just a trivial comment. How about adding a comma at the end of the last > entry so that the next patch won't have to touch it? Sure, bk fix'ed and new patch attached. However, I haven't read all the recent happenings around bk and somewhat missed rc2. I just noticed the freeze so not sure if this still makes sense. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/08 00:24:50+02:00 tgraf@suug.ch # [RTNETLINK]: Protocol family wildcard dumping for routing rules # # Be kind to userspace and don't force them to hardcode protocol # families just to have it changed again once we support routing # rules for more than one protocol family. # # Signed-off-by: Thomas Graf # Signed-off-by: David S. Miller # # net/core/rtnetlink.c # 2005/04/08 00:24:40+02:00 tgraf@suug.ch +2 -1 # [RTNETLINK]: Protocol family wildcard dumping for routing rules # diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c 2005-04-08 00:35:37 +02:00 +++ b/net/core/rtnetlink.c 2005-04-08 00:35:37 +02:00 @@ -647,7 +647,8 @@ [RTM_GETROUTE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, [RTM_NEWNEIGH - RTM_BASE] = { .doit = neigh_add }, [RTM_DELNEIGH - RTM_BASE] = { .doit = neigh_delete }, - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, }; static int rtnetlink_event(struct notifier_block *this, unsigned long event, void *ptr) From herbert@gondor.apana.org.au Thu Apr 7 16:08:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:08:37 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37N8SEn002388 for ; Thu, 7 Apr 2005 16:08:29 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJg6Y-0007FA-00; Fri, 08 Apr 2005 09:08:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJg66-0007dS-00; Fri, 08 Apr 2005 09:07:38 +1000 Date: Fri, 8 Apr 2005 09:07:38 +1000 To: Christoph Lameter Cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: <20050407230738.GA29330@gondor.apana.org.au> References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 870 Lines: 22 On Thu, Apr 07, 2005 at 03:30:28PM -0700, Christoph Lameter wrote: > > So in case f.e. the refcnt was 2 for a child NOHASH entry, then we > decrement the refcnt for the child but do not free it. However after > dst_destroy the parent is gone and presumably some skb->dst are still > pointing to the dst entry (or is there something else accounting for the > remaining __refcnt)? > > What happens to the child dst entry? Will the system simply never > deallocate it? If the refcnt is non-zero after the atomic_dec and the entry is NOHASH, we return it and the caller will add it to the GC list. See the relevant section in dst_run_gc and dst_free. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Thu Apr 7 16:13:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:13:50 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NDkoA003168 for ; Thu, 7 Apr 2005 16:13:46 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJgC1-0002pK-Q8 for netdev@oss.sgi.com; Thu, 07 Apr 2005 19:13:45 -0400 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 1DJgBx-0001Kb-IG; Thu, 07 Apr 2005 19:13:41 -0400 Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , "David S. Miller" , netdev In-Reply-To: <20050407223847.GX26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> <20050407223847.GX26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112915616.1089.27.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 19:13:36 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1551 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: 551 Lines: 18 On Thu, 2005-04-07 at 18:38, Thomas Graf wrote: > - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } > + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, > + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, > }; > Shouldnt this just work (without this change) if you have CONFIG_IP_MULTIPLE_TABLES? If you want to be funky and have some default dumper always, why not make the change to set dumpit to rtnetlink_dump_all in the code when dumpit is found to be NULL as a last resort? cheers, jamal From radheka.godse@intel.com Thu Apr 7 16:16:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:16:10 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NG6SB003761 for ; Thu, 7 Apr 2005 16:16:06 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NFqwZ022429; Thu, 7 Apr 2005 23:15:52 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NFqRZ024716; Thu, 7 Apr 2005 23:15:52 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NFqSL028838; Thu, 7 Apr 2005 16:15:52 -0700 Date: Fri, 8 Apr 2005 16:15:24 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 0/17] bonding: sysfs interface... Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 2240 Lines: 55 This patch set implements the sysfs interface for bonding and has a couple bug fixes. We have done a full test pass and consider these patches ready for inclusion upstream. We have submitted them to bonding-devel several times and have incorporated feedback and fixes all known issues. The interface is pretty simple. Here are some notes on how it could be used: The file /sys/class/net/bonding_masters contains the names of all the active bonds. To add or remove bonds, write a whitespace-delimited list of interface names to this file. For example: echo "bond1 bond2 bond3" > /sys/class/net/bonding_masters will create three bonds with the given names. If any other bonds exist, they will be deleted. echo "bond0 bond2 bond3" > /sys/class/net/bonding_masters would then create bond0 and remove bond1. For each bond, there is a directory /sys/class/net//bonding. In this directory are a number of files which control the bond. The names of these files match the existing module parameters and do the same things. The slaves file contains a whitespace-delimited list of interface names, which are slaves to the bond. This file behaves much the same as the "bonding_masters" file; just write a list of your desired interfaces to this file. Likewise, the arp_targets file contains a whitespace-delimited list of IP addresses and should be written to in a similar fashion. The other files contain single values(numeric and/or mnemonic), except for stat, which duplicates the slave information in the proc file. Some caveats: - slaves can only be assigned when the interface is up - mode can only be changed when the interface is down Warnings and status messages will be logged and can be viewed with dmesg. Example: modprobe bonding echo "bond0 bond1" > /sys/class/net/bonding_masters echo "6" > /sys/class/net/bond0/bonding/mode echo "1000" > /sys/class/net/bond0/bonding/miimon ifconfig bond0 192.168.0.1 echo "eth0 eth1" > /sys/class/net/bond0/bonding/slaves # bond0 is now ready to use echo "1" > /sys/class/net/bond1/bonding/mode # ... and so on for bond1 These patches apply cleanly to kernel 2.6.12-rc2. - Mitch Williams - Radheka Godse From radheka.godse@intel.com Thu Apr 7 16:21:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:21:47 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NLge0008459 for ; Thu, 7 Apr 2005 16:21:42 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NLUQe003773; Thu, 7 Apr 2005 23:21:30 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NLURZ029746; Thu, 7 Apr 2005 23:21:30 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NLTSL029150; Thu, 7 Apr 2005 16:21:30 -0700 Date: Fri, 8 Apr 2005 16:21:01 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 1/17] bonding: make some functions not static Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 5366 Lines: 134 This patch prepares for adding sysfs functionality to bonding by making some functions in bond_main non-static and adding protos into the header. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -247,6 +247,17 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr); int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); +void bond_deinit(struct net_device *bond_dev); +int bond_release(struct net_device *bond_dev, struct net_device *slave_dev); +int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev); +void bond_mii_monitor(struct net_device *bond_dev); +void bond_loadbalance_arp_mon(struct net_device *bond_dev); +void bond_activebackup_arp_mon(struct net_device *bond_dev); +void bond_set_mode_ops(struct net_device *bond_dev, int mode); +int bond_parse_parm(char *mode_arg, struct bond_parm_tbl *tbl); +const char *bond_mode_name(int mode); +void bond_select_active_slave(struct bonding *bond); +void bond_change_active_slave(struct bonding *bond, struct slave *new_active); #endif /* _LINUX_BONDING_H */ diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -610,11 +610,10 @@ /*-------------------------- Forward declarations ---------------------------*/ -static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); /*---------------------------- General routines -----------------------------*/ -static const char *bond_mode_name(int mode) +const char *bond_mode_name(int mode) { switch (mode) { case BOND_MODE_ROUNDROBIN : @@ -1428,7 +1427,7 @@ * * Warning: Caller must hold curr_slave_lock for writing. */ -static void bond_change_active_slave(struct bonding *bond, struct slave *new_active) +void bond_change_active_slave(struct bonding *bond, struct slave *new_active) { struct slave *old_active = bond->curr_active_slave; @@ -1501,7 +1500,7 @@ * * Warning: Caller must hold curr_slave_lock for writing. */ -static void bond_select_active_slave(struct bonding *bond) +void bond_select_active_slave(struct bonding *bond) { struct slave *best_slave; @@ -1569,7 +1568,7 @@ /*---------------------------------- IOCTL ----------------------------------*/ -static int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev) +int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev) { dprintk("bond_dev=%p\n", bond_dev); dprintk("slave_dev=%p\n", slave_dev); @@ -2004,7 +2003,7 @@ * for Bonded connections: * The first up interface should be left on and all others downed. */ -static int bond_release(struct net_device *bond_dev, struct net_device *slave_dev) +int bond_release(struct net_device *bond_dev, struct net_device *slave_dev) { struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; @@ -2453,7 +2452,7 @@ /*-------------------------------- Monitoring -------------------------------*/ /* this function is called regularly to monitor each slave's link. */ -static void bond_mii_monitor(struct net_device *bond_dev) +void bond_mii_monitor(struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; @@ -2713,7 +2712,7 @@ * arp is transmitted to generate traffic. see activebackup_arp_monitor for * arp monitoring in active backup mode. */ -static void bond_loadbalance_arp_mon(struct net_device *bond_dev) +void bond_loadbalance_arp_mon(struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; @@ -2851,7 +2850,7 @@ * may have received. * see loadbalance_arp_monitor for arp monitoring in load balancing mode */ -static void bond_activebackup_arp_mon(struct net_device *bond_dev) +void bond_activebackup_arp_mon(struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; struct slave *slave; @@ -4208,7 +4207,7 @@ /* * set bond mode specific net device operations */ -static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode) +void bond_set_mode_ops(struct net_device *bond_dev, int mode) { switch (mode) { case BOND_MODE_ROUNDROBIN: @@ -4317,7 +4316,7 @@ /* De-initialize device specific data. * Caller must hold rtnl_lock. */ -static inline void bond_deinit(struct net_device *bond_dev) +void bond_deinit(struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; @@ -4353,7 +4352,7 @@ * Convert string input module parms. Accept either the * number of the mode or its string name. */ -static inline int bond_parse_parm(char *mode_arg, struct bond_parm_tbl *tbl) +int bond_parse_parm(char *mode_arg, struct bond_parm_tbl *tbl) { int i; From tgraf@suug.ch Thu Apr 7 16:24:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:24:15 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NO71Z009056 for ; Thu, 7 Apr 2005 16:24:10 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C93A98D; Fri, 8 Apr 2005 01:23:44 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 0D8001C0EA; Fri, 8 Apr 2005 01:24:28 +0200 (CEST) Date: Fri, 8 Apr 2005 01:24:27 +0200 From: Thomas Graf To: jamal Cc: Herbert Xu , "David S. Miller" , netdev Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules Message-ID: <20050407232427.GY26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> <20050407223847.GX26731@postel.suug.ch> <1112915616.1089.27.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112915616.1089.27.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1174 Lines: 30 * jamal <1112915616.1089.27.camel@jzny.localdomain> 2005-04-07 19:13 > On Thu, 2005-04-07 at 18:38, Thomas Graf wrote: > > - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } > > + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, > > + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, > > }; > > > > Shouldnt this just work (without this change) if you have > CONFIG_IP_MULTIPLE_TABLES? Not sure what you mean, it doesn't even get into the routing code but already fails in rtnetlink_rcv_msg when it doesn't find a dumpit implementation for family == AF_UNSPEC. > If you want to be funky and have some default dumper always, > why not make the change to set dumpit to rtnetlink_dump_all in the code > when dumpit is found to be NULL as a last resort? That is exactly what happens, it will first look up the address family dumpit and if none exist falls back to the rtnetlink_dump_all introduced above. if (link->dumpit == NULL) link = &(rtnetlink_links[PF_UNSPEC][type]); if (link->dumpit == NULL) goto err_inval; /* <-- we used to fail here for PF_UNSPEC */ if ((*errp = netlink_dump_start(rtnl, skb, nlh, ... From radheka.godse@intel.com Thu Apr 7 16:24:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:24:16 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NO8L6009052 for ; Thu, 7 Apr 2005 16:24:10 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NNvQe004821; Thu, 7 Apr 2005 23:23:57 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NNvju010260; Thu, 7 Apr 2005 23:23:57 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NNvSL029229; Thu, 7 Apr 2005 16:23:57 -0700 Date: Fri, 8 Apr 2005 16:23:29 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 2/17] bonding: split bond creation into new function Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 4930 Lines: 166 This patch moves the work of creating a new bond into a separate function, instead of being inline in bonding_init. This function is non-static and proto is added to the header, for use by the sysfs interface. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -247,6 +247,7 @@ struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr); int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); +int bond_create(char *name, struct bond_params *params, struct bonding **newbond); void bond_deinit(struct net_device *bond_dev); int bond_release(struct net_device *bond_dev, struct net_device *slave_dev); int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev); diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -539,6 +539,7 @@ static char *lacp_rate = NULL; static int arp_interval = BOND_LINK_ARP_INTERV; static char *arp_ip_target[BOND_MAX_ARP_TARGETS] = { NULL, }; +struct bond_params bonding_defaults; module_param(max_bonds, int, 0); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -4243,12 +4244,10 @@ * Does not allocate but creates a /proc entry. * Allowed to fail. */ -static int __init bond_init(struct net_device *bond_dev, struct bond_params *params) +static int bond_init(struct net_device *bond_dev, struct bond_params *params) { - struct bonding *bond = bond_dev->priv; - - dprintk("Begin bond_init for %s\n", bond_dev->name); - + struct bonding *bond; + bond = bond_dev->priv; /* initialize rwlocks */ rwlock_init(&bond->lock); rwlock_init(&bond->curr_slave_lock); @@ -4612,20 +4723,70 @@ return 0; } +/* Create a new bond based on the specified name and bonding parameters. + * Caller must NOT hold rtnl_lock; we need to release it here before we + * set up our sysfs entries. + */ +int bond_create(char *name, struct bond_params *params, struct bonding **newbond) +{ + struct net_device *bond_dev; + int res; + + rtnl_lock(); + bond_dev = alloc_netdev(sizeof(struct bonding), name, ether_setup); + if (!bond_dev) { + printk(KERN_ERR DRV_NAME + ": %s: eek! can't alloc netdev!\n", + name); + res = -ENOMEM; + goto out_rtnl; + } + + /* bond_init() must be called after dev_alloc_name() (for the + * /proc files), but before register_netdevice(), because we + * need to set function pointers. + */ + + res = bond_init(bond_dev, params); + if (res < 0) { + goto out_netdev; + } + + SET_MODULE_OWNER(bond_dev); + + res = register_netdevice(bond_dev); + if (res < 0) { + goto out_bond; + } + if (newbond) + *newbond = bond_dev->priv; + + rtnl_unlock(); /* allows sysfs registration of net device */ + res = bond_create_sysfs_entry(bond_dev->priv); + goto done; +out_bond: + bond_deinit(bond_dev); +out_netdev: + free_netdev(bond_dev); +out_rtnl: + rtnl_unlock(); +done: + return res; +} + static int __init bonding_init(void) { - struct bond_params params; int i; int res; + char new_bond_name[8]; /* Enough room for 999 bonds at init. */ printk(KERN_INFO "%s", version); - res = bond_check_params(¶ms); + res = bond_check_params(&bonding_defaults); if (res) { - return res; + goto out; } - rtnl_lock(); #ifdef CONFIG_PROC_FS bond_create_proc_dir(); @@ -4632,41 +4723,12 @@ #endif for (i = 0; i < max_bonds; i++) { - struct net_device *bond_dev; - - bond_dev = alloc_netdev(sizeof(struct bonding), "", ether_setup); - if (!bond_dev) { - res = -ENOMEM; - goto out_err; - } - - res = dev_alloc_name(bond_dev, "bond%d"); - if (res < 0) { - free_netdev(bond_dev); - goto out_err; - } - - /* bond_init() must be called after dev_alloc_name() (for the - * /proc files), but before register_netdevice(), because we - * need to set function pointers. - */ - res = bond_init(bond_dev, ¶ms); - if (res < 0) { - free_netdev(bond_dev); - goto out_err; - } - - SET_MODULE_OWNER(bond_dev); - - res = register_netdevice(bond_dev); - if (res < 0) { - bond_deinit(bond_dev); - free_netdev(bond_dev); - goto out_err; - } + sprintf(new_bond_name, "bond%d",i); + res = bond_create(new_bond_name,&bonding_defaults, NULL); + if (res) + goto err; } - rtnl_unlock(); register_netdevice_notifier(&bond_netdev_notifier); return 0; From radheka.godse@intel.com Thu Apr 7 16:26:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:26:13 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NQ8l9010175 for ; Thu, 7 Apr 2005 16:26:08 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NPuVa007625; Thu, 7 Apr 2005 23:25:56 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NPuju011752; Thu, 7 Apr 2005 23:25:56 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NPtSL029345; Thu, 7 Apr 2005 16:25:55 -0700 Date: Fri, 8 Apr 2005 16:25:27 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 3/17] bonding: export some structs to bonding.h Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 1772 Lines: 56 This patch exposes some data structures for use by the sysfs interface. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -147,6 +147,11 @@ u32 arp_targets[BOND_MAX_ARP_TARGETS]; }; +struct bond_parm_tbl { + char *modename; + int mode; +}; + struct vlan_entry { struct list_head vlan_list; unsigned short vlan_id; diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -567,7 +567,7 @@ static const char *version = DRV_DESCRIPTION ": v" DRV_VERSION " (" DRV_RELDATE ")\n"; -static LIST_HEAD(bond_dev_list); +LIST_HEAD(bond_dev_list); #ifdef CONFIG_PROC_FS static struct proc_dir_entry *bond_proc_dir = NULL; @@ -587,18 +587,13 @@ * another ABI version. */ -struct bond_parm_tbl { - char *modename; - int mode; -}; - -static struct bond_parm_tbl bond_lacp_tbl[] = { +struct bond_parm_tbl bond_lacp_tbl[] = { { "slow", AD_LACP_SLOW}, { "fast", AD_LACP_FAST}, { NULL, -1}, }; -static struct bond_parm_tbl bond_mode_tbl[] = { +struct bond_parm_tbl bond_mode_tbl[] = { { "balance-rr", BOND_MODE_ROUNDROBIN}, { "active-backup", BOND_MODE_ACTIVEBACKUP}, { "balance-xor", BOND_MODE_XOR}, From radheka.godse@intel.com Thu Apr 7 16:29:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:29:56 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NTqtK010846 for ; Thu, 7 Apr 2005 16:29:52 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NTf6x006747; Thu, 7 Apr 2005 23:29:41 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NTfRZ003904; Thu, 7 Apr 2005 23:29:41 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NTfSL029572; Thu, 7 Apr 2005 16:29:41 -0700 Date: Fri, 8 Apr 2005 16:29:13 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 4/17] bonding: return pointer to slave from enslave Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 2415 Lines: 52 This patch changes the bond_enslave function so that it (optionally) returns a pointer tothe slave struct for a new slave. This functionality is not used by the existing ioctl interface, but will be used by the sysfs interface. This function is also made non-static and a proto is placed in the header. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -254,6 +254,7 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); int bond_create(char *name, struct bond_params *params, struct bonding **newbond); void bond_deinit(struct net_device *bond_dev); +int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, struct slave **vassal); int bond_release(struct net_device *bond_dev, struct net_device *slave_dev); int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev); void bond_mii_monitor(struct net_device *bond_dev); diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -1574,7 +1574,7 @@ } /* enslave device to bond device */ -static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev) +int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, struct slave **vassal) { struct bonding *bond = bond_dev->priv; struct slave *new_slave = NULL; @@ -1965,6 +1965,8 @@ new_slave->link != BOND_LINK_DOWN ? "n up" : " down"); /* enslave is successful */ + if (vassal) + *vassal=new_slave; return 0; /* Undo stages on error */ @@ -3771,7 +3773,7 @@ switch (cmd) { case BOND_ENSLAVE_OLD: case SIOCBONDENSLAVE: - res = bond_enslave(bond_dev, slave_dev); + res = bond_enslave(bond_dev, slave_dev, NULL); break; case BOND_RELEASE_OLD: case SIOCBONDRELEASE: From radheka.godse@intel.com Thu Apr 7 16:31:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:31:24 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NVIJH011272 for ; Thu, 7 Apr 2005 16:31:18 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NV6wZ029813; Thu, 7 Apr 2005 23:31:06 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NV6RZ005246; Thu, 7 Apr 2005 23:31:06 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NV6SL029699; Thu, 7 Apr 2005 16:31:06 -0700 Date: Fri, 8 Apr 2005 16:30:38 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 5/17] bonding: reset RLB flag during ALB init Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 761 Lines: 22 s patch makes the ALB init function explicitly clear the RLB flag if RLB is not used. This is required by the sysfs interfaces, which allows the user to change mode without destroying the bond. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c 2005-04-07 13:57:29.000000000 -0700 @@ -1256,7 +1256,10 @@ tlb_deinitialize(bond); return res; } + } else { + bond->alb_info.rlb_enabled = 0; } + return 0; } From radheka.godse@intel.com Thu Apr 7 16:34:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:34:59 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NYtnN012063 for ; Thu, 7 Apr 2005 16:34:55 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NYiwZ031366; Thu, 7 Apr 2005 23:34:44 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NYiRZ007795; Thu, 7 Apr 2005 23:34:44 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NYiSL029870; Thu, 7 Apr 2005 16:34:44 -0700 Date: Fri, 8 Apr 2005 16:34:15 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 6/17] bonding: ALB init kmalloc inside spinlock bugfix Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 2033 Lines: 64 This patch corrects bug in ALB init where kmalloc called inside a held lock causes stacdump in debug mode Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c 2005-04-07 13:57:29.000000000 -0700 @@ -198,20 +198,21 @@ { struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); int size = TLB_HASH_TABLE_SIZE * sizeof(struct tlb_client_info); + struct tlb_client_info *new_hashtbl; int i; spin_lock_init(&(bond_info->tx_hashtbl_lock)); - _lock_tx_hashtbl(bond); - - bond_info->tx_hashtbl = kmalloc(size, GFP_KERNEL); - if (!bond_info->tx_hashtbl) { + new_hashtbl = kmalloc(size, GFP_KERNEL); + if (!new_hashtbl) { printk(KERN_ERR DRV_NAME ": Error: %s: Failed to allocate TLB hash table\n", bond->dev->name); - _unlock_tx_hashtbl(bond); return -1; } + _lock_tx_hashtbl(bond); + + bond_info->tx_hashtbl = new_hashtbl; memset(bond_info->tx_hashtbl, 0, size); @@ -798,21 +801,22 @@ { struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); struct packet_type *pk_type = &(BOND_ALB_INFO(bond).rlb_pkt_type); + struct rlb_client_info *new_hashtbl; int size = RLB_HASH_TABLE_SIZE * sizeof(struct rlb_client_info); int i; spin_lock_init(&(bond_info->rx_hashtbl_lock)); - _lock_rx_hashtbl(bond); - - bond_info->rx_hashtbl = kmalloc(size, GFP_KERNEL); - if (!bond_info->rx_hashtbl) { + new_hashtbl = kmalloc(size, GFP_KERNEL); + if (!new_hashtbl) { printk(KERN_ERR DRV_NAME ": Error: %s: Failed to allocate RLB hash table\n", bond->dev->name); - _unlock_rx_hashtbl(bond); return -1; } + _lock_rx_hashtbl(bond); + + bond_info->rx_hashtbl = new_hashtbl; bond_info->rx_hashtbl_head = RLB_NULL_INDEX; From dmitry_yus@yahoo.com Thu Apr 7 16:36:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:36:48 -0700 (PDT) Received: from smtp104.mail.sc5.yahoo.com (smtp104.mail.sc5.yahoo.com [66.163.169.223]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j37NahLK012658 for ; Thu, 7 Apr 2005 16:36:43 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp104.mail.sc5.yahoo.com with SMTP; 7 Apr 2005 23:36:43 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050407213231.GA28738@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> Content-Type: text/plain Date: Thu, 07 Apr 2005 16:36:41 -0700 Message-Id: <1112917001.3893.77.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1020 Lines: 20 On Fri, 2005-04-08 at 07:32 +1000, Herbert Xu wrote: > On Wed, Apr 06, 2005 at 03:26:25PM -0700, Dmitry Yusupov wrote: > > > > Messages from kernel are asynchronous and there are no alloc_skb on "up" > > calls. It is "mempooled out" on interface level. (see Open-iSCSI > > interface). Messages to kernel requires copy_from_user to newly > > allocated skb, here is where we need sk_allocation bit set. Those > > messages are synchronous from daemon perspective. If "down" call fails, > > we will re-try later or take some other management action. We assuming > > that later OOM-killer will free some memory for us and atomic allocation > > will succeed eventually. > > I presume you only need to send one message at a time of a fixed size. > Would it better to always have an skb allocated for the socket so that > we don't need to allocate at sendmsg time? This actually even better since we will guarantee "down" call delivery. My only concern is that it is not very generic. Do you know clean way to implement it? From radheka.godse@intel.com Thu Apr 7 16:55:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:55:37 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NtV0i014052 for ; Thu, 7 Apr 2005 16:55:31 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NtJwZ009627; Thu, 7 Apr 2005 23:55:19 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NtJRZ024281; Thu, 7 Apr 2005 23:55:19 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NtJSL031417; Thu, 7 Apr 2005 16:55:19 -0700 Date: Fri, 8 Apr 2005 16:54:51 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 7/17] bonding: per bond my_ip Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 3095 Lines: 89 This patch makes "my_ip" a per bond variable instead of a global Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -208,6 +208,7 @@ struct bond_params params; struct list_head vlan_list; struct vlan_group *vlgrp; + u32 my_ip; }; /** diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -575,7 +575,6 @@ 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; static int lacp_fast = 0; static int app_abi_ver = 0; @@ -2698,7 +2698,7 @@ 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, + bond->my_ip, NULL, slave->dev->dev_addr, NULL); } } @@ -2778,7 +2777,7 @@ */ if (((jiffies - slave->dev->trans_start) >= (2*delta_in_ticks)) || (((jiffies - slave->dev->last_rx) >= (2*delta_in_ticks)) && - my_ip)) { + bond->my_ip)) { slave->link = BOND_LINK_DOWN; slave->state = BOND_STATE_BACKUP; @@ -2917,7 +2916,7 @@ if ((slave != bond->curr_active_slave) && (!bond->current_arp_slave) && (((jiffies - slave->dev->last_rx) >= 3*delta_in_ticks) && - my_ip)) { + bond->my_ip)) { /* a backup slave has gone down; three times * the delta allows the current slave to be * taken out before the backup slave. @@ -2964,7 +2963,7 @@ */ if ((((jiffies - slave->dev->trans_start) >= (2*delta_in_ticks)) || (((jiffies - slave->dev->last_rx) >= (2*delta_in_ticks)) && - my_ip)) && + bond->my_ip)) && ((jiffies - slave->jiffies) >= 2*delta_in_ticks)) { slave->link = BOND_LINK_DOWN; @@ -3016,7 +3015,7 @@ /* the current slave must tx an arp to ensure backup slaves * rx traffic */ - if (slave && my_ip) { + if (slave && bond->my_ip) { bond_arp_send_all(bond, slave); } } @@ -4059,13 +4058,13 @@ /* if we are sending arp packets, try to at least identify our own ip address */ - if (bond->params.arp_interval && !my_ip && + if (bond->params.arp_interval && !bond->my_ip && (skb->protocol == __constant_htons(ETH_P_ARP))) { char *the_ip = (char *)skb->data + sizeof(struct ethhdr) + sizeof(struct arphdr) + ETH_ALEN; - memcpy(&my_ip, the_ip, 4); + memcpy(&bond->my_ip, the_ip, 4); } read_lock(&bond->lock); From radheka.godse@intel.com Thu Apr 7 16:57:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:57:25 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NvGin014445 for ; Thu, 7 Apr 2005 16:57:16 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37Nv4wZ010459; Thu, 7 Apr 2005 23:57:04 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37Nv3ju000395; Thu, 7 Apr 2005 23:57:03 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37Nv3SL031496; Thu, 7 Apr 2005 16:57:03 -0700 Date: Fri, 8 Apr 2005 16:56:35 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r8/17] bonding: SYSFS INTERFACE (large) Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 46588 Lines: 1561 This large patch adds the sysfs interface to channel bonding. It will allow users to add and remove bonds, add and remove slaves, and change all bonding parameters without using ifenslave. The ifenslave interface still works. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -33,6 +33,7 @@ #include #include #include +#include #include "bond_3ad.h" #include "bond_alb.h" @@ -255,6 +247,13 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); int bond_create(char *name, struct bond_params *params, struct bonding **newbond); void bond_deinit(struct net_device *bond_dev); +int bond_create_sysfs(void); +void bond_destroy_sysfs(void); +void bond_destroy_sysfs_entry(struct bonding *bond); +int bond_create_sysfs_entry(struct bonding *bond); +int bond_create_slave_symlinks(struct net_device *master, struct net_device *slave); +void bond_destroy_slave_symlinks(struct net_device *master, struct net_device *slave); +int bond_check_abi_ver(void); int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, struct slave **vassal); int bond_release(struct net_device *bond_dev, struct net_device *slave_dev); int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev); diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -573,6 +573,7 @@ static struct proc_dir_entry *bond_proc_dir = NULL; #endif +extern struct rw_semaphore bonding_rwsem; static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -1957,6 +1957,9 @@ } } + res = bond_create_slave_symlinks(bond_dev, slave_dev); + if (res) + goto err_unset_master; printk(KERN_INFO DRV_NAME ": %s: enslaving %s as a%s interface with a%s link.\n", bond_dev->name, slave_dev->name, @@ -2128,6 +2171,9 @@ write_unlock_bh(&bond->lock); + /* must do this from outside any spinlocks */ + bond_destroy_slave_symlinks(bond_dev, slave_dev); + bond_del_vlans_from_slave(bond, slave_dev); /* If the mode USES_PRIMARY, then we should only remove its @@ -2399,6 +2406,22 @@ } } +int bond_check_abi_ver(void) +{ + int retval = 1; + + if (orig_app_abi_ver == -1) { + orig_app_abi_ver = BOND_ABI_VERSION; + app_abi_ver = BOND_ABI_VERSION; + } + else { + if (app_abi_ver == 0) + retval = 0; + } + + return retval; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3367,7 +3390,10 @@ bond_remove_proc_entry(bond); bond_create_proc_entry(bond); #endif - + down_write(&(bonding_rwsem)); + bond_destroy_sysfs_entry(bond); + bond_create_sysfs_entry(bond); + up_write(&(bonding_rwsem)); return NOTIFY_DONE; } @@ -3761,6 +3787,7 @@ return -EINVAL; } + down_write(&(bonding_rwsem)); slave_dev = dev_get_by_name(ifr->ifr_slave); dprintk("slave_dev=%p: \n", slave_dev); @@ -3801,6 +3828,7 @@ orig_app_abi_ver = prev_abi_ver; } + up_write(&(bonding_rwsem)); return res; } @@ -4683,17 +4699,21 @@ goto err; } + res = bond_create_sysfs(); + if (res) + goto err; + register_netdevice_notifier(&bond_netdev_notifier); - return 0; - -out_err: - /* free and unregister all bonds that were successfully added */ + goto out; +err: + rtnl_lock(); bond_free_all(); - + bond_destroy_sysfs(); rtnl_unlock(); - +out: return res; + } static void __exit bonding_exit(void) @@ -4702,6 +4699,7 @@ rtnl_lock(); bond_free_all(); + bond_destroy_sysfs(); rtnl_unlock(); } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_sysfs.c linux-2.6.12-rc2/drivers/net/bonding/bond_sysfs.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_sysfs.c 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_sysfs.c 2005-04-07 13:57:29.000000000 -0700 @@ -0,0 +1,1395 @@ + +/* + * Copyright(c) 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * The full GNU General Public License is included in this distribution in the + * file called LICENSE. + * + * + * Changes: + * + * 2004/12/12 - Mitch Williams + * - Initial creation of sysfs interface. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* #define BONDING_DEBUG 1 */ +#include "bonding.h" +#define to_class_dev(obj) container_of(obj,struct class_device,kobj) +#define to_net_dev(class) container_of(class, struct net_device, class_dev) +#define to_bond(cd) ((struct bonding *)(to_net_dev(cd)->priv)) + +/*---------------------------- Declarations -------------------------------*/ + +/* Macros for real simple parsing of text. */ +#define eat_nonalnum(str,whence,max) \ + while (whence < max) {if (!isalnum(str[whence])) whence++; else break;}; +#define find_next_nonalpha(str,whence,max) \ + while (whence < max) {if (isalnum(str[whence])) whence++; else break;}; + +extern struct list_head bond_dev_list; +extern struct bond_params bonding_defaults; +extern struct bond_parm_tbl bond_mode_tbl[]; +extern struct bond_parm_tbl bond_lacp_tbl[]; + +static struct class *netdev_class; +/*--------------------------- Data Structures -----------------------------*/ + +/* Bonding sysfs lock. Why can't we just use the subsytem lock? + * Because kobject_register tries to acquire the subsystem lock. If + * we already hold the lock (which we would if the user was creating + * a new bond through the sysfs interface), we deadlock. + */ + +struct rw_semaphore bonding_rwsem; + + + + +/*------------------------------ Functions --------------------------------*/ + +/* + * "show" function for the bond_masters attribute. + * The class parameter is ignored. + */ +static ssize_t bonding_show_bonds(struct class *cls, char *buffer) +{ + int res = 0; + struct bonding *bond; + + down_read(&(bonding_rwsem)); + + list_for_each_entry(bond, &bond_dev_list, bond_list) { + res += sprintf(buffer + res, "%s ", + bond->dev->name); + if (res > (PAGE_SIZE - IFNAMSIZ)) { + dprintk("eek! too many bonds!\n"); + break; + } + } + res += sprintf(buffer + res, "\n"); + res++; + up_read(&(bonding_rwsem)); + return res; +} + +/* + * "store" function for the bond_masters attribute. This is what + * creates and deletes entire bonds. + * + * The class parameter is ignored. + * + * This function uses the eat_nonalnum and eat_alnum macros, define + * above. Why not use sscanf()? Scanf can get strings, but can't filter + * out inappropriate characters. For example, we can't have bonds named + * "foo/bar" or "foo*bar" or "Does this work?" as these aren't valid + * filenames. While we could use scanf to get strings and then validate + * them, this is quicker. + * The above examples give us these results: + * "foo/bar" gives two bonds, "foo" and "bar". + * "foo*bar" gives two bonds, "foo" and "bar". + * "Does this work?" gives three bonds, "Does", "this", and "work". + */ + +static ssize_t bonding_store_bonds(struct class *cls, const char *buffer, size_t count) +{ + char name[IFNAMSIZ]; + int i, res, found, pos = 0; + struct bonding *bond; + struct bonding *nxt; + + down_write(&(bonding_rwsem)); + /* First process adds */ + eat_nonalnum(buffer, pos, count); + /* Pos now points to the first alpha character. */ + i = pos; + find_next_nonalpha(buffer, i, count); + /* i now points to the next character past the end of the bond name. */ + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME "Interface name %.*s too large! Ignoring.\n", + i - pos, buffer + pos); + up_write(&(bonding_rwsem)); + return -EPERM; + } + /* Copy the bond name so we can deal with it separately. */ + strncpy(name, buffer + pos, i - pos); + /* Don't forget the null terminator! */ + name[i - pos] = 0; + while (strlen(name)) { + /* Got a bond name in name. Is it already in the list? */ + found = 0; + list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { + if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) { + /* Temporarily set a meaningless flag. When + * we get done with the loop, we'll check all of these. + * If the bond doesn't have this flag set, then we need + * to remove the bond. If the flag has it set, then + * we can just clear the flag. + */ + bond->flags |= IFF_DYNAMIC; + found = 1; + break; /* Found it, so go to next name */ + } + } + if (found == 0) { + printk(KERN_INFO DRV_NAME ": %s is being created...\n", name); + res = bond_create(name, &bonding_defaults, &bond); + if (res) { + up_write(&(bonding_rwsem)); + printk(KERN_INFO DRV_NAME ": %s interface already exists. Bond creation failed.\n", name); + return res; + } + printk(KERN_INFO DRV_NAME ": %s created.\n", name); + /* Set the flag so we don't delete + * this interface in the loop below. + */ + bond->flags |= IFF_DYNAMIC; + } + /* Scan for the next name. i still has the location of + * the char just past the end of the last name we handled. + */ + pos = i; + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME + ": %.*s interface name too large! Ignoring.\n", + i - pos, buffer + pos); + up_write(&(bonding_rwsem)); + return -EPERM; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + } /* end of while loop and end of input */ + + /* Now we do deletes. Walk through the list, and check to see + * if the flag didn't get set. If it's set, clear it. If it's + * not set, delete the bond. + */ + list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { + if (bond->flags & IFF_DYNAMIC) { + bond->flags &= ~IFF_DYNAMIC; + } else { + printk(KERN_INFO DRV_NAME ": %s is being deleted...\n", bond->dev->name); + rtnl_lock(); + unregister_netdevice(bond->dev); + bond_deinit(bond->dev); + bond_destroy_sysfs_entry(bond); + rtnl_unlock(); + printk(KERN_INFO DRV_NAME ": %s deleted.\n", bond->dev->name); + } + } + /* Always return either count or an error. If you return 0, you'll + * get called forever, which is bad. + */ + up_write(&(bonding_rwsem)); + return count; +} +/* class attribute for bond_masters file. This ends up in /sys/class/net */ +static CLASS_ATTR(bonding_masters, S_IWUSR | S_IRUGO, + bonding_show_bonds, bonding_store_bonds); + +/* + * Show slave/s status for current bond. Same info as in the proc + * entry, but we can't use the same functions. :-( + */ +static ssize_t bonding_show_stat(struct class_device *cd, char *buf) +{ + struct slave *curr; + int i, len = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, curr, i) { + len += sprintf(buf + len, "\nSlave Interface: %s\n", + curr->dev->name); + len += sprintf(buf + len, "MII Status: %s\n", + (curr->link == BOND_LINK_UP) ? "up" : "down"); + len += sprintf(buf + len, "Link Failure Count: %d\n", + curr->link_failure_count); + + len += sprintf(buf + len, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + curr->perm_hwaddr[0], curr->perm_hwaddr[1], + curr->perm_hwaddr[2], curr->perm_hwaddr[3], + curr->perm_hwaddr[4], curr->perm_hwaddr[5]); + + if (bond->params.mode == BOND_MODE_8023AD) { + const struct aggregator *agg = + SLAVE_AD_INFO(curr).port.aggregator; + + if (agg) { + len += sprintf(buf + len, "Aggregator ID: %d\n", + agg->aggregator_identifier); + } else { + len += sprintf(buf + len, + "Aggregator ID: N/A\n"); + } + } + } + + read_unlock_bh(&bond->lock); + up_read(&bonding_rwsem); + return len; +} +static CLASS_DEVICE_ATTR(stat, S_IRUGO, bonding_show_stat, NULL); + +int bond_create_slave_symlinks(struct net_device *master, struct net_device *slave) +{ + char linkname[IFNAMSIZ+7]; + int ret = 0; + + /* first, create a link from the slave back to the master */ + ret = sysfs_create_link(&(slave->class_dev.kobj), &(master->class_dev.kobj), + "master"); + if (ret) + return ret; + /* next, create a link from the master to the slave */ + sprintf(linkname,"slave_%s",slave->name); + ret = sysfs_create_link(&(master->class_dev.kobj), &(slave->class_dev.kobj), + linkname); + return ret; + +} + +void bond_destroy_slave_symlinks(struct net_device *master, struct net_device *slave) +{ + char linkname[IFNAMSIZ+7]; + + sysfs_remove_link(&(slave->class_dev.kobj), "master"); + sprintf(linkname,"slave_%s",slave->name); + sysfs_remove_link(&(master->class_dev.kobj), linkname); +} + + +/* + * Show the slaves in the current bond. + */ +static ssize_t bonding_show_slaves(struct class_device *cd, char *buf) +{ + struct slave *slave; + int i, res = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, slave, i) { + res += sprintf(buf + res, "%s ", slave->dev->name); + if (res > (PAGE_SIZE - IFNAMSIZ)) { + dprintk("eek! too many slaves!\n"); + break; + } + } + read_unlock_bh(&bond->lock); + res += sprintf(buf + res, "\n"); + res++; + up_read(&(bonding_rwsem)); + return res; +} + +/* + * Set the slaves in the current bond. The bond interface must be + * up for this to succeed. + * This function is largely the same flow as bonding_update_bonds(). + */ +static ssize_t bonding_store_slaves(struct class_device *cd, const char *buffer, size_t count) +{ + char name[IFNAMSIZ]; + int i, j, res, found, pos = 0, ret = count; + struct slave *slave; + struct net_device *dev = 0; + struct bonding *bond = to_bond(cd); + + if (!bond_check_abi_ver()) + { + printk(KERN_ERR DRV_NAME + ": Error: your version of ifenslave is incompatible " + "with the sysfs interface in this version of bonding. " + "Upgrade ifenslave to version 1 or greater and reload " + "bonding.\n"); + return -EINVAL; + } + + down_write(&(bonding_rwsem)); + + /* Quick sanity check -- is the bond interface up? */ + if (!(bond->dev->flags & IFF_UP)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update slaves because interface is down.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + /* Note: We can't hold bond->lock here, as bond_create grabs it. */ + + /* First process adds */ + + /* Copy the first name we find. */ + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME ": %s: Slave name %.*s too large! Ignoring.\n", + bond->dev->name, + i - pos, buffer + pos); + ret = -EPERM; + goto out; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + + while (strlen(name)) { + /* Got a slave name in name. Is it already there? */ + found = 0; + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, slave, j) { + if (strnicmp(slave->dev->name, name, IFNAMSIZ) == 0) { + /* Temporarily set a meaningless flag. When + * we get done with the loop, we'll check all of these. + * If the slave doesn't have this flag set, then we need + * to remove the slave. If the flag has it set, then + * we can just clear the flag. + */ + slave->original_flags |= IFF_DYNAMIC; + found = 1; + break; /* Found it, so go to next name */ + } + } + read_unlock_bh(&bond->lock); + if (found == 0) { + printk(KERN_INFO DRV_NAME ": %s: Adding slave %s.\n", + bond->dev->name, name); + dev = dev_get_by_name(name); + if (!dev) { + printk(KERN_INFO DRV_NAME + ": %s: Interface %s does not exist!\n", + bond->dev->name, name); + ret = -EPERM; + goto out; + } + + if (dev->flags & IFF_SLAVE) { + printk(KERN_INFO DRV_NAME + ": %s: Interface %s is already enslaved!\n", + bond->dev->name, name); + ret = -EPERM; + goto out; + } + + /* If this is the first slave, then we need to set + the master's hardware address to be the same as the + slave's. */ + if (!(*((u32 *) & (bond->dev->dev_addr[0])))) { + memcpy(bond->dev->dev_addr, dev->dev_addr, + dev->addr_len); + } + + /* Set the slave's MTU to match the bond */ + if (dev->mtu != bond->dev->mtu) { + if (dev->change_mtu) { + res = dev->change_mtu(dev, + bond->dev->mtu); + if (res) { + ret = res; + goto out; + } + } else { + dev->mtu = bond->dev->mtu; + } + } + rtnl_lock(); + res = bond_enslave(bond->dev, dev, &slave); + rtnl_unlock(); + if (res) { + ret = res; + goto out; + } + slave->original_flags |= IFF_DYNAMIC; + dev_put(dev); + } + /* Get the next name in the buffer. */ + pos = i; + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME + ": %s: Slave name %.*s too large! Ignoring.\n", + bond->dev->name, i - pos, buffer + pos); + ret = -EPERM; + goto out; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + } /* End of while loop, and end of input. */ + + /* Now handle deletes. + * We can't use bond_for_each_slave here because we might modify + * the list when we're inside the loop. We can't hold the lock + * either because bond_release grabs it. + */ + slave = bond->first_slave; + i = bond->slave_cnt; + while (i > 0) { + BUG_ON(slave == 0); + if (slave->original_flags & IFF_DYNAMIC) { + slave->original_flags &= ~IFF_DYNAMIC; + slave = slave->next; + } else { + /* Didn't find the name of this slave in the list, so + * remove the slave. + */ + printk(KERN_INFO DRV_NAME + ": %s: Removing slave %s\n", + bond->dev->name, + slave->dev->name); + dev = slave->dev; + slave = slave->next; + rtnl_lock(); + res = bond_release(bond->dev, dev); + rtnl_unlock(); + if (res) { + ret = res; + goto out; + } + /* set the slave MTU to the default */ + if (dev->change_mtu) { + dev->change_mtu(dev, 1500); + } else { + dev->mtu = 1500; + } + } + i--; + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(slaves, S_IRUGO | S_IWUSR, bonding_show_slaves, bonding_store_slaves); + +/* + * Show and set the bonding mode. The bond interface must be down to + * change the mode. + */ +static ssize_t bonding_show_mode(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%s %d\n", + bond_mode_tbl[bond->params.mode].modename, + bond->params.mode) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_mode(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (bond->dev->flags & IFF_UP) { + printk(KERN_ERR DRV_NAME + "Unable to update mode of %s because interface is up.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + new_value = bond_parse_parm((char *)buf, bond_mode_tbl); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid mode value %.*s.\n", + bond->dev->name, + (int)strlen(buf) - 1, buf); + ret = -EINVAL; + goto out; + } else { + bond->params.mode = new_value; + bond_set_mode_ops(bond->dev, bond->params.mode); + printk(KERN_INFO DRV_NAME ": %s: setting mode to %s (%d).\n", + bond->dev->name, bond_mode_tbl[new_value].modename, new_value); + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(mode, S_IRUGO | S_IWUSR, bonding_show_mode, bonding_store_mode); + +/* + * Show and set the arp timer interval. There are two tricky bits + * here. First, if ARP monitoring is activated, then we must disable + * MII monitoring. Second, if the ARP timer isn't running, we must + * start it. + */ +static ssize_t bonding_show_arp_interval(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.arp_interval) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_arp_interval(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid arp_interval value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + printk(KERN_INFO DRV_NAME + ": %s: Setting ARP monitoring interval to %d.\n", + bond->dev->name, new_value); + bond->params.arp_interval = new_value; + if (bond->params.miimon) { + printk(KERN_INFO DRV_NAME + ": %s: ARP monitoring cannot be used with MII monitoring. " + "%s Disabling MII monitoring.\n", + bond->dev->name, bond->dev->name); + bond->params.miimon = 0; + del_timer_sync(&bond->mii_timer); + /* Kill MII timer, else it brings bond's link down */ + } + if (!bond->params.arp_targets[0]) { + printk(KERN_INFO DRV_NAME + ": %s: ARP monitoring has been set up, " + "but no ARP targets have been specified.\n", + bond->dev->name); + } + if (bond->dev->flags & IFF_UP) { + /* If the interface is up, we may need to fire off + * the ARP timer. If the interface is down, the + * timer will get fired off when the open function + * is called. + */ + if (bond->arp_timer.function) { + /* The timer's already set up, so fire it off */ + mod_timer(&bond->arp_timer, jiffies + 1); + } else { + /* Set up the timer. */ + init_timer(&bond->arp_timer); + bond->arp_timer.expires = jiffies + 1; + bond->arp_timer.data = + (unsigned long) bond->dev; + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { + bond->arp_timer.function = + (void *) + &bond_activebackup_arp_mon; + } else { + bond->arp_timer.function = + (void *) + &bond_loadbalance_arp_mon; + } + add_timer(&bond->arp_timer); + } + } + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(arp_interval, S_IRUGO | S_IWUSR , bonding_show_arp_interval, bonding_store_arp_interval); + +/* + * Show and set the arp targets. + */ +static ssize_t bonding_show_arp_targets(struct class_device *cd, char *buf) +{ + int i, res = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && bond->params.arp_targets[i]; + i++) { + res += sprintf(buf + res, "%u.%u.%u.%u ", + NIPQUAD(bond->params.arp_targets[i])); + res++; + } + + up_read(&(bonding_rwsem)); + return res; +} + +static ssize_t bonding_store_arp_targets(struct class_device *cd, const char *buf, size_t count) +{ + int octet1, octet2, octet3, octet4, ret = count; + int newpos = 0, pos = 0, i = 0; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d.%d.%d.%d%n", &octet1, &octet2, &octet3, &octet4, &pos); + while ((pos < count) && (i < BOND_MAX_ARP_TARGETS)) { + if ( (octet1 < 0) || (octet1 > 255) + || (octet2 < 0) || (octet2 > 255) + || (octet3 < 0) || (octet3 > 255) + || (octet4 < 0) || (octet4 > 255) + || ((octet1 == 0) && (octet2 == 0) && + (octet3 == 0) && (octet4 == 0)) + || ((octet1 == 255) && (octet2 == 255) && + (octet3 == 255) && (octet4 == 255)) + ) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to add arp target %d.%d.%d.%d\n", + bond->dev->name, octet1, octet2, octet3, octet4); + ret = -EINVAL; + goto out; + } else { + printk(KERN_INFO DRV_NAME + ": %s: Adding arp target %d.%d.%d.%d\n", + bond->dev->name, octet1, octet2, octet3, octet4); + /* Is this going to get me into trouble on big-endian boxes? */ + /* Is there a macro to do this? I can't find one... */ + bond->params.arp_targets[i] = htonl + ((((u32) octet1 & 0xff) << 24) | + (((u32) octet2 & 0xff) << 16) | + (((u32) octet3 & 0xff) << 8) | ((u32) octet4 & + 0xff)); + + i++; + } + + newpos = 0; + sscanf(buf + pos, "%d.%d.%d.%d%n", &octet1, &octet2, &octet3, + &octet4, &newpos); + if (newpos == 0) { + break; + } + pos += newpos; + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(arp_ip_target, S_IRUGO | S_IWUSR , bonding_show_arp_targets, bonding_store_arp_targets); + +/* + * Show and set the up and down delays. These must be multiples of the + * MII monitoring value, and are stored internally as the multiplier. + * Thus, we must translate to MS for the real world. + */ +static ssize_t bonding_show_downdelay(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.downdelay * bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_downdelay(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (!(bond->params.miimon)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to set down delay as MII monitoring is disabled\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid down delay value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + if ((new_value % bond->params.miimon) != 0) { + printk(KERN_WARNING DRV_NAME + ": %s: Warning: down delay (%d) is not a multiple " + "of miimon (%d), delay rounded to %d ms\n", + bond->dev->name, new_value, bond->params.miimon, + (new_value / bond->params.miimon) * + bond->params.miimon); + } + bond->params.downdelay = new_value / bond->params.miimon; + printk(KERN_INFO DRV_NAME ": %s: Setting down delay to %d.\n", + bond->dev->name, bond->params.downdelay * bond->params.miimon); + + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(down_delay, S_IRUGO | S_IWUSR , bonding_show_downdelay, bonding_store_downdelay); + +static ssize_t bonding_show_updelay(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.updelay * bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; + +} + +static ssize_t bonding_store_updelay(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (!(bond->params.miimon)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to set up delay as MII monitoring is disabled\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid up delay value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + if ((new_value % bond->params.miimon) != 0) { + printk(KERN_WARNING DRV_NAME + ": %s: Warning: up delay (%d) is not a multiple " + "of miimon (%d), updelay rounded to %d ms\n", + bond->dev->name, new_value, bond->params.miimon, + (new_value / bond->params.miimon) * + bond->params.miimon); + } + bond->params.updelay = new_value / bond->params.miimon; + printk(KERN_INFO DRV_NAME ": %s: Setting up delay to %d.\n", + bond->dev->name, bond->params.updelay * bond->params.miimon); + + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(up_delay, S_IRUGO | S_IWUSR , bonding_show_updelay, bonding_store_updelay); + +/* + * Show and set the LACP interval. Interface must be down, and the mode + * must be set to 802.3ad mode. + */ +static ssize_t bonding_show_lacp(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%s %d\n", + bond_lacp_tbl[bond->params.lacp_fast].modename, + bond->params.lacp_fast) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_lacp(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (bond->dev->flags & IFF_UP) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update LACP rate because interface is up.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + if (bond->params.mode != BOND_MODE_8023AD) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update LACP rate because bond is not in 802.3ad mode.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + new_value = bond_parse_parm((char *)buf, bond_lacp_tbl); + + if ((new_value == 1) || (new_value == 0)) { + bond->params.lacp_fast = new_value; + printk(KERN_INFO DRV_NAME + ": %s: Setting LACP rate to %s (%d).\n", + bond->dev->name, bond_lacp_tbl[new_value].modename, new_value); + } else { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid LACP rate value %.*s.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + ret = -EINVAL; + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR, bonding_show_lacp, bonding_store_lacp); + +/* + * Show and set the MII monitor interval. There are two tricky bits + * here. First, if MII monitoring is activated, then we must disable + * ARP monitoring. Second, if the timer isn't running, we must + * start it. + */ +static ssize_t bonding_show_miimon(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_miimon(struct class_device *cd, const char *buf, size_t count) +{ + int new_value; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid miimon value %d.\n", + bond->dev->name, new_value); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Setting MII monitoring interval to %d.\n", + bond->dev->name, new_value); + bond->params.miimon = new_value; + if(bond->params.updelay) + printk(KERN_INFO DRV_NAME + ": %s: Note: Updating updelay (to %d) " + "since it is a multiple of the miimon value.\n", + bond->dev->name, + bond->params.updelay * bond->params.miimon); + if(bond->params.downdelay) + printk(KERN_INFO DRV_NAME + ": %s: Note: Updating downdelay (to %d) " + "since it is a multiple of the miimon value.\n", + bond->dev->name, + bond->params.downdelay * bond->params.miimon); + if (bond->params.arp_interval) { + printk(KERN_INFO DRV_NAME + ": %s: MII monitoring cannot be used with " + "ARP monitoring. Disabling ARP monitoring...\n", + bond->dev->name); + bond->params.arp_interval = 0; + del_timer_sync(&bond->arp_timer); + /* Kill ARP timer, else it brings bond's link down */ + } + + if (bond->dev->flags & IFF_UP) { + /* If the interface is up, we may need to fire off + * the MII timer. If the interface is down, the + * timer will get fired off when the open function + * is called. + */ + if (bond->mii_timer.function) { + /* The timer's already set up, so fire it off */ + mod_timer(&bond->mii_timer, jiffies + 1); + } else { + /* Set up the timer. */ + init_timer(&bond->mii_timer); + bond->mii_timer.expires = jiffies + 1; + bond->mii_timer.data = + (unsigned long) bond->dev; + bond->mii_timer.function = + (void *) &bond_mii_monitor; + add_timer(&bond->mii_timer); + } + } + } + + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(miimon, S_IRUGO | S_IWUSR, bonding_show_miimon, bonding_store_miimon); + +/* + * Show and set the primary slave. The store function is much + * simpler than bonding_store_slaves function because it only needs to + * handle one interface name. + * The bond must be a mode that supports a primary for this be + * set. + */ +static ssize_t bonding_show_primary(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->primary_slave) + count = sprintf(buf, "%s\n", bond->primary_slave->dev->name) + 1; + + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_primary(struct class_device *cd, const char *buf, size_t count) +{ + int i; + struct slave *slave; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + write_lock_bh(&bond->lock); + if (!USES_PRIMARY(bond->params.mode)) { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set primary slave; %s is in mode %d\n", + bond->dev->name, bond->dev->name, bond->params.mode); + } else { + bond_for_each_slave(bond, slave, i) { + if (strnicmp + (slave->dev->name, buf, + strlen(slave->dev->name)) == 0) { + printk(KERN_INFO DRV_NAME + ": %s: Setting %s as primary slave.\n", + bond->dev->name, slave->dev->name); + bond->primary_slave = slave; + bond_select_active_slave(bond); + goto out; + } + } + + /* if we got here, then we didn't match the name of any slave */ + + if (strlen(buf) == 0 || buf[0] == '\n') { + printk(KERN_INFO DRV_NAME + ": %s: Setting primary slave to None.\n", + bond->dev->name); + bond->primary_slave = 0; + bond_select_active_slave(bond); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set %.*s as primary slave as it is not a slave.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + } + } +out: + write_unlock_bh(&bond->lock); + up_write(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary, bonding_store_primary); + +/* + * Show and set the use_carrier flag. + */ +static ssize_t bonding_show_carrier(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.use_carrier) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_carrier(struct class_device *cd, const char *buf, size_t count) +{ + int new_value; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + if ((new_value == 0) || (new_value == 1)) { + bond->params.use_carrier = new_value; + printk(KERN_INFO DRV_NAME ": %s: Setting use_carrier to %d.\n", + bond->dev->name, new_value); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Ignoring invalid use_carrier value %d.\n", + bond->dev->name, new_value); + } + up_write(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(use_carrier, S_IRUGO | S_IWUSR, bonding_show_carrier, bonding_store_carrier); + + +/* + * Show and set currently active_slave. + */ +static ssize_t bonding_show_active_slave(struct class_device *cd, char *buf) +{ + struct slave *curr; + struct bonding *bond = to_bond(cd); + int count; + + down_read(&(bonding_rwsem)); + + read_lock(&bond->curr_slave_lock); + curr = bond->curr_active_slave; + read_unlock(&bond->curr_slave_lock); + + if (USES_PRIMARY(bond->params.mode)) { + count = sprintf(buf, "%s\n", (curr) ? curr->dev->name : "None") + 1; + } + else { + count = sprintf(buf, "%s\n", "None") + 1; + } + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_active_slave(struct class_device *cd, const char *buf, size_t count) +{ + int i; + struct slave *slave; + struct slave *old_active = NULL; + struct slave *new_active = NULL; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + write_lock_bh(&bond->lock); + if (!USES_PRIMARY(bond->params.mode)) { + printk(KERN_INFO DRV_NAME + ": %s: Unable to change active slave; %s is in mode %d\n", + bond->dev->name, bond->dev->name, bond->params.mode); + } else { + bond_for_each_slave(bond, slave, i) { + if (strnicmp + (slave->dev->name, buf, + strlen(slave->dev->name)) == 0) { + old_active = bond->curr_active_slave; + new_active = slave; + if (new_active && (new_active == old_active)) { + /* do nothing */ + printk(KERN_INFO DRV_NAME + ": %s: %s is already the current active slave.\n", + bond->dev->name, slave->dev->name); + goto out; + } + else { + if ((new_active) && + (old_active) && + (new_active->link == BOND_LINK_UP) && + IS_UP(new_active->dev)) { + printk(KERN_INFO DRV_NAME + ": %s: Setting %s as active slave.\n", + bond->dev->name, slave->dev->name); + bond_change_active_slave(bond, new_active); + } + else { + printk(KERN_INFO DRV_NAME + ": %s: Could not set %s as active slave; " + "either %s is down or the link is down.\n", + bond->dev->name, slave->dev->name, + slave->dev->name); + } + goto out; + } + } + } + + /* if we got here, then we didn't match the name of any slave */ + + if (strlen(buf) == 0 || buf[0] == '\n') { + printk(KERN_INFO DRV_NAME + ": %s: Setting active slave to None.\n", + bond->dev->name); + bond->primary_slave = 0; + bond_select_active_slave(bond); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set %.*s as active slave as it is not a slave.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + } + } +out: + write_unlock_bh(&bond->lock); + up_write(&(bonding_rwsem)); + return count; + +} +static CLASS_DEVICE_ATTR(active_slave, S_IRUGO | S_IWUSR, bonding_show_active_slave, bonding_store_active_slave); + + +/* + * Show link status of the bond interface. + */ +static ssize_t bonding_show_mii_status(struct class_device *cd, char *buf) +{ + int count; + struct slave *curr; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + read_lock(&bond->curr_slave_lock); + curr = bond->curr_active_slave; + read_unlock(&bond->curr_slave_lock); + + count = sprintf(buf, "%s\n", (curr) ? "up" : "down") + 1; + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(mii_status, S_IRUGO, bonding_show_mii_status, NULL); + + +/* + * Show current 802.3ad aggregator ID. + */ +static ssize_t bonding_show_ad_aggregator(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.aggregator_id) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_aggregator, S_IRUGO, bonding_show_ad_aggregator, NULL); + + +/* + * Show number of active 802.3ad ports. + */ +static ssize_t bonding_show_ad_num_ports(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0: ad_info.ports) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_num_ports, S_IRUGO, bonding_show_ad_num_ports, NULL); + + +/* + * Show current 802.3ad actor key. + */ +static ssize_t bonding_show_ad_actor_key(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.actor_key) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_actor_key, S_IRUGO, bonding_show_ad_actor_key, NULL); + + +/* + * Show current 802.3ad partner key. + */ +static ssize_t bonding_show_ad_partner_key(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.partner_key) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_partner_key, S_IRUGO, bonding_show_ad_partner_key, NULL); + + +/* + * Show current 802.3ad partner mac. + */ +static ssize_t bonding_show_ad_partner_mac(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + if (!bond_3ad_get_active_agg_info(bond, &ad_info)) { + count = sprintf(buf,"%02x:%02x:%02x:%02x:%02x:%02x\n", + ad_info.partner_system[0], + ad_info.partner_system[1], + ad_info.partner_system[2], + ad_info.partner_system[3], + ad_info.partner_system[4], + ad_info.partner_system[5]) + 1; + } + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_partner_mac, S_IRUGO, bonding_show_ad_partner_mac, NULL); + + + +static struct attribute *per_bond_attrs[] = { + &class_device_attr_stat.attr, + &class_device_attr_slaves.attr, + &class_device_attr_mode.attr, + &class_device_attr_arp_interval.attr, + &class_device_attr_arp_ip_target.attr, + &class_device_attr_down_delay.attr, + &class_device_attr_up_delay.attr, + &class_device_attr_lacp_rate.attr, + &class_device_attr_miimon.attr, + &class_device_attr_primary.attr, + &class_device_attr_use_carrier.attr, + &class_device_attr_active_slave.attr, + &class_device_attr_mii_status.attr, + &class_device_attr_ad_aggregator.attr, + &class_device_attr_ad_num_ports.attr, + &class_device_attr_ad_actor_key.attr, + &class_device_attr_ad_partner_key.attr, + &class_device_attr_ad_partner_mac.attr, + NULL, +}; + +static struct attribute_group bonding_group = { + .name = "bonding", + .attrs = per_bond_attrs, +}; + +/* + * Initialize sysfs. This sets up the bonding_masters file in + * /sys/class/net. + */ +int bond_create_sysfs(void) +{ + int ret = 0; + struct bonding *firstbond; + + init_rwsem(&bonding_rwsem); + + /* get the netdev class pointer */ + firstbond = container_of(bond_dev_list.next, struct bonding, bond_list); + if (!firstbond) + { + return -ENODEV; + + } + netdev_class = firstbond->dev->class_dev.class; + if (!netdev_class) + { + return -ENODEV; + } + ret = class_create_file(netdev_class, &class_attr_bonding_masters); + + return ret; + +} + +/* + * Remove /sys/class/net/bonding_masters. + */ +void bond_destroy_sysfs(void) +{ + if (netdev_class) + class_remove_file(netdev_class, &class_attr_bonding_masters); +} + +/* + * Initialize sysfs for each bond. This sets up and registers + * the 'bondctl' directory for each individual bond under /sys/class/net. + */ +int bond_create_sysfs_entry(struct bonding *bond) +{ + struct net_device *dev = bond->dev; + int err; + + err = sysfs_create_group(&(dev->class_dev.kobj), &bonding_group); + if (err) { + printk(KERN_EMERG "eek! didn't create group!\n"); + } + + return err; +} +/* + * Remove sysfs entries for each bond. + */ +void bond_destroy_sysfs_entry(struct bonding *bond) +{ + struct net_device *dev = bond->dev; + + sysfs_remove_group(&(dev->class_dev.kobj), &bonding_group); +} + diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/Makefile linux-2.6.12-rc2/drivers/net/bonding/Makefile --- linux-2.6.12-rc2clean/drivers/net/bonding/Makefile 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/Makefile 2005-04-07 13:57:53.000000000 -0700 @@ -4,5 +4,5 @@ obj-$(CONFIG_BONDING) += bonding.o -bonding-objs := bond_main.o bond_3ad.o bond_alb.o +bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o From radheka.godse@intel.com Thu Apr 7 16:58:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 16:59:05 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37Nwxjq015158 for ; Thu, 7 Apr 2005 16:58:59 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j37NwmwZ011227; Thu, 7 Apr 2005 23:58:48 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j37NwmRZ026897; Thu, 7 Apr 2005 23:58:48 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j37NwlSL031626; Thu, 7 Apr 2005 16:58:47 -0700 Date: Fri, 8 Apr 2005 16:58:19 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r9/17] bonding: get primary name from slave dev Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 1059 Lines: 23 This patch fixes a bug in the proc file handler in bonding. The name of the primary slave was taken from the command-line options, instead of from the dev structure of the primary slave itself. This caused an incorrect display if the primary is set or changed via sysfs. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -3166,8 +3166,8 @@ if (USES_PRIMARY(bond->params.mode)) { seq_printf(seq, "Primary Slave: %s\n", - (bond->params.primary[0]) ? - bond->params.primary : "None"); + (bond->primary_slave) ? + bond->primary_slave->dev->name : "None"); seq_printf(seq, "Currently Active Slave: %s\n", (curr) ? curr->dev->name : "None"); From radheka.godse@intel.com Thu Apr 7 17:00:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:00:38 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3800YAD015817 for ; Thu, 7 Apr 2005 17:00:34 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3800MQe022258; Fri, 8 Apr 2005 00:00:22 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3800Mju002996; Fri, 8 Apr 2005 00:00:22 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j3800MSL031803; Thu, 7 Apr 2005 17:00:22 -0700 Date: Fri, 8 Apr 2005 16:59:54 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r10/17] bonding: added missing mode descriptions to modinfo Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 2010 Lines: 36 This patch updates the modinfo description for mode module param to include all available modes as described in bonding.txt. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -548,15 +548,21 @@ module_param(updelay, int, 0); MODULE_PARM_DESC(updelay, "Delay before considering link up, in milliseconds"); module_param(downdelay, int, 0); -MODULE_PARM_DESC(downdelay, "Delay before considering link down, in milliseconds"); +MODULE_PARM_DESC(downdelay, "Delay before considering link down, " + "in milliseconds"); module_param(use_carrier, int, 0); -MODULE_PARM_DESC(use_carrier, "Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default)"); +MODULE_PARM_DESC(use_carrier, "Use netif_carrier_ok (vs MII ioctls) in miimon; " + "0 for off, 1 for on (default)"); module_param(mode, charp, 0); -MODULE_PARM_DESC(mode, "Mode of operation : 0 for round robin, 1 for active-backup, 2 for xor"); +MODULE_PARM_DESC(mode, "Mode of operation : 0 for balance-rr, " + "1 for active-backup, 2 for balance-xor, " + "3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, " + "6 for balance-alb"); module_param(primary, charp, 0); MODULE_PARM_DESC(primary, "Primary network device to use"); module_param(lacp_rate, charp, 0); -MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner (slow/fast)"); +MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner " + "(slow/fast)"); module_param(arp_interval, int, 0); MODULE_PARM_DESC(arp_interval, "arp interval in milliseconds"); module_param_array(arp_ip_target, charp, NULL, 0); From radheka.godse@intel.com Thu Apr 7 17:01:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:01:57 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3801pJE016259 for ; Thu, 7 Apr 2005 17:01:51 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3801fQe022876; Fri, 8 Apr 2005 00:01:41 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3801fRZ029184; Fri, 8 Apr 2005 00:01:41 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j3801eSL031968; Thu, 7 Apr 2005 17:01:40 -0700 Date: Fri, 8 Apr 2005 17:01:12 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r11/17] bonding: add driver name to log messages Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 2931 Lines: 81 Trivial fix to include DRVNAME in logs printed to /var/log/messages Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c 2005-04-07 13:57:28.000000000 -0700 @@ -1915,7 +1915,8 @@ struct aggregator *aggregator; if (bond == NULL) { - printk(KERN_ERR "The slave %s is not attached to its bond\n", slave->dev->name); + printk(KERN_ERR DRV_NAME ": %s: The slave %s is not attached to its bond\n", + slave->dev->master->name, slave->dev->name); return -1; } @@ -2085,7 +2086,8 @@ // clear the aggregator ad_clear_agg(temp_aggregator); if (select_new_active_agg) { - printk(KERN_INFO "Removing an active aggregator\n"); + printk(KERN_INFO DRV_NAME ": %s: Removing an active aggregator\n", + slave->dev->master->name); // select new active aggregator ad_agg_selection_logic(__get_first_agg(port)); } @@ -2364,7 +2366,8 @@ } if (bond_3ad_get_active_agg_info(bond, &ad_info)) { - printk(KERN_DEBUG "ERROR: bond_3ad_get_active_agg_info failed\n"); + printk(KERN_DEBUG DRV_NAME ": %s: Error: " + "bond_3ad_get_active_agg_info failed\n", dev->name); goto out; } @@ -2373,7 +2376,9 @@ if (slaves_in_agg == 0) { /*the aggregator is empty*/ - printk(KERN_DEBUG "ERROR: active aggregator is empty\n"); + printk(KERN_DEBUG DRV_NAME ": %s: Error: active " + "aggregator is empty\n", + dev->name); goto out; } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -1846,10 +1846,10 @@ new_slave->dev->name); if (bond->params.mode == BOND_MODE_8023AD) { - printk(KERN_WARNING - "Operation of 802.3ad mode requires ETHTOOL " + printk(KERN_WARNING DRV_NAME + ": %s: Warning: Operation of 802.3ad mode requires ETHTOOL " "support in base driver for proper aggregator " - "selection.\n"); + "selection.\n", bond_dev->name); } } @@ -2677,8 +2677,11 @@ break; default: /* Should not happen */ - printk(KERN_ERR "bonding: Error: %s Illegal value (link=%d)\n", - slave->dev->name, slave->link); + printk(KERN_ERR DRV_NAME + ": %s: Error: %s Illegal value (link=%d)\n", + bond_dev->name, + slave->dev->name, + slave->link); goto out; } /* end of switch (slave->link) */ From radheka.godse@intel.com Thu Apr 7 17:03:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:03:47 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3803f6c017013 for ; Thu, 7 Apr 2005 17:03:41 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3803T6x017559; Fri, 8 Apr 2005 00:03:29 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3803TRZ030528; Fri, 8 Apr 2005 00:03:29 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j3803TSL032086; Thu, 7 Apr 2005 17:03:29 -0700 Date: Fri, 8 Apr 2005 17:03:01 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r12/17] bonding: prefix bondname to log messages Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 17442 Lines: 462 This patch adds : prefix to logs printed to /var/log/messages to identify messages on a per bond basis. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c 2005-04-07 13:57:28.000000000 -0700 @@ -1378,8 +1378,9 @@ } } if (!curr_port) { // meaning: the port was related to an aggregator but was not on the aggregator port list - printk(KERN_WARNING DRV_NAME ": Warning: Port %d (on %s) was " + printk(KERN_WARNING DRV_NAME ": %s: Warning: Port %d (on %s) was " "related to aggregator %d but was not on its port list\n", + port->slave->dev->master->name, port->actor_port_number, port->slave->dev->name, port->aggregator->aggregator_identifier); } @@ -1450,7 +1451,8 @@ dprintk("Port %d joined LAG %d(new LAG)\n", port->actor_port_number, port->aggregator->aggregator_identifier); } else { - printk(KERN_ERR DRV_NAME ": Port %d (on %s) did not find a suitable aggregator\n", + printk(KERN_ERR DRV_NAME ": %s: Port %d (on %s) did not find a suitable aggregator\n", + port->slave->dev->master->name, port->actor_port_number, port->slave->dev->name); } } @@ -1582,8 +1584,9 @@ // check if any partner replys if (best_aggregator->is_individual) { - printk(KERN_WARNING DRV_NAME ": Warning: No 802.3ad response from the link partner " - "for any adapters in the bond\n"); + printk(KERN_WARNING DRV_NAME ": %s: Warning: No 802.3ad response from " + "the link partner for any adapters in the bond\n", + best_aggregator->slave->dev->master->name); } // check if there are more than one aggregator @@ -1991,7 +1994,9 @@ // if slave is null, the whole port is not initialized if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Trying to unbind an uninitialized port on %s\n", slave->dev->name); + printk(KERN_WARNING DRV_NAME ": Warning: %s: Trying to " + "unbind an uninitialized port on %s\n", + slave->dev->master->name, slave->dev->name); return; } @@ -2022,7 +2027,8 @@ dprintk("Some port(s) related to LAG %d - replaceing with LAG %d\n", aggregator->aggregator_identifier, new_aggregator->aggregator_identifier); if ((new_aggregator->lag_ports == port) && new_aggregator->is_active) { - printk(KERN_INFO DRV_NAME ": Removing an active aggregator\n"); + printk(KERN_INFO DRV_NAME ": %s: Removing an active aggregator\n", + aggregator->slave->dev->master->name); // select new active aggregator select_new_active_agg = 1; } @@ -2052,15 +2058,17 @@ ad_agg_selection_logic(__get_first_agg(port)); } } else { - printk(KERN_WARNING DRV_NAME ": Warning: unbinding aggregator, " - "and could not find a new aggregator for its ports\n"); + printk(KERN_WARNING DRV_NAME ": %s: Warning: unbinding aggregator, " + "and could not find a new aggregator for its ports\n", + slave->dev->master->name); } } else { // in case that the only port related to this aggregator is the one we want to remove select_new_active_agg = aggregator->is_active; // clear the aggregator ad_clear_agg(aggregator); if (select_new_active_agg) { - printk(KERN_INFO "Removing an active aggregator\n"); + printk(KERN_INFO DRV_NAME ": %s: Removing an active aggregator\n", + slave->dev->master->name); // select new active aggregator ad_agg_selection_logic(__get_first_agg(port)); } @@ -2133,7 +2141,8 @@ // select the active aggregator for the bond if ((port = __get_first_port(bond))) { if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: bond's first port is uninitialized\n"); + printk(KERN_WARNING DRV_NAME ": %s: Warning: bond's first port is " + "uninitialized\n", bond->dev->name); goto re_arm; } @@ -2145,7 +2154,8 @@ // for each port run the state machines for (port = __get_first_port(bond); port; port = __get_next_port(port)) { if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: Found an uninitialized port\n"); + printk(KERN_WARNING DRV_NAME ": %s: Warning: Found an uninitialized " + "port\n", bond->dev->name); goto re_arm; } @@ -2186,7 +2196,8 @@ port = &(SLAVE_AD_INFO(slave).port); if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: port of slave %s is uninitialized\n", slave->dev->name); + printk(KERN_WARNING DRV_NAME ": %s: Warning: port of slave %s is " + "uninitialized\n", slave->dev->name, slave->dev->master->name); return; } @@ -2232,8 +2243,9 @@ // if slave is null, the whole port is not initialized if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: speed changed for uninitialized port on %s\n", - slave->dev->name); + printk(KERN_WARNING DRV_NAME ": Warning: %s: speed " + "changed for uninitialized port on %s\n", + slave->dev->master->name, slave->dev->name); return; } @@ -2259,8 +2271,9 @@ // if slave is null, the whole port is not initialized if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: duplex changed for uninitialized port on %s\n", - slave->dev->name); + printk(KERN_WARNING DRV_NAME ": %s: Warning: duplex changed " + "for uninitialized port on %s\n", + slave->dev->master->name, slave->dev->name); return; } @@ -2287,8 +2300,9 @@ // if slave is null, the whole port is not initialized if (!port->slave) { - printk(KERN_WARNING DRV_NAME ": Warning: link status changed for uninitialized port on %s\n", - slave->dev->name); + printk(KERN_WARNING DRV_NAME ": Warning: %s: link status changed for " + "uninitialized port on %s\n", + slave->dev->master->name, slave->dev->name); return; } @@ -2396,7 +2410,8 @@ } if (slave_agg_no >= 0) { - printk(KERN_ERR DRV_NAME ": Error: Couldn't find a slave to tx on for aggregator ID %d\n", agg_id); + printk(KERN_ERR DRV_NAME ": %s: Error: Couldn't find a slave to tx on " + "for aggregator ID %d\n", dev->name, agg_id); goto out; } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c 2005-04-07 13:57:29.000000000 -0700 @@ -515,7 +515,8 @@ client_info->mac_dst); if (!skb) { printk(KERN_ERR DRV_NAME - ": Error: failed to create an ARP packet\n"); + ": %s: Error: failed to create an ARP packet\n", + client_info->slave->dev->master->name); continue; } @@ -525,7 +526,8 @@ skb = vlan_put_tag(skb, client_info->vlan_id); if (!skb) { printk(KERN_ERR DRV_NAME - ": Error: failed to insert VLAN tag\n"); + ": %s: Error: failed to insert VLAN tag\n", + client_info->slave->dev->master->name); continue; } } @@ -608,8 +610,9 @@ if (!client_info->slave) { printk(KERN_ERR DRV_NAME - ": Error: found a client with no channel in " - "the client's hash table\n"); + ": %s: Error: found a client with no channel in " + "the client's hash table\n", + bond->dev->name); continue; } /*update all clients using this src_ip, that are not assigned @@ -930,7 +933,8 @@ skb = vlan_put_tag(skb, vlan->vlan_id); if (!skb) { printk(KERN_ERR DRV_NAME - ": Error: failed to insert VLAN tag\n"); + ": %s: Error: failed to insert VLAN tag\n", + bond->dev->name); continue; } } @@ -959,11 +963,11 @@ s_addr.sa_family = dev->type; if (dev_set_mac_address(dev, &s_addr)) { printk(KERN_ERR DRV_NAME - ": Error: dev_set_mac_address of dev %s failed! ALB " + ": %s: Error: dev_set_mac_address of dev %s failed! ALB " "mode requires that the base driver support setting " "the hw address also when the network device's " "interface is open\n", - dev->name); + dev->master->name, dev->name); return -EOPNOTSUPP; } return 0; @@ -1113,9 +1117,9 @@ * of the new slave */ printk(KERN_ERR DRV_NAME - ": Error: the hw address of slave %s is not " + ": %s: Error: the hw address of slave %s is not " "unique - cannot enslave it!", - slave->dev->name); + bond->dev->name, slave->dev->name); return -EINVAL; } @@ -1161,16 +1165,16 @@ bond->alb_info.rlb_enabled); printk(KERN_WARNING DRV_NAME - ": Warning: the hw address of slave %s is in use by " + ": %s: Warning: the hw address of slave %s is in use by " "the bond; giving it the hw address of %s\n", - slave->dev->name, free_mac_slave->dev->name); + bond->dev->name, slave->dev->name, free_mac_slave->dev->name); } else if (has_bond_addr) { printk(KERN_ERR DRV_NAME - ": Error: the hw address of slave %s is in use by the " + ": %s: Error: the hw address of slave %s is in use by the " "bond; couldn't find a slave with a free hw address to " "give it (this should not have happened)\n", - slave->dev->name); + bond->dev->name, slave->dev->name); return -EFAULT; } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -1592,8 +1592,8 @@ if (slave_dev->do_ioctl == NULL) { printk(KERN_WARNING DRV_NAME - ": Warning : no link monitoring support for %s\n", - slave_dev->name); + ": %s: Warning: no link monitoring support for %s\n", + bond_dev->name, slave_dev->name); } /* bond must be initialized by bond_open() before enslaving */ @@ -1614,17 +1614,17 @@ dprintk("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name); if (!list_empty(&bond->vlan_list)) { printk(KERN_ERR DRV_NAME - ": Error: cannot enslave VLAN " + ": %s: Error: cannot enslave VLAN " "challenged slave %s on VLAN enabled " - "bond %s\n", slave_dev->name, + "bond %s\n", bond_dev->name, slave_dev->name, bond_dev->name); return -EPERM; } else { printk(KERN_WARNING DRV_NAME - ": Warning: enslaved VLAN challenged " + ": %s: Warning: enslaved VLAN challenged " "slave %s. Adding VLANs will be blocked as " "long as %s is part of bond %s\n", - slave_dev->name, slave_dev->name, + bond_dev->name, slave_dev->name, slave_dev->name, bond_dev->name); bond_dev->features |= NETIF_F_VLAN_CHALLENGED; } @@ -1644,8 +1694,8 @@ */ if ((slave_dev->flags & IFF_UP)) { printk(KERN_ERR DRV_NAME - ": Error: %s is up\n", - slave_dev->name); + ": %s: Error: %s is up\n", + bond_dev->name, slave_dev->name); res = -EPERM; goto err_undo_flags; } @@ -1667,8 +1667,8 @@ */ if (!(slave_dev->flags & IFF_UP)) { printk(KERN_ERR DRV_NAME - ": Error: %s is not running\n", - slave_dev->name); + ": %s: Error: %s is not running\n", + bond_dev->name, slave_dev->name); res = -EINVAL; goto err_undo_flags; } @@ -1677,9 +1677,9 @@ (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 " + ": %s: Error: to use %s mode, you must upgrade " "ifenslave.\n", - bond_mode_name(bond->params.mode)); + bond_dev->name, bond_mode_name(bond->params.mode)); res = -EOPNOTSUPP; goto err_undo_flags; } @@ -1800,21 +1800,21 @@ * the messages for netif_carrier. */ printk(KERN_WARNING DRV_NAME - ": Warning: MII and ETHTOOL support not " + ": %s: Warning: MII and ETHTOOL support not " "available for interface %s, and " "arp_interval/arp_ip_target module parameters " "not specified, thus bonding will not detect " "link failures! see bonding.txt for details.\n", - slave_dev->name); + bond_dev->name, slave_dev->name); } else if (link_reporting == -1) { /* unable get link status using mii/ethtool */ printk(KERN_WARNING DRV_NAME - ": Warning: can't get link status from " + ": %s: Warning: can't get link status from " "interface %s; the network driver associated " "with this interface does not support MII or " "ETHTOOL link status reporting, thus miimon " "has no effect on this interface.\n", - slave_dev->name); + bond_dev->name, slave_dev->name); } } @@ -1841,9 +1890,9 @@ if (bond_update_speed_duplex(new_slave) && (new_slave->link != BOND_LINK_DOWN)) { printk(KERN_WARNING DRV_NAME - ": Warning: failed to get speed and duplex from %s, " + ": %s: Warning: failed to get speed and duplex from %s, " "assumed to be 100Mb/sec and Full.\n", - new_slave->dev->name); + bond_dev->name, new_slave->dev->name); if (bond->params.mode == BOND_MODE_8023AD) { printk(KERN_WARNING DRV_NAME @@ -2042,11 +2042,12 @@ ETH_ALEN); if (!mac_addr_differ && (bond->slave_cnt > 1)) { printk(KERN_WARNING DRV_NAME - ": Warning: the permanent HWaddr of %s " + ": %s: Warning: the permanent HWaddr of %s " "- %02X:%02X:%02X:%02X:%02X:%02X - is " "still in use by %s. Set the HWaddr of " "%s to a different address to avoid " "conflicts.\n", + bond_dev->name, slave_dev->name, slave->perm_hwaddr[0], slave->perm_hwaddr[1], @@ -2120,19 +2164,20 @@ bond_dev->features |= NETIF_F_VLAN_CHALLENGED; } else { printk(KERN_WARNING DRV_NAME - ": Warning: clearing HW address of %s while it " + ": %s: Warning: clearing HW address of %s while it " "still has VLANs.\n", - bond_dev->name); + bond_dev->name, bond_dev->name); printk(KERN_WARNING DRV_NAME - ": When re-adding slaves, make sure the bond's " - "HW address matches its VLANs'.\n"); + ": %s: When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n", + bond_dev->name); } } else if ((bond_dev->features & NETIF_F_VLAN_CHALLENGED) && !bond_has_challenged_slaves(bond)) { printk(KERN_INFO DRV_NAME - ": last VLAN challenged slave %s " + ": %s: last VLAN challenged slave %s " "left bond %s. VLAN blocking is removed\n", - slave_dev->name, bond_dev->name); + bond_dev->name, slave_dev->name, bond_dev->name); bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED; } @@ -2232,6 +2234,7 @@ */ write_unlock_bh(&bond->lock); + bond_destroy_slave_symlinks(bond_dev, slave_dev); bond_del_vlans_from_slave(bond, slave_dev); /* If the mode USES_PRIMARY, then we should only remove its @@ -2288,12 +2291,13 @@ bond_dev->features |= NETIF_F_VLAN_CHALLENGED; } else { printk(KERN_WARNING DRV_NAME - ": Warning: clearing HW address of %s while it " + ": %s: Warning: clearing HW address of %s while it " "still has VLANs.\n", - bond_dev->name); + bond_dev->name, bond_dev->name); printk(KERN_WARNING DRV_NAME - ": When re-adding slaves, make sure the bond's " - "HW address matches its VLANs'.\n"); + ": %s: When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n", + bond_dev->name); } printk(KERN_INFO DRV_NAME @@ -2385,8 +2389,9 @@ &endptr, 0); if (*endptr) { printk(KERN_ERR DRV_NAME - ": Error: got invalid ABI " - "version from application\n"); + ": %s: Error: got invalid ABI " + "version from application\n", + bond_dev->name); return -EINVAL; } @@ -4207,8 +4212,9 @@ struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC); if (!skb2) { printk(KERN_ERR DRV_NAME - ": Error: bond_xmit_broadcast(): " - "skb_clone() failed\n"); + ": %s: Error: bond_xmit_broadcast(): " + "skb_clone() failed\n", + bond_dev->name); continue; } @@ -4267,7 +4273,8 @@ default: /* Should never happen, mode already checked */ printk(KERN_ERR DRV_NAME - ": Error: Unknown bonding mode %d\n", + ": %s: Error: Unknown bonding mode %d\n", + bond_dev->name, mode); break; } From radheka.godse@intel.com Thu Apr 7 17:05:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:05:05 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3804xLv017346 for ; Thu, 7 Apr 2005 17:05:00 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3804nVa026344; Fri, 8 Apr 2005 00:04:49 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3804nju006601; Fri, 8 Apr 2005 00:04:49 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j3804nSL032146; Thu, 7 Apr 2005 17:04:49 -0700 Date: Fri, 8 Apr 2005 17:04:20 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r13/17] bonding: make error messages more consistent Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 4254 Lines: 101 This patch attempts to make error reporting more consistent, removes/adds newlines as appropriate, adds bonding: : prefix if missing (especially in alb, ad) messages. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_3ad.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_3ad.c 2005-04-07 13:57:28.000000000 -0700 @@ -1198,10 +1198,10 @@ // detect loopback situation if (!MAC_ADDRESS_COMPARE(&(lacpdu->actor_system), &(port->actor_system))) { // INFO_RECEIVED_LOOPBACK_FRAMES - printk(KERN_ERR DRV_NAME ": An illegal loopback occurred on adapter (%s)\n", - port->slave->dev->name); - printk(KERN_ERR "Check the configuration to verify that all Adapters " - "are connected to 802.3ad compliant switch ports\n"); + printk(KERN_ERR DRV_NAME ": %s: An illegal loopback occurred on " + "adapter (%s). Check the configuration to verify that all " + "Adapters are connected to 802.3ad compliant switch ports\n", + port->slave->dev->master->name, port->slave->dev->name); __release_rx_machine_lock(port); return; } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c 2005-04-07 13:57:29.000000000 -0700 @@ -206,7 +206,7 @@ new_hashtbl = kmalloc(size, GFP_KERNEL); if (!new_hashtbl) { printk(KERN_ERR DRV_NAME - ": Error: %s: Failed to allocate TLB hash table\n", + ": %s: Error: Failed to allocate TLB hash table\n", bond->dev->name); return -1; } @@ -811,7 +798,7 @@ new_hashtbl = kmalloc(size, GFP_KERNEL); if (!new_hashtbl) { printk(KERN_ERR DRV_NAME - ": Error: %s: Failed to allocate RLB hash table\n", + ": %s: Error: Failed to allocate RLB hash table\n", bond->dev->name); return -1; } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -891,7 +891,7 @@ res = bond_add_vlan(bond, vid); if (res) { printk(KERN_ERR DRV_NAME - ": %s: Failed to add vlan id %d\n", + ": %s: Error: Failed to add vlan id %d\n", bond_dev->name, vid); } } @@ -925,7 +925,7 @@ res = bond_del_vlan(bond, vid); if (res) { printk(KERN_ERR DRV_NAME - ": %s: Failed to remove vlan id %d\n", + ": %s: Error: Failed to remove vlan id %d\n", bond_dev->name, vid); } } @@ -1652,11 +1694,10 @@ if (slave_dev->set_mac_address == NULL) { printk(KERN_ERR DRV_NAME - ": Error: The slave device you specified does " - "not support setting the MAC address.\n"); - printk(KERN_ERR + ": %s: Error: The slave device you specified does " + "not support setting the MAC address. " "Your kernel likely does not support slave " - "devices.\n"); + "devices.\n", bond_dev->name); res = -EOPNOTSUPP; goto err_undo_flags; @@ -2021,7 +2020,7 @@ if (!(slave_dev->flags & IFF_SLAVE) || (slave_dev->master != bond_dev)) { printk(KERN_ERR DRV_NAME - ": Error: %s: cannot release %s.\n", + ": %s: Error: cannot release %s.\n", bond_dev->name, slave_dev->name); return -EINVAL; } @@ -4441,7 +4440,7 @@ if (max_bonds < 1 || max_bonds > INT_MAX) { printk(KERN_WARNING DRV_NAME ": Warning: max_bonds (%d) not in range %d-%d, so it " - "was reset to BOND_DEFAULT_MAX_BONDS (%d)", + "was reset to BOND_DEFAULT_MAX_BONDS (%d)\n", max_bonds, 1, INT_MAX, BOND_DEFAULT_MAX_BONDS); max_bonds = BOND_DEFAULT_MAX_BONDS; } From radheka.godse@intel.com Thu Apr 7 17:07:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:07:43 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3807cgu018213 for ; Thu, 7 Apr 2005 17:07:38 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3807QwZ015074; Fri, 8 Apr 2005 00:07:26 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3807QRZ000963; Fri, 8 Apr 2005 00:07:26 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j3807QSL032376; Thu, 7 Apr 2005 17:07:26 -0700 Date: Fri, 8 Apr 2005 17:06:58 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r14/17] bonding: spelling and whitespace correction Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 3105 Lines: 93 Trivial patch to fix spelling errors and some white spaces changes for readabilitiy. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_alb.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_alb.c 2005-04-07 13:57:29.000000000 -0700 @@ -1424,7 +1424,7 @@ read_lock(&bond->curr_slave_lock); bond_for_each_slave(bond, slave, i) { - alb_send_learning_packets(slave,slave->dev->dev_addr); + alb_send_learning_packets(slave, slave->dev->dev_addr); } read_unlock(&bond->curr_slave_lock); diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -159,7 +159,7 @@ }; struct slave { - struct net_device *dev; /* first - usefull for panic debug */ + struct net_device *dev; /* first - useful for panic debug */ struct slave *next; struct slave *prev; s16 delay; @@ -185,7 +185,7 @@ * beforehand. */ struct bonding { - struct net_device *dev; /* first - usefull for panic debug */ + struct net_device *dev; /* first - useful for panic debug */ struct slave *first_slave; struct slave *curr_active_slave; struct slave *current_arp_slave; diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -2079,7 +2079,6 @@ /* release the slave from its bond */ bond_detach_slave(bond, slave); - if (bond->primary_slave == slave) { bond->primary_slave = NULL; } @@ -2398,7 +2397,6 @@ if (orig_app_abi_ver == -1) { orig_app_abi_ver = new_abi_ver; } - app_abi_ver = new_abi_ver; } @@ -3926,6 +3924,7 @@ bond_for_each_slave(bond, slave, i) { dprintk("s %p s->p %p c_m %p\n", slave, slave->prev, slave->dev->change_mtu); + res = dev_set_mtu(slave->dev, new_mtu); if (res) { @@ -4325,7 +4324,7 @@ */ bond_dev->features |= NETIF_F_VLAN_CHALLENGED; - /* don't acquire bond device's xmit_lock when + /* don't acquire bond device's xmit_lock when * transmitting */ bond_dev->features |= NETIF_F_LLTX; @@ -4718,7 +4685,6 @@ #ifdef CONFIG_PROC_FS bond_create_proc_dir(); #endif - for (i = 0; i < max_bonds; i++) { sprintf(new_bond_name, "bond%d",i); res = bond_create(new_bond_name,&bonding_defaults, NULL); @@ -4746,7 +4685,6 @@ static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); - rtnl_lock(); bond_free_all(); bond_destroy_sysfs(); From shemminger@osdl.org Thu Apr 7 17:09:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:09:49 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3809igU018820 for ; Thu, 7 Apr 2005 17:09:44 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3809Xs4021606 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Apr 2005 17:09:34 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j3809YtL001127; Thu, 7 Apr 2005 17:09:34 -0700 Date: Thu, 7 Apr 2005 17:09:34 -0700 From: Stephen Hemminger To: Radheka Godse Cc: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2 0/17] bonding: sysfs interface... Message-ID: <20050407170934.5ca77ab5@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1569 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: 4023 Lines: 106 On Fri, 8 Apr 2005 16:15:24 -0700 (PDT) Radheka Godse wrote: > > This patch set implements the sysfs interface for bonding and has a couple > bug fixes. We have done a full test pass and consider these patches ready for > inclusion upstream. We have submitted them to bonding-devel several > times and have incorporated feedback and fixes all known issues. > > The interface is pretty simple. Here are some notes on how it could be > used: > > The file /sys/class/net/bonding_masters contains the names of all the > active bonds. To add or remove bonds, write a whitespace-delimited list of > interface names to this file. For example: > echo "bond1 bond2 bond3" > /sys/class/net/bonding_masters > will create three bonds with the given names. If any other > bonds exist, they will be deleted. > echo "bond0 bond2 bond3" > /sys/class/net/bonding_masters > would then create bond0 and remove bond1. > > For each bond, there is a directory /sys/class/net//bonding. > In this directory are a number of files which control the bond. The names > of these files match the existing module parameters and do the same things. > > The slaves file contains a whitespace-delimited list of interface names, > which are slaves to the bond. This file behaves much the same as the > "bonding_masters" file; just write a list of your desired interfaces to > this file. > > Likewise, the arp_targets file contains a whitespace-delimited list of IP > addresses and should be written to in a similar fashion. > > The other files contain single values(numeric and/or mnemonic), except > for stat, which duplicates the slave information in the proc file. > > Some caveats: > - slaves can only be assigned when the interface is up > - mode can only be changed when the interface is down > > Warnings and status messages will be logged and can be viewed with dmesg. > > Example: > modprobe bonding > echo "bond0 bond1" > /sys/class/net/bonding_masters > echo "6" > /sys/class/net/bond0/bonding/mode > echo "1000" > /sys/class/net/bond0/bonding/miimon > ifconfig bond0 192.168.0.1 > echo "eth0 eth1" > /sys/class/net/bond0/bonding/slaves > # bond0 is now ready to use > echo "1" > /sys/class/net/bond1/bonding/mode > # ... and so on for bond1 > > > These patches apply cleanly to kernel 2.6.12-rc2. > > - Mitch Williams > - Radheka Godse I'm not adverse to sysfs per say, but you are using like /proc with multiple values per file. This is not what the original design was. Examples: +static ssize_t bonding_show_stat(struct class_device *cd, char *buf) +{ + struct slave *curr; + int i, len = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, curr, i) { + len += sprintf(buf + len, "\nSlave Interface: %s\n", + curr->dev->name); + len += sprintf(buf + len, "MII Status: %s\n", + (curr->link == BOND_LINK_UP) ? "up" : "down"); + len += sprintf(buf + len, "Link Failure Count: %d\n", + curr->link_failure_count); + + len += sprintf(buf + len, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + curr->perm_hwaddr[0], curr->perm_hwaddr[1], + curr->perm_hwaddr[2], curr->perm_hwaddr[3], + curr->perm_hwaddr[4], curr->perm_hwaddr[5]); + + if (bond->params.mode == BOND_MODE_8023AD) { + const struct aggregator *agg = + SLAVE_AD_INFO(curr).port.aggregator; + + if (agg) { + len += sprintf(buf + len, "Aggregator ID: %d\n", + agg->aggregator_identifier); + } else { + len += sprintf(buf + len, + "Aggregator ID: N/A\n"); + } + } You need to break this up into symlinks and individual files with single value. Look at bridging as an example. Also: how do you intend to use the ABI version exported? Unless you have a clear plan, it is frowned upon to drop random version numbers around hoping to be able to have compatibility. From radheka.godse@intel.com Thu Apr 7 17:11:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:11:15 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j380B9kY019237 for ; Thu, 7 Apr 2005 17:11:09 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j380AwQe027189; Fri, 8 Apr 2005 00:10:58 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j380AwRZ003324; Fri, 8 Apr 2005 00:10:58 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j380AwSL032594; Thu, 7 Apr 2005 17:10:58 -0700 Date: Fri, 8 Apr 2005 17:10:30 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r15/17] bonding: include ARP information in /proc file Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 1531 Lines: 46 For bonds configured to do ARP monitoring, this patch displays polling interval and ip targets info in their respective proc files. This information was missing in the proc file. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -3167,6 +3167,8 @@ { struct bonding *bond = seq->private; struct slave *curr; + int i; + u32 target; read_lock(&bond->curr_slave_lock); curr = bond->curr_active_slave; @@ -3191,6 +3193,24 @@ seq_printf(seq, "Down Delay (ms): %d\n", bond->params.downdelay * bond->params.miimon); + + // ARP information + if(bond->params.arp_interval > 0) { + seq_printf(seq, "ARP Polling Interval (ms): %d\n", + bond->params.arp_interval); + + seq_printf(seq, "ARP IP target/s (n.n.n.n form):"); + + for(i = 0; (i < BOND_MAX_ARP_TARGETS) && bond->params.arp_targets[i] ;i++) { + target = ntohl(bond->params.arp_targets[i]); + seq_printf(seq, " %d.%d.%d.%d", HIPQUAD(target)); + if((i+1 < BOND_MAX_ARP_TARGETS) && bond->params.arp_targets[i+1]) + seq_printf(seq, ","); + else + seq_printf(seq, "\n"); + } + } + if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; From radheka.godse@intel.com Thu Apr 7 17:13:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:13:25 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j380DKnE019993 for ; Thu, 7 Apr 2005 17:13:20 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j380D8wZ017399; Fri, 8 Apr 2005 00:13:09 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j380D8ju011821; Fri, 8 Apr 2005 00:13:08 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j380D8SL032726; Thu, 7 Apr 2005 17:13:08 -0700 Date: Fri, 8 Apr 2005 17:12:40 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r16/17] bonding: version, date and log update Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 4177 Lines: 84 This patch updates the bonding version number and adds entries to the change log in bond_main. The major version number is changed to 3 because of the sysfs interface. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bonding.h 2005-04-07 14:05:31.000000000 -0700 @@ -37,8 +37,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.6.1" -#define DRV_RELDATE "October 29, 2004" +#define DRV_VERSION "3.1.5" +#define DRV_RELDATE "April 6, 2005" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -475,6 +475,57 @@ * Solution is to move call to dev_remove_pack outside of the * spinlock. * Set version to 2.6.1. + * 2004/12/14 - Mitch Williams + * - Split out bond creation code to allow for future addition of + * sysfs interface. + * - Added extra optional parameter to bond_enslave to return a + * a pointer to the new slave. This will be used by future + * sysfs functionality. + * - Removed static declaration on some functions and data items. + * Set version to 2.6.3 + * 2005/02/10 - Mitch Williams + * - Added sysfs support, including capability to add/remove/change + * any bond at runtime. + * Set version to 3.0.5 + * 2005/02/18 - Radheka Godse + * - Corrected bugs in bond_check_abi_version so sys fs interface can + * be used simultaneously with ifenslave version 1 and above + * Set version to 3.0.7 + * 2005/02/23 - Mitch Williams + * - fixed sysfs bug where the primary could not be cleared + * - ioctls call now grab the sysfs semaphore to prevent race + * conditions if both ifenslave and sysfs are being used + * Set version to 3.0.8 + * 2005/03/18 - Radheka Godse + * - added ifenslave -c type functionality to sysfs + * - split sysfs stat into separate files for attribs such as + * MII Status and 802.3ad aggregator values to sysfs + * - added "name value" format to sysfs "mode" and + * "lacp_rate", for e.g., "active-backup 1" or "slow 0" for + * consistency and ease of script parsing + * - fixed reversal of octets in arp_ip_targets via sysfs + * - added bonding: : prefix to sysfs log messages + * - sysfs support to handle bond interface re-naming + * - Added log messages to reflect/notify changes in updelay and + * downdelay values due to changes to miimon configuration + * - added arp_ip_targets to /proc entry + * - trivial fix: added missing modes description to modinfo + * - made "my_ip" a per bond value instead of a global + * Set version to 3.0.9 + * 2005/03/23 - Mitch Williams + * - Moved all sysfs entries into /sys/class/net instead of + * of using a standalone subsystem. + * - Added sysfs symlinks between masters and slaves + * - Corrected bug in ALB init where kmalloc is called inside + * a held lock + * Set version to 3.1.0 + * 2005/04/01 - Radheka Godse + * - Corrected behaviour to maintain bond link when changing + * from arp monitor to miimon and vice versa + * - Corrected bugs in sysfs unload path when creating bonds + * with existing interface names. + * - Added missing bonding: : prefix to alb, ad log messages + * Set version to 3.1.5 * */ From radheka.godse@intel.com Thu Apr 7 17:15:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:15:41 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j380FaPt020611 for ; Thu, 7 Apr 2005 17:15:37 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j380FQ6x020348; Fri, 8 Apr 2005 00:15:26 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j380FQju013322; Fri, 8 Apr 2005 00:15:26 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j380FQSL000374; Thu, 7 Apr 2005 17:15:26 -0700 Date: Fri, 8 Apr 2005 17:14:57 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6.12-rc2 r17/17] bonding: dprintks Message-ID: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 697 Lines: 16 Really trivial dprintk to know when last slave leaves the bond. Signed-off-by: Radheka Godse diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2/drivers/net/bonding/bond_main.c 2005-04-07 14:35:41.000000000 -0700 @@ -2160,6 +2160,7 @@ } if (bond->slave_cnt == 0) { + dprintk("last slave removed\n"); /* 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 From fubar@us.ibm.com Thu Apr 7 17:41:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:41:38 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j380fPDL021753 for ; Thu, 7 Apr 2005 17:41:32 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j380fK5j586204 for ; Thu, 7 Apr 2005 20:41:20 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j380fJKk194760 for ; Thu, 7 Apr 2005 18:41:19 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j380fJC5021435 for ; Thu, 7 Apr 2005 18:41:19 -0600 Received: from death.nxdomain.ibm.com (sig-9-49-129-6.mts.ibm.com [9.49.129.6]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j380fIoo021413; Thu, 7 Apr 2005 18:41:18 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j380fGNn004910; Thu, 7 Apr 2005 17:41:16 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j380fFAM004902; Thu, 7 Apr 2005 17:41:15 -0700 Message-Id: <200504080041.j380fFAM004902@death.nxdomain.ibm.com> To: Stephen Hemminger cc: Radheka Godse , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2 0/17] bonding: sysfs interface... In-Reply-To: Message from Stephen Hemminger of "Thu, 07 Apr 2005 17:09:34 PDT." <20050407170934.5ca77ab5@dxpl.pdx.osdl.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 17:41:15 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 986 Lines: 38 Stephen Hemminger wrote: [...] >Also: how do you intend to use the ABI version exported? Unless you have a clear >plan, it is frowned upon to drop random version numbers around hoping to be able >to have compatibility. If by "ABI version exported," you're referring to this (and the associated calls): +int bond_check_abi_ver(void) +{ + int retval = 1; + + if (orig_app_abi_ver == -1) { + orig_app_abi_ver = BOND_ABI_VERSION; + app_abi_ver = BOND_ABI_VERSION; + } + else { + if (app_abi_ver == 0) + retval = 0; + } + + return retval; +} + This enforces the already existing ABI version control stuff in bonding (which deals with different versions of the ifenslave control program). This should preserve the existing ifenslave (ioctl based) ABI. I've only skimmed the patch, so I haven't tested it out as yet, but at first glance it looks ok. Or did you mean something else? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From hadi@cyberus.ca Thu Apr 7 17:48:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 17:48:36 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j380mWPi022386 for ; Thu, 7 Apr 2005 17:48:32 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DJhfc-0006SN-9o for netdev@oss.sgi.com; Thu, 07 Apr 2005 18:48:24 -0600 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 1DJhfd-0002en-2P; Thu, 07 Apr 2005 20:48:25 -0400 Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , "David S. Miller" , netdev In-Reply-To: <20050407232427.GY26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> <20050407223847.GX26731@postel.suug.ch> <1112915616.1089.27.camel@jzny.localdomain> <20050407232427.GY26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112921300.1088.54.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 20:48:20 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1574 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: 1408 Lines: 40 On Thu, 2005-04-07 at 19:24, Thomas Graf wrote: > * jamal <1112915616.1089.27.camel@jzny.localdomain> 2005-04-07 19:13 > > On Thu, 2005-04-07 at 18:38, Thomas Graf wrote: > > > - [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info } > > > + [RTM_GETNEIGH - RTM_BASE] = { .dumpit = neigh_dump_info }, > > > + [RTM_GETRULE - RTM_BASE] = { .dumpit = rtnetlink_dump_all }, > > > }; > > > > > > > Shouldnt this just work (without this change) if you have > > CONFIG_IP_MULTIPLE_TABLES? > > Not sure what you mean, it doesn't even get into the routing > code but already fails in rtnetlink_rcv_msg when it doesn't > find a dumpit implementation for family == AF_UNSPEC. > Right but if CONFIG_IP_MULTIPLE_TABLES is compiled it will find it in family = PF_INET, no? In the minimal shouldnt you have #ifdef CONFIG_IP_MULTIPLE_TABLES around that defined? > That is exactly what happens, it will first look up the address > family dumpit and if none exist falls back to the rtnetlink_dump_all > introduced above. > > if (link->dumpit == NULL) > link = &(rtnetlink_links[PF_UNSPEC][type]); > > if (link->dumpit == NULL) > goto err_inval; /* <-- we used to fail here for PF_UNSPEC */ > > if ((*errp = netlink_dump_start(rtnl, skb, nlh, ... I mean why dont you just set it there in that last part where it currently fails? i.e set link->dumpit to rtnetlink_dump_all cheers, jamal From tgraf@suug.ch Thu Apr 7 18:03:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 18:03:54 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3813mqU023155 for ; Thu, 7 Apr 2005 18:03:48 -0700 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7A9DC8D; Fri, 8 Apr 2005 03:03:24 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id CEA0B1C0EA; Fri, 8 Apr 2005 03:04:06 +0200 (CEST) Date: Fri, 8 Apr 2005 03:04:06 +0200 From: Thomas Graf To: jamal Cc: Herbert Xu , "David S. Miller" , netdev Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules Message-ID: <20050408010406.GZ26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> <20050407223847.GX26731@postel.suug.ch> <1112915616.1089.27.camel@jzny.localdomain> <20050407232427.GY26731@postel.suug.ch> <1112921300.1088.54.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112921300.1088.54.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 973 Lines: 21 * jamal <1112921300.1088.54.camel@jzny.localdomain> 2005-04-07 20:48 > Right but if CONFIG_IP_MULTIPLE_TABLES is compiled it will find it in > family = PF_INET, no? Yes if rtgenmsg->rtgen_family is set to PF_IPV4. What I'm trying to achieve is that if the user specifies PF_UNSPEC that it will look through all families looking for possible rules to dump, ... > In the minimal shouldnt you have #ifdef CONFIG_IP_MULTIPLE_TABLES around > that defined? ... this may include rule systems that do not depend on CONFIG_IP_MULTIPLE_TABLES, e.g. IPv6 is likely to get an own config option for this. Or someday we might have DECnet rules? I don't know. > I mean why dont you just set it there in that last part where it > currently fails? i.e set link->dumpit to rtnetlink_dump_all Because that would interefer with the RTM_GETLINK and RTM_GETNEIGH. We need that link_rtnetlink_table which is then mapped to PF_UNSPEC and PF_PACKET protocol family for the wildcard support. From hadi@cyberus.ca Thu Apr 7 18:11:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 18:11:34 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j381BTm9023913 for ; Thu, 7 Apr 2005 18:11:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJi1x-00085w-Ru for netdev@oss.sgi.com; Thu, 07 Apr 2005 21:11:29 -0400 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 1DJi1v-000568-8s; Thu, 07 Apr 2005 21:11:27 -0400 Subject: Re: [PATCH] RTNETLINK: Protocol family wildcard dumping for routing rules From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , "David S. Miller" , netdev In-Reply-To: <20050408010406.GZ26731@postel.suug.ch> References: <20050407213838.GW26731@postel.suug.ch> <20050407223847.GX26731@postel.suug.ch> <1112915616.1089.27.camel@jzny.localdomain> <20050407232427.GY26731@postel.suug.ch> <1112921300.1088.54.camel@jzny.localdomain> <20050408010406.GZ26731@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112922682.1088.62.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2005 21:11:22 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1576 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: 453 Lines: 17 On Thu, 2005-04-07 at 21:04, Thomas Graf wrote: > ... this may include rule systems that do not depend on > CONFIG_IP_MULTIPLE_TABLES, e.g. IPv6 is likely to get an own config option > for this. Or someday we might have DECnet rules? I don't know. > Ok, fair enough. BTW Decnet already has it for family PF_DECnet ;-> [I dont think there has existed a decnet as sophisticated as the one we have - too bad its not used that much]. cheers, jamal From ayyappan.veeraiyan@intel.com Thu Apr 7 18:15:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 18:15:35 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j381FV3Q024514 for ; Thu, 7 Apr 2005 18:15:31 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j381FB0f031985; Fri, 8 Apr 2005 01:15:11 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j381F336026983; Fri, 8 Apr 2005 01:15:11 GMT Received: from muhil.jf.intel.com ([10.23.35.119]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005040718150829644 ; Thu, 07 Apr 2005 18:15:08 -0700 Date: Thu, 7 Apr 2005 18:15:09 -0700 (PDT) From: Ayyappan Veeraiyan To: Harald Welte cc: "Veeraiyan, Ayyappan" , Robert Olsson , Subject: Re: pktgen problem (skb refcount) in 2.6.12-rc1 In-Reply-To: <20050405155820.GB3261@obroa-skai.de.gnumonks.org> Message-ID: ReplyTo: "Ayyappan Veeraiyan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ayyappan.veeraiyan@intel.com Precedence: bulk X-list: netdev Content-Length: 1206 Lines: 40 On Tue, 5 Apr 2005, Harald Welte wrote: > > I have tried a 2.6.11 kernel which works fine. I have not tested > patching e1000 in 2.6.12-rc1 to go back to whatever was shipped in > 2.6.11. > > I'll try to remember testing that once I'm back from my current business > trip (friday), though > I think one of the previos set of e1000 patches is the cause for this issue. TSO workaround we put in doesn't release the last TX packet skb if there are no more receives on the interface. Could you please try the below patch to 2.6.12-rc1? Apologies if the patch doesn't apply cleanly. thanks, Ayyappan V. --- linux-2.6.11.6/drivers/net/e1000/e1000_main.c.fix1 2005-04-04 22:08:13.026941064 -0700 +++ linux-2.6.11.6/drivers/net/e1000/e1000_main.c 2005-04-04 22:07:18.775188584 -0700 @@ -2426,6 +2426,14 @@ !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) netif_stop_queue(netdev); } +#ifdef NETIF_F_TSO + + if( unlikely(!(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) && + time_after(jiffies, adapter->previous_buffer_info.time_stamp + HZ))) + e1000_unmap_and_free_tx_resource( + adapter, &adapter->previous_buffer_info); + +#endif return cleaned; } From jgarzik@pobox.com Thu Apr 7 20:50:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 20:50:29 -0700 (PDT) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j383oItE002547 for ; Thu, 7 Apr 2005 20:50:19 -0700 Received: from cpe-024-025-022-197.nc.res.rr.com ([24.25.22.197] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DJkVc-0001Vd-8P; Fri, 08 Apr 2005 04:50:16 +0100 Message-ID: <4255FF69.4090208@pobox.com> Date: Thu, 07 Apr 2005 23:50:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jay Vosburgh CC: netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address References: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> In-Reply-To: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Warning: 24.25.22.197 is listed at orbz.gst-group.uk.com X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1578 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: 648 Lines: 20 Jay Vosburgh wrote: > This patch backs out some of the calls to dev_set_mac_address > and replaces them with calls to a similar function that does not call > notifier_call_chain. > > The reason for this is that the rtnetlink event handler and its > descendents make GFP_KERNEL memory allocation requests, and the bonding > driver makes some of its MAC address change calls from timer context > with a lock held (notably the ALB mode). > > Rearranging the bonding driver to not call this way is a fairly > involved change; this patch merely reverts one part of bonding to the > way it used to be. Do I need to forward this for -rc3? Jeff From davem@davemloft.net Thu Apr 7 21:50:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 21:50:49 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j384oeXB004598 for ; Thu, 7 Apr 2005 21:50:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DJlMr-00088L-00; Thu, 07 Apr 2005 21:45:17 -0700 Date: Thu, 7 Apr 2005 21:45:17 -0700 From: "David S. Miller" To: Jeff Garzik Cc: fubar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-Id: <20050407214517.0d50703d.davem@davemloft.net> In-Reply-To: <4255FF69.4090208@pobox.com> References: <200504071959.j37JxZ8g003626@death.nxdomain.ibm.com> <4255FF69.4090208@pobox.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 829 Lines: 21 On Thu, 07 Apr 2005 23:50:01 -0400 Jeff Garzik wrote: > Jay Vosburgh wrote: > > This patch backs out some of the calls to dev_set_mac_address > > and replaces them with calls to a similar function that does not call > > notifier_call_chain. > > > > The reason for this is that the rtnetlink event handler and its > > descendents make GFP_KERNEL memory allocation requests, and the bonding > > driver makes some of its MAC address change calls from timer context > > with a lock held (notably the ALB mode). > > > > Rearranging the bonding driver to not call this way is a fairly > > involved change; this patch merely reverts one part of bonding to the > > way it used to be. > > Do I need to forward this for -rc3? No, read the rest of the thread, we're discussing an alternative version of the fix. From christoph@graphe.net Thu Apr 7 22:45:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 22:45:49 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j385jgCU007335 for ; Thu, 7 Apr 2005 22:45:42 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJmIg-00031q-Pe; Thu, 07 Apr 2005 22:45:06 -0700 Date: Thu, 7 Apr 2005 22:45:02 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050407212504.GA4939@gondor.apana.org.au> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 2722 Lines: 87 On Fri, 8 Apr 2005, Herbert Xu wrote: > I never said that it is better to treat them differently. I wrote > it like this earlier because I still had atomic_dec_and_test. > > > if ((dst->flags & DST_NOHASH)) { > > /* dst not on hash and also not on gc list */ > > atomic_dec(&dst->__refcnt); > > if (!atomic_read(&dst->refcnt)) > > /* We were the only reference kill child */ > > goto again; > > /* return child to put it on the gc list */ > > return dst; > > } > > BTW this patch is missing a barrier. That was just some C code to explain what I meant. Here is a patch against 2.6.12-rc2 with explanations as to what exactly is going on with __refcnt so that we can avoid future confusion about this piece of code. It removes the atomic_dec_and_test like the initial patch. I hope this is acceptable now. Signed-off-by: Christoph Lameter Index: linux-2.6.11/net/core/dst.c =================================================================== --- linux-2.6.11.orig/net/core/dst.c 2005-03-01 23:38:12.000000000 -0800 +++ linux-2.6.11/net/core/dst.c 2005-04-07 22:39:09.000000000 -0700 @@ -191,23 +191,47 @@ again: dst->ops->destroy(dst); if (dst->dev) dev_put(dst->dev); -#if RT_CACHE_DEBUG >= 2 +#if RT_CACHE_DEBUG >= 2 atomic_dec(&dst_total); #endif kmem_cache_free(dst->ops->kmem_cachep, dst); dst = child; if (dst) { - if (atomic_dec_and_test(&dst->__refcnt)) { - /* We were real parent of this dst, so kill child. */ - if (dst->flags&DST_NOHASH) + /* + * Note that the check for NO_HASH must be done before + * decrementing the __refcnt. If __refcnt reaches zero + * then the dst entry may be freed immediately by the gc + * running on another cpu. Therefore no field of the dst + * entry may be accessed after decrementing __refcnt + */ + if (dst->flags&DST_NOHASH) { + /* + * The child is not on a hash table or on the gc list. + * We are the owner and are the only ones who could + * free the dst. There is no possibility of racing + * with the gc code. + */ + atomic_dec(&dst->__refcnt); + smp_mb__after_atomic_dec(); + if (!atomic_read(&dst->__refcnt)) + /* + * There are no other references and therefore + * the dst can be freed now + */ goto again; - } else { - /* Child is still referenced, return it for freeing. */ - if (dst->flags&DST_NOHASH) - return dst; - /* Child is still in his hash table */ + + /* + * Child is still referenced and will be put on the gc + * list by the function invoking dst_destroy. + */ + return dst; } + + /* + * Child is on the hash table. Just decrement the use counter. + */ + atomic_dec(&dst->__refcnt); } return NULL; } From herbert@gondor.apana.org.au Thu Apr 7 22:49:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Apr 2005 22:49:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j385nPso012085 for ; Thu, 7 Apr 2005 22:49:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJmMe-0001Cd-00; Fri, 08 Apr 2005 15:49:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJmM3-00009d-00; Fri, 08 Apr 2005 15:48:31 +1000 Date: Fri, 8 Apr 2005 15:48:31 +1000 To: Christoph Lameter Cc: "David S. Miller" , netdev@oss.sgi.com, pravins@calsoftinc.com, shai@scalesx86.org Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: <20050408054831.GA569@gondor.apana.org.au> References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 618 Lines: 20 On Thu, Apr 07, 2005 at 10:45:02PM -0700, Christoph Lameter wrote: > > + atomic_dec(&dst->__refcnt); > + smp_mb__after_atomic_dec(); > + if (!atomic_read(&dst->__refcnt)) > + /* > + * There are no other references and therefore > + * the dst can be freed now > + */ > goto again; This is wrong. The barrier needs to be after the atomic_read. Please see my patch to Dave. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From domen@coderock.org Fri Apr 8 00:53:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 00:53:31 -0700 (PDT) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j387rLNj022264 for ; Fri, 8 Apr 2005 00:53:21 -0700 Received: by trashy.coderock.org (Postfix, from userid 780) id D45E01F3A3; Fri, 8 Apr 2005 09:53:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 0D97D1F3A4; Fri, 8 Apr 2005 09:53:14 +0200 (CEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 545761F39A; Fri, 8 Apr 2005 09:52:32 +0200 (CEST) Subject: [patch 1/1] drivers/net/: Use the DMA_{64,32}BIT_MASK constants To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, tklauser@nuerscht.ch From: domen@coderock.org Date: Fri, 08 Apr 2005 09:52:32 +0200 Message-Id: <20050408075232.545761F39A@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 16181 Lines: 419 The previous patch did not compile cleanly on all architectures so here's a fixed one. Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() This patch includes dma-mapping.h explicitly because it caused errors on some architectures otherwise. See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details Signed-off-by: Tobias Klauser Signed-off-by: Domen Puncer --- kj-domen/drivers/net/8139cp.c | 9 +++++---- kj-domen/drivers/net/acenic.c | 5 +++-- kj-domen/drivers/net/e100.c | 3 ++- kj-domen/drivers/net/hp100.c | 3 ++- kj-domen/drivers/net/ns83820.c | 5 +++-- kj-domen/drivers/net/s2io.c | 7 ++++--- kj-domen/drivers/net/sis900.c | 5 ++--- kj-domen/drivers/net/sk98lin/skge.c | 5 +++-- kj-domen/drivers/net/sungem.c | 5 +++-- kj-domen/drivers/net/tg3.c | 7 ++++--- kj-domen/drivers/net/tlan.c | 3 ++- kj-domen/drivers/net/tokenring/lanstreamer.c | 3 ++- kj-domen/drivers/net/tulip/dmfe.c | 3 ++- kj-domen/drivers/net/tulip/winbond-840.c | 3 ++- kj-domen/drivers/net/via-rhine.c | 3 ++- kj-domen/drivers/net/wan/wanxl.c | 5 +++-- 16 files changed, 44 insertions(+), 30 deletions(-) diff -puN drivers/net/8139cp.c~dma_mask-drivers_net drivers/net/8139cp.c --- kj/drivers/net/8139cp.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/8139cp.c 2005-04-05 12:57:45.000000000 +0200 @@ -60,6 +60,7 @@ #include #include #include +#include #include #include #include @@ -1702,19 +1703,19 @@ static int cp_init_one (struct pci_dev * /* Configure DMA attributes. */ if ((sizeof(dma_addr_t) > 4) && - !pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL) && - !pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + !pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { pci_using_dac = 1; } else { pci_using_dac = 0; - rc = pci_set_dma_mask(pdev, 0xffffffffULL); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_res; } - rc = pci_set_consistent_dma_mask(pdev, 0xffffffffULL); + rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR PFX "No usable consistent DMA configuration, " "aborting.\n"); diff -puN drivers/net/acenic.c~dma_mask-drivers_net drivers/net/acenic.c --- kj/drivers/net/acenic.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/acenic.c 2005-04-05 12:57:45.000000000 +0200 @@ -58,6 +58,7 @@ #include #include #include +#include #include #include #include @@ -1167,9 +1168,9 @@ static int __devinit ace_init(struct net /* * Configure DMA attributes. */ - if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { ap->pci_using_dac = 1; - } else if (!pci_set_dma_mask(pdev, 0xffffffffULL)) { + } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { ap->pci_using_dac = 0; } else { ecode = -ENODEV; diff -puN drivers/net/e100.c~dma_mask-drivers_net drivers/net/e100.c --- kj/drivers/net/e100.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/e100.c 2005-04-05 12:57:45.000000000 +0200 @@ -143,6 +143,7 @@ #include #include #include +#include #include #include #include @@ -2201,7 +2202,7 @@ static int __devinit e100_probe(struct p goto err_out_disable_pdev; } - if((err = pci_set_dma_mask(pdev, 0xFFFFFFFFULL))) { + if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) { DPRINTK(PROBE, ERR, "No usable DMA configuration, aborting.\n"); goto err_out_free_res; } diff -puN drivers/net/hp100.c~dma_mask-drivers_net drivers/net/hp100.c --- kj/drivers/net/hp100.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/hp100.c 2005-04-05 12:57:45.000000000 +0200 @@ -106,6 +106,7 @@ #include #include #include +#include #include #include #include @@ -562,7 +563,7 @@ static int __devinit hp100_probe1(struct * Also, we can have EISA Busmaster cards (not tested), * so beware !!! - Jean II */ if((bus == HP100_BUS_PCI) && - (pci_set_dma_mask(pci_dev, 0xffffffff))) { + (pci_set_dma_mask(pci_dev, DMA_32BIT_MASK))) { /* Gracefully fallback to shared memory */ goto busmasterfail; } diff -puN drivers/net/ns83820.c~dma_mask-drivers_net drivers/net/ns83820.c --- kj/drivers/net/ns83820.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/ns83820.c 2005-04-05 12:57:45.000000000 +0200 @@ -99,6 +99,7 @@ #include #include #include +#include #include #include #include @@ -1841,9 +1842,9 @@ static int __devinit ns83820_init_one(st int using_dac = 0; /* See if we can set the dma mask early on; failure is fatal. */ - if (TRY_DAC && !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { + if (TRY_DAC && !pci_set_dma_mask(pci_dev, DMA_64BIT_MASK)) { using_dac = 1; - } else if (!pci_set_dma_mask(pci_dev, 0xffffffff)) { + } else if (!pci_set_dma_mask(pci_dev, DMA_32BIT_MASK)) { using_dac = 0; } else { printk(KERN_WARNING "ns83820.c: pci_set_dma_mask failed!\n"); diff -puN drivers/net/s2io.c~dma_mask-drivers_net drivers/net/s2io.c --- kj/drivers/net/s2io.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/s2io.c 2005-04-05 12:57:45.000000000 +0200 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -4593,19 +4594,19 @@ s2io_init_nic(struct pci_dev *pdev, cons return ret; } - if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 64bit DMA\n"); dma_flag = TRUE; if (pci_set_consistent_dma_mask - (pdev, 0xffffffffffffffffULL)) { + (pdev, DMA_64BIT_MASK)) { DBG_PRINT(ERR_DBG, "Unable to obtain 64bit DMA for \ consistent allocations\n"); pci_disable_device(pdev); return -ENOMEM; } - } else if (!pci_set_dma_mask(pdev, 0xffffffffUL)) { + } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 32bit DMA\n"); } else { pci_disable_device(pdev); diff -puN drivers/net/sis900.c~dma_mask-drivers_net drivers/net/sis900.c --- kj/drivers/net/sis900.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/sis900.c 2005-04-05 12:57:45.000000000 +0200 @@ -66,6 +66,7 @@ #include #include #include +#include #include /* Processor type for cache alignment. */ #include @@ -93,8 +94,6 @@ static int sis900_debug = -1; /* Use SIS /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (4*HZ) -/* SiS 900 is capable of 32 bits BM DMA */ -#define SIS900_DMA_MASK 0xffffffff enum { SIS_900 = 0, @@ -413,7 +412,7 @@ static int __devinit sis900_probe(struct ret = pci_enable_device(pci_dev); if(ret) return ret; - i = pci_set_dma_mask(pci_dev, SIS900_DMA_MASK); + i = pci_set_dma_mask(pci_dev, DMA_32BIT_MASK); if(i){ printk(KERN_ERR "sis900.c: architecture does not support" "32bit PCI busmaster DMA\n"); diff -puN drivers/net/sk98lin/skge.c~dma_mask-drivers_net drivers/net/sk98lin/skge.c --- kj/drivers/net/sk98lin/skge.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/sk98lin/skge.c 2005-04-05 12:57:45.000000000 +0200 @@ -112,6 +112,7 @@ #include #include #include +#include #include "h/skdrv1st.h" #include "h/skdrv2nd.h" @@ -4912,8 +4913,8 @@ static int __devinit skge_probe_one(stru goto out; /* Configure DMA attributes. */ - if (pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL) && - pci_set_dma_mask(pdev, (u64) 0xffffffff)) + if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) && + pci_set_dma_mask(pdev, DMA_32BIT_MASK)) goto out_disable_device; diff -puN drivers/net/sungem.c~dma_mask-drivers_net drivers/net/sungem.c --- kj/drivers/net/sungem.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/sungem.c 2005-04-05 12:57:45.000000000 +0200 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -2989,10 +2990,10 @@ static int __devinit gem_init_one(struct */ if (pdev->vendor == PCI_VENDOR_ID_SUN && pdev->device == PCI_DEVICE_ID_SUN_GEM && - !pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL)) { + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { pci_using_dac = 1; } else { - err = pci_set_dma_mask(pdev, (u64) 0xffffffff); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); diff -puN drivers/net/tg3.c~dma_mask-drivers_net drivers/net/tg3.c --- kj/drivers/net/tg3.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/tg3.c 2005-04-05 12:57:45.000000000 +0200 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -8702,17 +8703,17 @@ static int __devinit tg3_init_one(struct } /* Configure DMA attributes. */ - err = pci_set_dma_mask(pdev, 0xffffffffffffffffULL); + err = pci_set_dma_mask(pdev, DMA_64BIT_MASK); if (!err) { pci_using_dac = 1; - err = pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL); + err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (err < 0) { printk(KERN_ERR PFX "Unable to obtain 64 bit DMA " "for consistent allocations\n"); goto err_out_free_res; } } else { - err = pci_set_dma_mask(pdev, 0xffffffffULL); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); diff -puN drivers/net/tlan.c~dma_mask-drivers_net drivers/net/tlan.c --- kj/drivers/net/tlan.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/tlan.c 2005-04-05 12:57:45.000000000 +0200 @@ -171,6 +171,7 @@ #include #include #include +#include #include #include #include @@ -555,7 +556,7 @@ static int __devinit TLan_probe1(struct priv->adapter = &board_info[ent->driver_data]; - rc = pci_set_dma_mask(pdev, 0xFFFFFFFF); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR "TLAN: No suitable PCI mapping available.\n"); goto err_out_free_dev; diff -puN drivers/net/tokenring/lanstreamer.c~dma_mask-drivers_net drivers/net/tokenring/lanstreamer.c --- kj/drivers/net/tokenring/lanstreamer.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/tokenring/lanstreamer.c 2005-04-05 12:57:45.000000000 +0200 @@ -118,6 +118,7 @@ #include #include #include +#include #include #include #include @@ -258,7 +259,7 @@ static int __devinit streamer_init_one(s #endif #endif - rc = pci_set_dma_mask(pdev, 0xFFFFFFFFULL); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR "%s: No suitable PCI mapping available.\n", dev->name); diff -puN drivers/net/tulip/dmfe.c~dma_mask-drivers_net drivers/net/tulip/dmfe.c --- kj/drivers/net/tulip/dmfe.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/tulip/dmfe.c 2005-04-05 12:57:45.000000000 +0200 @@ -78,6 +78,7 @@ #include #include #include +#include #include #include #include @@ -354,7 +355,7 @@ static int __devinit dmfe_init_one (stru SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (pci_set_dma_mask(pdev, 0xffffffff)) { + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_WARNING DRV_NAME ": 32-bit PCI DMA not available.\n"); err = -ENODEV; goto err_out_free; diff -puN drivers/net/tulip/winbond-840.c~dma_mask-drivers_net drivers/net/tulip/winbond-840.c --- kj/drivers/net/tulip/winbond-840.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/tulip/winbond-840.c 2005-04-05 12:57:45.000000000 +0200 @@ -121,6 +121,7 @@ static int full_duplex[MAX_UNITS] = {-1, #include #include #include +#include #include #include #include @@ -394,7 +395,7 @@ static int __devinit w840_probe1 (struct irq = pdev->irq; - if (pci_set_dma_mask(pdev,0xFFFFffff)) { + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA limitations.\n", pci_name(pdev)); return -EIO; diff -puN drivers/net/via-rhine.c~dma_mask-drivers_net drivers/net/via-rhine.c --- kj/drivers/net/via-rhine.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/via-rhine.c 2005-04-05 12:57:45.000000000 +0200 @@ -186,6 +186,7 @@ static const int multicast_filter_limit #include #include #include +#include #include #include #include @@ -740,7 +741,7 @@ static int __devinit rhine_init_one(stru goto err_out; /* this should always be supported */ - rc = pci_set_dma_mask(pdev, 0xffffffff); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR "32-bit PCI DMA addresses not supported by " "the card!?\n"); diff -puN drivers/net/wan/wanxl.c~dma_mask-drivers_net drivers/net/wan/wanxl.c --- kj/drivers/net/wan/wanxl.c~dma_mask-drivers_net 2005-04-05 12:57:45.000000000 +0200 +++ kj-domen/drivers/net/wan/wanxl.c 2005-04-05 12:57:45.000000000 +0200 @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -624,8 +625,8 @@ static int __devinit wanxl_pci_init_one( /* FIXME when PCI/DMA subsystems are fixed. We set both dma_mask and consistent_dma_mask back to 32 bits to indicate the card can do 32-bit DMA addressing */ - if (pci_set_consistent_dma_mask(pdev, 0xFFFFFFFF) || - pci_set_dma_mask(pdev, 0xFFFFFFFF)) { + if (pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK) || + pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_ERR "wanXL: No usable DMA configuration\n"); wanxl_pci_remove_one(pdev); return -EIO; _ From herbert@gondor.apana.org.au Fri Apr 8 04:37:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 04:37:54 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38BbjFX006924 for ; Fri, 8 Apr 2005 04:37:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJrnj-0003RY-00; Fri, 08 Apr 2005 21:37:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJrnD-0006rv-00; Fri, 08 Apr 2005 21:36:55 +1000 Date: Fri, 8 Apr 2005 21:36:55 +1000 To: Dmitry Yusupov Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050408113654.GA26095@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> <1112917001.3893.77.camel@beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112917001.3893.77.camel@beastie> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1006 Lines: 27 On Thu, Apr 07, 2005 at 04:36:41PM -0700, Dmitry Yusupov wrote: > > This actually even better since we will guarantee "down" call delivery. > My only concern is that it is not very generic. Do you know clean way to > implement it? How generic do you want this? Do you need this for socket types other than netlink? For a one-packet version, we can pre-allocate an skb/page in response to a setsockopt and store it in sk_send_head/sk_sndmsg_page. This can then be used at sendmsg time. Obviously subsequent messages will have to use alloc_skb until that skb is released. Alternatively, we can let the socket allocate skb's from an emergency pool similar to what was discussed in the thread "Summary of 2005 Kernel Summit Proposed Topics". Again this could enabled on a setsockopt. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 8 05:39:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 05:39:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38CdZdK009222 for ; Fri, 8 Apr 2005 05:39:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DJslF-0003t2-00; Fri, 08 Apr 2005 22:38:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DJsiq-0006xJ-00; Fri, 08 Apr 2005 22:36:28 +1000 From: Herbert Xu To: fubar@us.ibm.com (Jay Vosburgh) Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Organization: Core In-Reply-To: <200504072135.j37LZt4f004009@death.nxdomain.ibm.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 08 Apr 2005 22:36:28 +1000 X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1552 Lines: 39 Jay Vosburgh wrote: > > Yes, that works, and yes, the troublesome calls come from > softirq (timers). In that case, the rtnetlink patch would be: This should work. However, this is a bit of an eye sore as it is the only place where rtmsg_ifinfo is called from softirq context. In fact, this is probably the only place where CHANGEADDR (and perhaps even call_netdevice_notifiers) is called from softirq context. It just so happens that all the CHANGEADDR handlers were coded to be on the safe side and this seems to be the only place where it sleeps. Nevertheless, I'd like to ask the possibility for bond to not do this from softirq context. I looked at bond_alb.c briefly and it appears that the MAC addresses aren't actually set from the timers. It is however set in user context with spin locks held to guard against the timer. I looked at one of those places: alb_handle_addr_collision_on_attach. As far as I can see, there is no need for the address change to occur under the write_lock. It would work just as well if that function returned the MAC address to be set and performed the actual setting after dropping the lock. So if you have time, could you please comb through the bonding driver and let us know if it is possible to move the setting of the MAC address outside atomic areas. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Fri Apr 8 05:43:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 05:43:44 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38ChamC009915 for ; Fri, 8 Apr 2005 05:43:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DJsph-0006Le-3L for netdev@oss.sgi.com; Fri, 08 Apr 2005 08:43:33 -0400 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 1DJspf-00063F-5Y; Fri, 08 Apr 2005 08:43:31 -0400 Subject: Re: [RFC] QoS: new per flow queue From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050407203631.02CF.LARK@linux.net.cn> References: <20050406210800.0296.LARK@linux.net.cn> <1112871961.1117.121.camel@jzny.localdomain> <20050407203631.02CF.LARK@linux.net.cn> Content-Type: text/plain Organization: jamalopolous Message-Id: <1112964208.1088.226.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Apr 2005 08:43:28 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1585 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: 5163 Lines: 136 Wang, sorry for not getting back sooner - I actually wanted to read what you are saying before responding ;-> On Thu, 2005-04-07 at 09:14, Wang Jian wrote: > 1. a flow (in my perflow queue implementation) is a tuple of five > elements, but, for some reason, if the users misused this queue and send > non-flow packet, e.g. ICMP packet here; > > 2. a queue is configured to handle 100 flows, but the 101st flow comes; > > For this two situations, currently, the implementation just drops > packets. However, a clean way is to reclassify the packet into another > class (default) and provides no per flow guarantee. > The reclassification or #1 will best be left to the user. This is not hard to do. > > Doesnt that defeat the purpose of it being "per flow queue" ;-> > > Per flow queue, is not one queue per flow ;) It is queue which can > provide bandwidth assurance and constraint per flow. > > The implementation can be either one queue per flow, or all flows fit > into one queue. > Ok, stop calling it per-flow-queue then ;-> You should call it per-flow-rate-guarantee. > As I already said, this approach has drawbacks > > 1. when flow count overlimit, no guarantee > 2. when flow count is underlimit, the guaranteed sum bandwidth can be > exploited to waste bandwidth. > > So, thinking of per flow queue, it is "queue which can provide bandwidth > assurance and constraint per flow", and with only one queue! > Sharing is not a big challenge - and should be policy driven. HTB and CBQ both support it. I am not sure about HFSC. > You only need to create one HTB, one filter and one per flow queue for > VoIP; and one HTB, one filter and one per flow queue for VPN. > > I think the "per flow" name does confuse you ;) My fault. The "queue" part is confusing - the "perflow" is fine. Lets stick with per-flow-rate-guarantee as the description. So it seems you want by all means to avoid entering something that will take forever to list. Did i understand this correctly? We can probably avoid insisting on dynamically creating classes maybe. You can rate control before you enqueue and we can use fwmark perhaps. Earlier i also asked whether policing will suffice. Heres an example (maybe dated syntax, but concept still valid) that shows sharing using policers: http://www.cyberus.ca/~hadi/patches/action/README look at the example where it says "--cut here --" The only difference in this case is instead of creating 1000 classes you create 1000 policers as a result of the hash. Something along: u32 classify for port 80 prio high \ action dymfwmark create range min 1 max 1000 \ action police to some rate if result is drop we stop here \ else continue \ fwmark classify prio low\ select one of two queues (high prio or low prio Q) Very small script but still doesnt avoid the "seeing 1000 things". In this case if you list actions you see 1000. The lockings in this case are more bearable than having the dynamic marker creating queues. Typically the actions in a topology graph are stiched together at policy init time for efficiency reasons - so we dont have to do lookups at runtime. In this case it will need to have static lookup instead because depending on what the hash selects you want to select a different policer instance. I think i know an easy way of doing this (example storing per hash policer pointer in the dynmark table and doing the invoke from within dynmark). > The problem occurs when you delete and add, and so on. It not good idea > to reuse a used classid when there is stream classified as old. > > For example, you give class 1:1000 htb rate 200kbps ceil 200kbps for > http, and you delete the class 1:1000 and redefine 1:1000 htb rate > 30kbps ceil 30kbps for ftp. > > At this time, the remained http streams carries a CONNMARK and restore > to MARK and then classified as 1:0000. Then 1:1000 is not what you want. > I would think the number 1000 should be related to hash of flow header, no? In which case there should be no collision unless the hash of ftp and http are 1000. > > > > > > > I am suprised no one has compared all the rate control schemes. > > > > > > > > btw, would policing also suffice for you? The only difference is it will > > > > drop packets if you exceed your rate. You can also do hierachical > > > > sharing. > > > > > > policy suffices, but doesn't serve the purpose of per flow queue. > > > > > > > Policing will achieve the goal of rate control without worrying about > > any queueing. I like the idea of someone trying to create dynamic queues > > though ;-> > > > > You need per flow queue to control something, like VoIP streams, or VPN > streams. If you just use policy, mixed traffic is send to per flow queue. > That is definitely not the purpose of per flow queue. > > The dynamic queue creating is another way to implement the per flow > control (yes, one class and queue per flow). I think it is more complex > and wastes resources. > Look at the above suggestion - what you will waste in that case is polices. You should actually not use HTB but rather strict prio qdisc with policers. cheers, jamal From christoph@graphe.net Fri Apr 8 08:05:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 08:05:52 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38F5lol015220 for ; Fri, 8 Apr 2005 08:05:47 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DJv2d-0005oa-96; Fri, 08 Apr 2005 08:05:07 -0700 Date: Fri, 8 Apr 2005 08:05:00 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050408054831.GA569@gondor.apana.org.au> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> <20050408054831.GA569@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 259 Lines: 7 On Fri, 8 Apr 2005, Herbert Xu wrote: > This is wrong. The barrier needs to be after the atomic_read. > Please see my patch to Dave. Ok. How does one get onto the netdev list? The personal cc's of my mail to you also always bounces with admin prohibition. From dmitry_yus@yahoo.com Fri Apr 8 08:30:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 08:30:23 -0700 (PDT) Received: from smtp103.mail.sc5.yahoo.com (smtp103.mail.sc5.yahoo.com [66.163.169.222]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j38FUIcs019900 for ; Fri, 8 Apr 2005 08:30:18 -0700 Received: from unknown (HELO ?172.10.7.7?) (dmitry?yus@24.7.114.77 with plain) by smtp103.mail.sc5.yahoo.com with SMTP; 8 Apr 2005 15:30:18 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050408113654.GA26095@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> <1112917001.3893.77.camel@beastie> <20050408113654.GA26095@gondor.apana.org.au> Content-Type: text/plain Date: Fri, 08 Apr 2005 08:30:14 -0700 Message-Id: <1112974214.17165.8.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1184 Lines: 33 On Fri, 2005-04-08 at 21:36 +1000, Herbert Xu wrote: > On Thu, Apr 07, 2005 at 04:36:41PM -0700, Dmitry Yusupov wrote: > > > > This actually even better since we will guarantee "down" call delivery. > > My only concern is that it is not very generic. Do you know clean way to > > implement it? > > How generic do you want this? Do you need this for socket types other > than netlink? as discussed on kernel-summit-discuss. yes. we need generic OOM-safety solution. > For a one-packet version, we can pre-allocate an skb/page in response to > a setsockopt and store it in sk_send_head/sk_sndmsg_page. > > This can then be used at sendmsg time. Obviously subsequent messages > will have to use alloc_skb until that skb is released. > > Alternatively, we can let the socket allocate skb's from an emergency > pool similar to what was discussed in the thread > "Summary of 2005 Kernel Summit Proposed Topics". This is ideally how it should be for sendmsg paths. socket applications like iscsi, nbd, etc will use it for TCP/IP type of socket. iscsi could re-use the same generic "emergency pool" code for netlink. > Again this could enabled on a setsockopt. perfect. > Cheers, From akpm@osdl.org Fri Apr 8 09:36:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 09:36:48 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38GaeKV022546 for ; Fri, 8 Apr 2005 09:36:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j38GaYs4000527 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Apr 2005 09:36:34 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j38GaXIG010343; Fri, 8 Apr 2005 09:36:33 -0700 Date: Fri, 8 Apr 2005 09:36:30 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: Indrek Kruusa Subject: Fw: Re: 2.6.12-rc2-mm2 Message-Id: <20050408093630.0ff78c67.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1588 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: 1349 Lines: 53 Begin forwarded message: Date: Fri, 08 Apr 2005 15:25:16 +0300 From: Indrek Kruusa To: Andrew Morton Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.12-rc2-mm2 Andrew Morton wrote: >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ > > Wow... it responds despite the load average of 83.63 :) http://www.tuleriit.ee/progs/img/pic1.png http://www.tuleriit.ee/progs/img/pic2.png http://www.tuleriit.ee/progs/img/pic3.png dmesg is not clean though: TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 392 messages suppressed. TCP: time wait bucket table overflow printk: 290 messages suppressed. TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 295 messages suppressed. TCP: time wait bucket table overflow What I did: - "bombing" httpd with JMeter (from another computer) - copying files from USB memory device to harddisk - copying file with scp Indrek From linville@redhat.com Fri Apr 8 09:53:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 09:53:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38Gra0Y024437 for ; Fri, 8 Apr 2005 09:53:37 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j38GrOwq009373; Fri, 8 Apr 2005 12:53:24 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j38GrJO15366; Fri, 8 Apr 2005 12:53:19 -0400 Received: from savage.devel.redhat.com (savage.devel.redhat.com [172.16.59.46]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j38GrJpr000351; Fri, 8 Apr 2005 12:53:19 -0400 Received: from savage.devel.redhat.com (localhost.localdomain [127.0.0.1]) by savage.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j38GrJkX012930; Fri, 8 Apr 2005 12:53:19 -0400 Received: (from linville@localhost) by savage.devel.redhat.com (8.12.11/8.12.11/Submit) id j38GrJvt012929; Fri, 8 Apr 2005 12:53:19 -0400 Date: Fri, 8 Apr 2005 12:53:19 -0400 From: "John W. Linville" To: Radheka Godse Cc: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2 0/17] bonding: sysfs interface... Message-ID: <20050408165319.GF32431@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@redhat.com Precedence: bulk X-list: netdev Content-Length: 967 Lines: 28 On Fri, Apr 08, 2005 at 04:15:24PM -0700, Radheka Godse wrote: > > This patch set implements the sysfs interface for bonding and has a couple > bug fixes. We have done a full test pass and consider these patches ready > for inclusion upstream. We have submitted them to bonding-devel several > times and have incorporated feedback and fixes all known issues. I, for one, view these patches as very welcome. I intend to comment further later, but for now... FC3 users are invited to use the test kernels here: http://people.redhat.com/linville/kernels/fc3/ I have incorporated the bonding driver from 2.6.12-rc2 plus the bonding sysfs patches (along with some unrelated patches) to the current FC3 kernel sources. If you are an FC3 user and you want to experiment w/ these changes, this is the easiest way for you to do so. I'd love to hear feedback, either on the lists or directly to this address. Thanks, John -- John W. Linville linville@redhat.com From jheffner@psc.edu Fri Apr 8 12:34:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 12:34:09 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38JY28l032365 for ; Fri, 8 Apr 2005 12:34:03 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j38JXiuh001906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 15:33:49 -0400 (EDT) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j38JXifq021369; Fri, 8 Apr 2005 15:33:44 -0400 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j38JXioa021366; Fri, 8 Apr 2005 15:33:44 -0400 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Fri, 8 Apr 2005 15:33:44 -0400 (EDT) From: John Heffner To: Andi Kleen cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers In-Reply-To: Message-ID: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1662 Lines: 48 On Sat, 19 Mar 2005, Andi Kleen wrote: > Stephen Hemminger writes: > > > Since developers want to experiment with different congestion > > control mechanisms, and the kernel is getting bloated with overlapping > > data structure and code for multiple algorithms; here is a patch to > > split out the Reno, Vegas, Westwood, BIC congestion control stuff > > into an infrastructure similar to the I/O schedulers. > > [...] > > Did you do any benchmarks to check that wont slow it down? > > I would recommend to try it on a IA64 machine if possible. In the > past we found that adding indirect function calls on IA64 to networking > caused measurable slowdowns in macrobenchmarks. > In that case it was LSM callbacks, but your code looks like it will > add even more. For the record, here are some benchmarks from an ia64 over GigE. I set the MTU to 564 so it actually stressed the CPU. Numbers are throughput (10^6 bits/sec). Command line used: netperf -H 192.168.1.3 -l -1000000000 -c -C -v 2. The sender was a 1-CPU 900 MHz Itanium2. The receiver was a 1-CPU 2.4 GHz Pentium 4. The sender reported over 99% utilization; the receiver reported about 50%. The NICs were both fiber SysKonnect 9843's connected back to back. Normal reno Modular reno 392.77 392.59 393.96 393.66 393.22 393.72 393.12 393.81 392.09 393.37 393.3 393.58 391.81 393.22 393.11 394.1 391.32 393.77 392.94 393.03 average 392.76 393.49 stdev 0.79 0.44 -John From pavel@ucw.cz Fri Apr 8 13:16:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 13:16:26 -0700 (PDT) Received: from amd.ucw.cz (postfix@gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38KGGkS001384 for ; Fri, 8 Apr 2005 13:16:19 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 4C4A42D04A; Fri, 8 Apr 2005 22:16:07 +0200 (CEST) Date: Fri, 8 Apr 2005 22:16:07 +0200 From: Pavel Machek To: Jeff Garzik Cc: =?iso-8859-1?Q?J=F6rn?= Engel , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] s390: claw network device driver Message-ID: <20050408201606.GA1429@elf.ucw.cz> References: <200503290533.j2T5XEYT028850@hera.kernel.org> <4248FBFD.5000809@pobox.com> <20050328230830.5e90396f.akpm@osdl.org> <20050329071002.GA16204@havoc.gtf.org> <20050329152057.GA27840@wohnheim.fh-wedel.de> <4249B52C.2000300@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4249B52C.2000300@pobox.com> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: netdev Content-Length: 1548 Lines: 61 Hi! > >>As mentioned in the email, you want netdev, not linux-net... > > > > > >Just out of curiosity: why are there two mailing lists? Especially if > >one of them is the Wrong One. > > > > linux-net is mostly dead. I get the impression it is occasionally used > by users. > > netdev (as, perhaps, the name implies) is where the network developers > hang out. Eh... pavel@Elf:~/bin$ grep linux-net /usr/src/linux/MAINTAINERS L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org L: linux-net@vger.kernel.org pavel@Elf:~/bin$ More importantly, it is still listed as "the list" for network drivers... NETWORK DEVICE DRIVERS P: Andrew Morton M: akpm@osdl.org P: Jeff Garzik M: jgarzik@pobox.com L: linux-net@vger.kernel.org S: Maintained NETWORKING [GENERAL] P: Networking Team M: netdev@oss.sgi.com L: linux-net@vger.kernel.org S: Maintained Pavel -- Boycott Kodak -- for their patent abuse against Java. From rick.jones2@hp.com Fri Apr 8 13:20:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 13:20:39 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38KKYBW001995 for ; Fri, 8 Apr 2005 13:20:35 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 7A4F957F; Fri, 8 Apr 2005 13:20:34 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA00181; Fri, 8 Apr 2005 13:20:33 -0700 (PDT) Message-ID: <4256E791.7080904@hp.com> Date: Fri, 08 Apr 2005 13:20:33 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1397 Lines: 43 > > For the record, here are some benchmarks from an ia64 over GigE. I > set the MTU to 564 so it actually stressed the CPU. Numbers are > throughput (10^6 bits/sec). > Command line used: netperf -H 192.168.1.3 -l -1000000000 -c -C -v 2. I so rarely see anyone use the byte count limits for -l - nice to know they still work :) FWIW, the argument to -l is passed through netperf's "convert()" routine which means you can use K|M|G for powers-of-two kilo, mega and giga; or k|m|g for powers of ten: netperf -H 192.168.1.3 -l -1g -c -C -v 2 > The sender was a 1-CPU 900 MHz Itanium2. The receiver was a 1-CPU 2.4 GHz > Pentium 4. The sender reported over 99% utilization; the receiver > reported about 50%. The NICs were both fiber SysKonnect 9843's connected > back to back. > > Normal reno Modular reno > 392.77 392.59 > 393.96 393.66 > 393.22 393.72 > 393.12 393.81 > 392.09 393.37 > 393.3 393.58 > 391.81 393.22 > 393.11 394.1 > 391.32 393.77 > 392.94 393.03 > > average 392.76 393.49 > stdev 0.79 0.44 Looks like noise. Fair enough. rick jones back to trying to figure-out why netperf IPv6 tests and ping6 won't work with local scope addresses but will with global... From fubar@us.ibm.com Fri Apr 8 14:00:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 14:00:11 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38Kxw8v003234 for ; Fri, 8 Apr 2005 14:00:04 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j38Kxqhk028684 for ; Fri, 8 Apr 2005 16:59:52 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j38KxqJL251030 for ; Fri, 8 Apr 2005 16:59:52 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j38KxqSb029522 for ; Fri, 8 Apr 2005 15:59:52 -0500 Received: from death.nxdomain.ibm.com (lig32-225-151-181.us.lig-dial.ibm.com [32.225.151.181]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j38KxPxA029103; Fri, 8 Apr 2005 15:59:46 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j38Kx6Nn009197; Fri, 8 Apr 2005 13:59:22 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j38KwhaG009173; Fri, 8 Apr 2005 13:59:04 -0700 Message-Id: <200504082059.j38KwhaG009173@death.nxdomain.ibm.com> To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address In-Reply-To: Message from Herbert Xu of "Fri, 08 Apr 2005 22:36:28 +1000." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Apr 2005 13:58:43 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2400 Lines: 57 Herbert Xu wrote: [...] >However, this is a bit of an eye sore as it is the only place >where rtmsg_ifinfo is called from softirq context. In fact, >this is probably the only place where CHANGEADDR (and perhaps >even call_netdevice_notifiers) is called from softirq context. I looked as well, and didn't find anywhere else doing the netdev related notifiers from softirq. [...] >Nevertheless, I'd like to ask the possibility for bond to not do >this from softirq context. > >I looked at bond_alb.c briefly and it appears that the MAC addresses >aren't actually set from the timers. It is however set in user >context with spin locks held to guard against the timer. There are several paths from a timer context, e.g., timer -> bond_mii_monitor -> bond_change_active_slave -> bond_alb_handle_active_change -> alb_set_slave_mac_addr There are also calls that go through bond_select_active_slave (then on to bond_change_active_slave). In all of these cases, the path is taken when a link failure is detected. Running the timers function from a work queue instead (to get a sleepable context) is technically possible. I'm not sure how much overhead that would add (given that the link monitor timer typically runs on intervals in the 10 - 50 ms range). Getting the locks out is a little trickier; I've only looked at it briefly and don't see a simple way to do it. Well, at least that isn't, shall we say, less than elegant: e.g., a work queue out of line call that just changes the MAC address. I'm not sure what extra delay that kind of scheme would add to the failover time for the link. >I looked at one of those places: alb_handle_addr_collision_on_attach. >As far as I can see, there is no need for the address change to occur >under the write_lock. That case, yes, could be rearranged to do the assignment outside the lock without too much pain. >So if you have time, could you please comb through the bonding driver >and let us know if it is possible to move the setting of the MAC >address outside atomic areas. As I said above, the timer case doesn't have an obviously good way to change it to do the MAC sets in a sleepable context with no locks. I also wonder how expensive it is to run work queue events every 10ms as compared to running timer events every 10ms? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From baruch@ev-en.org Fri Apr 8 14:34:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 14:34:29 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38LYOBS006148 for ; Fri, 8 Apr 2005 14:34:24 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 862A211AA35; Sat, 9 Apr 2005 00:34:11 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 1296B11A606; Sat, 9 Apr 2005 00:34:03 +0300 (IDT) Message-ID: <4256F8C6.40704@ev-en.org> Date: Fri, 08 Apr 2005 22:33:58 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Heffner Cc: "David S. Miller" , shemminger@osdl.org, netdev@oss.sgi.com, werner@almesberger.net Subject: Re: [PATCH] Too aggressive cwnd backoff References: <20050407164146.GA6479@ev-en.org> <20050407101653.2cc68db1@dxpl.pdx.osdl.net> <42557895.8040004@ev-en.org> <20050407113121.31b71a94.davem@davemloft.net> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 867 Lines: 21 John Heffner wrote: > This test looks correct to me. (We never touched it.) It is the bounding > parameter specified in rate halving. If you actually get down that far, > then rate halving is getting confused, though. In my tests with either NewReno at high-BDP network settings (300Kbit/s, 120ms delay, BDP = 3200 packets), we always go into this confused mode. It will always upon a drop go to a point between the one-half and one-quarter of the original cwnd, but then, due to performance problems at that point the queue is filled and lots of packets are getting lost in bursts after I disabled throttling, with throttling it goes even below one quarter. If I understand you correctly this check (that I changed) is correct and should not be changed but rather that the bug is elsewhere. I'll give it another look when I have some more time. Baruch From herbert@gondor.apana.org.au Fri Apr 8 14:46:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 14:46:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38LkK5q007226 for ; Fri, 8 Apr 2005 14:46:21 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK1Ib-0000L6-00; Sat, 09 Apr 2005 07:45:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK1I9-0007jt-00; Sat, 09 Apr 2005 07:45:29 +1000 Date: Sat, 9 Apr 2005 07:45:29 +1000 To: Christoph Lameter Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? Message-ID: <20050408214529.GA29716@gondor.apana.org.au> References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> <20050408054831.GA569@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1902 Lines: 75 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 08, 2005 at 08:05:00AM -0700, Christoph Lameter wrote: > On Fri, 8 Apr 2005, Herbert Xu wrote: > > > This is wrong. The barrier needs to be after the atomic_read. > > Please see my patch to Dave. > > Ok. How does one get onto the netdev list? The personal cc's of my mail echo subscribe netdev | mail majordomo@oss.sgi.com > to you also always bounces with admin prohibition. Strange. I'm getting your direct emails just fine. In fact I'm replying to it now. Anyway, here is my last patch again. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- linux-2.6/net/core/dst.c.orig 2005-04-07 20:48:25.000000000 +1000 +++ linux-2.6/net/core/dst.c 2005-04-07 20:57:33.000000000 +1000 @@ -169,9 +169,9 @@ struct neighbour *neigh; struct hh_cache *hh; +again: smp_rmb(); -again: neigh = dst->neighbour; hh = dst->hh; child = dst->child; @@ -197,19 +197,19 @@ kmem_cache_free(dst->ops->kmem_cachep, dst); dst = child; - if (dst) { + if (unlikely(dst)) { int nohash = dst->flags & DST_NOHASH; - if (atomic_dec_and_test(&dst->__refcnt)) { + atomic_dec(&dst->__refcnt); + + if (nohash) { /* We were real parent of this dst, so kill child. */ - if (nohash) + if (!atomic_read(&dst->__refcnt)) goto again; - } else { /* Child is still referenced, return it for freeing. */ - if (nohash) - return dst; - /* Child is still in his hash table */ + return dst; } + /* Child is still in his hash table or on the GC list. */ } return NULL; } --tKW2IUtsqtDRztdT-- From radheka.godse@intel.com Fri Apr 8 14:53:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 14:53:51 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38LrfxD007874 for ; Fri, 8 Apr 2005 14:53:41 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j38LrSdU015402; Fri, 8 Apr 2005 21:53:28 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j38LrSgI031338; Fri, 8 Apr 2005 21:53:28 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j38LrSSL013111; Fri, 8 Apr 2005 14:53:28 -0700 Date: Fri, 8 Apr 2005 14:52:58 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: Radheka Godse cc: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH 2.6.12-rc2 r8/17] bonding: SYSFS INTERFACE (large)-revised In-Reply-To: Message-ID: References: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 45336 Lines: 1517 >I'm not adverse to sysfs per say, but you are using like /proc with >multiple values per file. This is not what the original design was. I revised earlier patch submittal to remove sysfs stat file since the slave info is duplicated from /proc/net/bonding/bondX and is in proc format. Signed-off-by: Radheka Godse Signed-off-by: Mitch Williams diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bonding.h 2005-04-09 11:19:27.000000000 -0700 @@ -33,6 +33,7 @@ #include #include #include +#include #include "bond_3ad.h" #include "bond_alb.h" @@ -255,6 +247,13 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); int bond_create(char *name, struct bond_params *params, struct bonding **newbond); void bond_deinit(struct net_device *bond_dev); +int bond_create_sysfs(void); +void bond_destroy_sysfs(void); +void bond_destroy_sysfs_entry(struct bonding *bond); +int bond_create_sysfs_entry(struct bonding *bond); +int bond_create_slave_symlinks(struct net_device *master, struct net_device *slave); +void bond_destroy_slave_symlinks(struct net_device *master, struct net_device *slave); +int bond_check_abi_ver(void); int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, struct slave **vassal); int bond_release(struct net_device *bond_dev, struct net_device *slave_dev); int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev); diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_main.c 2005-04-09 11:18:45.000000000 -0700 @@ -573,6 +573,7 @@ static struct proc_dir_entry *bond_proc_dir = NULL; #endif +extern struct rw_semaphore bonding_rwsem; static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -1957,6 +1957,9 @@ } } + res = bond_create_slave_symlinks(bond_dev, slave_dev); + if (res) + goto err_unset_master; printk(KERN_INFO DRV_NAME ": %s: enslaving %s as a%s interface with a%s link.\n", bond_dev->name, slave_dev->name, @@ -2128,6 +2173,9 @@ write_unlock_bh(&bond->lock); + /* must do this from outside any spinlocks */ + bond_destroy_slave_symlinks(bond_dev, slave_dev); + bond_del_vlans_from_slave(bond, slave_dev); /* If the mode USES_PRIMARY, then we should only remove its @@ -2399,6 +2406,22 @@ } } +int bond_check_abi_ver(void) +{ + int retval = 1; + + if (orig_app_abi_ver == -1) { + orig_app_abi_ver = BOND_ABI_VERSION; + app_abi_ver = BOND_ABI_VERSION; + } + else { + if (app_abi_ver == 0) + retval = 0; + } + + return retval; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3367,7 +3390,10 @@ bond_remove_proc_entry(bond); bond_create_proc_entry(bond); #endif - + down_write(&(bonding_rwsem)); + bond_destroy_sysfs_entry(bond); + bond_create_sysfs_entry(bond); + up_write(&(bonding_rwsem)); return NOTIFY_DONE; } @@ -3761,6 +3787,7 @@ return -EINVAL; } + down_write(&(bonding_rwsem)); slave_dev = dev_get_by_name(ifr->ifr_slave); dprintk("slave_dev=%p: \n", slave_dev); @@ -3801,6 +3828,7 @@ orig_app_abi_ver = prev_abi_ver; } + up_write(&(bonding_rwsem)); return res; } @@ -4683,17 +4701,21 @@ goto err; } + res = bond_create_sysfs(); + if (res) + goto err; + register_netdevice_notifier(&bond_netdev_notifier); - return 0; - -out_err: - /* free and unregister all bonds that were successfully added */ + goto out; +err: + rtnl_lock(); bond_free_all(); - + bond_destroy_sysfs(); rtnl_unlock(); - +out: return res; + } static void __exit bonding_exit(void) @@ -4702,6 +4701,7 @@ rtnl_lock(); bond_free_all(); + bond_destroy_sysfs(); rtnl_unlock(); } diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_sysfs.c linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_sysfs.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_sysfs.c 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_sysfs.c 2005-04-09 11:04:01.000000000 -0700 @@ -0,0 +1,1348 @@ + +/* + * Copyright(c) 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * The full GNU General Public License is included in this distribution in the + * file called LICENSE. + * + * + * Changes: + * + * 2004/12/12 - Mitch Williams + * - Initial creation of sysfs interface. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* #define BONDING_DEBUG 1 */ +#include "bonding.h" +#define to_class_dev(obj) container_of(obj,struct class_device,kobj) +#define to_net_dev(class) container_of(class, struct net_device, class_dev) +#define to_bond(cd) ((struct bonding *)(to_net_dev(cd)->priv)) + +/*---------------------------- Declarations -------------------------------*/ + +/* Macros for real simple parsing of text. */ +#define eat_nonalnum(str,whence,max) \ + while (whence < max) {if (!isalnum(str[whence])) whence++; else break;}; +#define find_next_nonalpha(str,whence,max) \ + while (whence < max) {if (isalnum(str[whence])) whence++; else break;}; + +extern struct list_head bond_dev_list; +extern struct bond_params bonding_defaults; +extern struct bond_parm_tbl bond_mode_tbl[]; +extern struct bond_parm_tbl bond_lacp_tbl[]; + +static struct class *netdev_class; +/*--------------------------- Data Structures -----------------------------*/ + +/* Bonding sysfs lock. Why can't we just use the subsytem lock? + * Because kobject_register tries to acquire the subsystem lock. If + * we already hold the lock (which we would if the user was creating + * a new bond through the sysfs interface), we deadlock. + */ + +struct rw_semaphore bonding_rwsem; + + + + +/*------------------------------ Functions --------------------------------*/ + +/* + * "show" function for the bond_masters attribute. + * The class parameter is ignored. + */ +static ssize_t bonding_show_bonds(struct class *cls, char *buffer) +{ + int res = 0; + struct bonding *bond; + + down_read(&(bonding_rwsem)); + + list_for_each_entry(bond, &bond_dev_list, bond_list) { + res += sprintf(buffer + res, "%s ", + bond->dev->name); + if (res > (PAGE_SIZE - IFNAMSIZ)) { + dprintk("eek! too many bonds!\n"); + break; + } + } + res += sprintf(buffer + res, "\n"); + res++; + up_read(&(bonding_rwsem)); + return res; +} + +/* + * "store" function for the bond_masters attribute. This is what + * creates and deletes entire bonds. + * + * The class parameter is ignored. + * + * This function uses the eat_nonalnum and eat_alnum macros, define + * above. Why not use sscanf()? Scanf can get strings, but can't filter + * out inappropriate characters. For example, we can't have bonds named + * "foo/bar" or "foo*bar" or "Does this work?" as these aren't valid + * filenames. While we could use scanf to get strings and then validate + * them, this is quicker. + * The above examples give us these results: + * "foo/bar" gives two bonds, "foo" and "bar". + * "foo*bar" gives two bonds, "foo" and "bar". + * "Does this work?" gives three bonds, "Does", "this", and "work". + */ + +static ssize_t bonding_store_bonds(struct class *cls, const char *buffer, size_t count) +{ + char name[IFNAMSIZ]; + int i, res, found, pos = 0; + struct bonding *bond; + struct bonding *nxt; + + down_write(&(bonding_rwsem)); + /* First process adds */ + eat_nonalnum(buffer, pos, count); + /* Pos now points to the first alpha character. */ + i = pos; + find_next_nonalpha(buffer, i, count); + /* i now points to the next character past the end of the bond name. */ + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME "Interface name %.*s too large! Ignoring.\n", + i - pos, buffer + pos); + up_write(&(bonding_rwsem)); + return -EPERM; + } + /* Copy the bond name so we can deal with it separately. */ + strncpy(name, buffer + pos, i - pos); + /* Don't forget the null terminator! */ + name[i - pos] = 0; + while (strlen(name)) { + /* Got a bond name in name. Is it already in the list? */ + found = 0; + list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { + if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) { + /* Temporarily set a meaningless flag. When + * we get done with the loop, we'll check all of these. + * If the bond doesn't have this flag set, then we need + * to remove the bond. If the flag has it set, then + * we can just clear the flag. + */ + bond->flags |= IFF_DYNAMIC; + found = 1; + break; /* Found it, so go to next name */ + } + } + if (found == 0) { + printk(KERN_INFO DRV_NAME ": %s is being created...\n", name); + res = bond_create(name, &bonding_defaults, &bond); + if (res) { + up_write(&(bonding_rwsem)); + printk(KERN_INFO DRV_NAME ": %s interface already exists. Bond creation failed.\n", name); + return res; + } + printk(KERN_INFO DRV_NAME ": %s created.\n", name); + /* Set the flag so we don't delete + * this interface in the loop below. + */ + bond->flags |= IFF_DYNAMIC; + } + /* Scan for the next name. i still has the location of + * the char just past the end of the last name we handled. + */ + pos = i; + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME + ": %.*s interface name too large! Ignoring.\n", + i - pos, buffer + pos); + up_write(&(bonding_rwsem)); + return -EPERM; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + } /* end of while loop and end of input */ + + /* Now we do deletes. Walk through the list, and check to see + * if the flag didn't get set. If it's set, clear it. If it's + * not set, delete the bond. + */ + list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { + if (bond->flags & IFF_DYNAMIC) { + bond->flags &= ~IFF_DYNAMIC; + } else { + printk(KERN_INFO DRV_NAME ": %s is being deleted...\n", bond->dev->name); + rtnl_lock(); + unregister_netdevice(bond->dev); + bond_deinit(bond->dev); + bond_destroy_sysfs_entry(bond); + rtnl_unlock(); + printk(KERN_INFO DRV_NAME ": %s deleted.\n", bond->dev->name); + } + } + /* Always return either count or an error. If you return 0, you'll + * get called forever, which is bad. + */ + up_write(&(bonding_rwsem)); + return count; +} +/* class attribute for bond_masters file. This ends up in /sys/class/net */ +static CLASS_ATTR(bonding_masters, S_IWUSR | S_IRUGO, + bonding_show_bonds, bonding_store_bonds); + +int bond_create_slave_symlinks(struct net_device *master, struct net_device *slave) +{ + char linkname[IFNAMSIZ+7]; + int ret = 0; + + /* first, create a link from the slave back to the master */ + ret = sysfs_create_link(&(slave->class_dev.kobj), &(master->class_dev.kobj), + "master"); + if (ret) + return ret; + /* next, create a link from the master to the slave */ + sprintf(linkname,"slave_%s",slave->name); + ret = sysfs_create_link(&(master->class_dev.kobj), &(slave->class_dev.kobj), + linkname); + return ret; + +} + +void bond_destroy_slave_symlinks(struct net_device *master, struct net_device *slave) +{ + char linkname[IFNAMSIZ+7]; + + sysfs_remove_link(&(slave->class_dev.kobj), "master"); + sprintf(linkname,"slave_%s",slave->name); + sysfs_remove_link(&(master->class_dev.kobj), linkname); +} + + +/* + * Show the slaves in the current bond. + */ +static ssize_t bonding_show_slaves(struct class_device *cd, char *buf) +{ + struct slave *slave; + int i, res = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, slave, i) { + res += sprintf(buf + res, "%s ", slave->dev->name); + if (res > (PAGE_SIZE - IFNAMSIZ)) { + dprintk("eek! too many slaves!\n"); + break; + } + } + read_unlock_bh(&bond->lock); + res += sprintf(buf + res, "\n"); + res++; + up_read(&(bonding_rwsem)); + return res; +} + +/* + * Set the slaves in the current bond. The bond interface must be + * up for this to succeed. + * This function is largely the same flow as bonding_update_bonds(). + */ +static ssize_t bonding_store_slaves(struct class_device *cd, const char *buffer, size_t count) +{ + char name[IFNAMSIZ]; + int i, j, res, found, pos = 0, ret = count; + struct slave *slave; + struct net_device *dev = 0; + struct bonding *bond = to_bond(cd); + + if (!bond_check_abi_ver()) + { + printk(KERN_ERR DRV_NAME + ": Error: your version of ifenslave is incompatible " + "with the sysfs interface in this version of bonding. " + "Upgrade ifenslave to version 1 or greater and reload " + "bonding.\n"); + return -EINVAL; + } + + down_write(&(bonding_rwsem)); + + /* Quick sanity check -- is the bond interface up? */ + if (!(bond->dev->flags & IFF_UP)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update slaves because interface is down.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + /* Note: We can't hold bond->lock here, as bond_create grabs it. */ + + /* First process adds */ + + /* Copy the first name we find. */ + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME ": %s: Slave name %.*s too large! Ignoring.\n", + bond->dev->name, + i - pos, buffer + pos); + ret = -EPERM; + goto out; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + + while (strlen(name)) { + /* Got a slave name in name. Is it already there? */ + found = 0; + read_lock_bh(&bond->lock); + bond_for_each_slave(bond, slave, j) { + if (strnicmp(slave->dev->name, name, IFNAMSIZ) == 0) { + /* Temporarily set a meaningless flag. When + * we get done with the loop, we'll check all of these. + * If the slave doesn't have this flag set, then we need + * to remove the slave. If the flag has it set, then + * we can just clear the flag. + */ + slave->original_flags |= IFF_DYNAMIC; + found = 1; + break; /* Found it, so go to next name */ + } + } + read_unlock_bh(&bond->lock); + if (found == 0) { + printk(KERN_INFO DRV_NAME ": %s: Adding slave %s.\n", + bond->dev->name, name); + dev = dev_get_by_name(name); + if (!dev) { + printk(KERN_INFO DRV_NAME + ": %s: Interface %s does not exist!\n", + bond->dev->name, name); + ret = -EPERM; + goto out; + } + + if (dev->flags & IFF_SLAVE) { + printk(KERN_INFO DRV_NAME + ": %s: Interface %s is already enslaved!\n", + bond->dev->name, name); + ret = -EPERM; + goto out; + } + + /* If this is the first slave, then we need to set + the master's hardware address to be the same as the + slave's. */ + if (!(*((u32 *) & (bond->dev->dev_addr[0])))) { + memcpy(bond->dev->dev_addr, dev->dev_addr, + dev->addr_len); + } + + /* Set the slave's MTU to match the bond */ + if (dev->mtu != bond->dev->mtu) { + if (dev->change_mtu) { + res = dev->change_mtu(dev, + bond->dev->mtu); + if (res) { + ret = res; + goto out; + } + } else { + dev->mtu = bond->dev->mtu; + } + } + rtnl_lock(); + res = bond_enslave(bond->dev, dev, &slave); + rtnl_unlock(); + if (res) { + ret = res; + goto out; + } + slave->original_flags |= IFF_DYNAMIC; + dev_put(dev); + } + /* Get the next name in the buffer. */ + pos = i; + eat_nonalnum(buffer, pos, count); + i = pos; + find_next_nonalpha(buffer, i, count); + if (i - pos >= IFNAMSIZ) { + printk(KERN_ERR DRV_NAME + ": %s: Slave name %.*s too large! Ignoring.\n", + bond->dev->name, i - pos, buffer + pos); + ret = -EPERM; + goto out; + } + strncpy(name, buffer + pos, i - pos); + name[i - pos] = 0; + } /* End of while loop, and end of input. */ + + /* Now handle deletes. + * We can't use bond_for_each_slave here because we might modify + * the list when we're inside the loop. We can't hold the lock + * either because bond_release grabs it. + */ + slave = bond->first_slave; + i = bond->slave_cnt; + while (i > 0) { + BUG_ON(slave == 0); + if (slave->original_flags & IFF_DYNAMIC) { + slave->original_flags &= ~IFF_DYNAMIC; + slave = slave->next; + } else { + /* Didn't find the name of this slave in the list, so + * remove the slave. + */ + printk(KERN_INFO DRV_NAME + ": %s: Removing slave %s\n", + bond->dev->name, + slave->dev->name); + dev = slave->dev; + slave = slave->next; + rtnl_lock(); + res = bond_release(bond->dev, dev); + rtnl_unlock(); + if (res) { + ret = res; + goto out; + } + /* set the slave MTU to the default */ + if (dev->change_mtu) { + dev->change_mtu(dev, 1500); + } else { + dev->mtu = 1500; + } + } + i--; + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(slaves, S_IRUGO | S_IWUSR, bonding_show_slaves, bonding_store_slaves); + +/* + * Show and set the bonding mode. The bond interface must be down to + * change the mode. + */ +static ssize_t bonding_show_mode(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%s %d\n", + bond_mode_tbl[bond->params.mode].modename, + bond->params.mode) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_mode(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (bond->dev->flags & IFF_UP) { + printk(KERN_ERR DRV_NAME + "Unable to update mode of %s because interface is up.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + new_value = bond_parse_parm((char *)buf, bond_mode_tbl); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid mode value %.*s.\n", + bond->dev->name, + (int)strlen(buf) - 1, buf); + ret = -EINVAL; + goto out; + } else { + bond->params.mode = new_value; + bond_set_mode_ops(bond->dev, bond->params.mode); + printk(KERN_INFO DRV_NAME ": %s: setting mode to %s (%d).\n", + bond->dev->name, bond_mode_tbl[new_value].modename, new_value); + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(mode, S_IRUGO | S_IWUSR, bonding_show_mode, bonding_store_mode); + +/* + * Show and set the arp timer interval. There are two tricky bits + * here. First, if ARP monitoring is activated, then we must disable + * MII monitoring. Second, if the ARP timer isn't running, we must + * start it. + */ +static ssize_t bonding_show_arp_interval(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.arp_interval) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_arp_interval(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid arp_interval value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + printk(KERN_INFO DRV_NAME + ": %s: Setting ARP monitoring interval to %d.\n", + bond->dev->name, new_value); + bond->params.arp_interval = new_value; + if (bond->params.miimon) { + printk(KERN_INFO DRV_NAME + ": %s: ARP monitoring cannot be used with MII monitoring. " + "%s Disabling MII monitoring.\n", + bond->dev->name, bond->dev->name); + bond->params.miimon = 0; + del_timer_sync(&bond->mii_timer); + /* Kill MII timer, else it brings bond's link down */ + } + if (!bond->params.arp_targets[0]) { + printk(KERN_INFO DRV_NAME + ": %s: ARP monitoring has been set up, " + "but no ARP targets have been specified.\n", + bond->dev->name); + } + if (bond->dev->flags & IFF_UP) { + /* If the interface is up, we may need to fire off + * the ARP timer. If the interface is down, the + * timer will get fired off when the open function + * is called. + */ + if (bond->arp_timer.function) { + /* The timer's already set up, so fire it off */ + mod_timer(&bond->arp_timer, jiffies + 1); + } else { + /* Set up the timer. */ + init_timer(&bond->arp_timer); + bond->arp_timer.expires = jiffies + 1; + bond->arp_timer.data = + (unsigned long) bond->dev; + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { + bond->arp_timer.function = + (void *) + &bond_activebackup_arp_mon; + } else { + bond->arp_timer.function = + (void *) + &bond_loadbalance_arp_mon; + } + add_timer(&bond->arp_timer); + } + } + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(arp_interval, S_IRUGO | S_IWUSR , bonding_show_arp_interval, bonding_store_arp_interval); + +/* + * Show and set the arp targets. + */ +static ssize_t bonding_show_arp_targets(struct class_device *cd, char *buf) +{ + int i, res = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && bond->params.arp_targets[i]; + i++) { + res += sprintf(buf + res, "%u.%u.%u.%u ", + NIPQUAD(bond->params.arp_targets[i])); + res++; + } + + up_read(&(bonding_rwsem)); + return res; +} + +static ssize_t bonding_store_arp_targets(struct class_device *cd, const char *buf, size_t count) +{ + int octet1, octet2, octet3, octet4, ret = count; + int newpos = 0, pos = 0, i = 0; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d.%d.%d.%d%n", &octet1, &octet2, &octet3, &octet4, &pos); + while ((pos < count) && (i < BOND_MAX_ARP_TARGETS)) { + if ( (octet1 < 0) || (octet1 > 255) + || (octet2 < 0) || (octet2 > 255) + || (octet3 < 0) || (octet3 > 255) + || (octet4 < 0) || (octet4 > 255) + || ((octet1 == 0) && (octet2 == 0) && + (octet3 == 0) && (octet4 == 0)) + || ((octet1 == 255) && (octet2 == 255) && + (octet3 == 255) && (octet4 == 255)) + ) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to add arp target %d.%d.%d.%d\n", + bond->dev->name, octet1, octet2, octet3, octet4); + ret = -EINVAL; + goto out; + } else { + printk(KERN_INFO DRV_NAME + ": %s: Adding arp target %d.%d.%d.%d\n", + bond->dev->name, octet1, octet2, octet3, octet4); + /* Is this going to get me into trouble on big-endian boxes? */ + /* Is there a macro to do this? I can't find one... */ + bond->params.arp_targets[i] = htonl + ((((u32) octet1 & 0xff) << 24) | + (((u32) octet2 & 0xff) << 16) | + (((u32) octet3 & 0xff) << 8) | ((u32) octet4 & + 0xff)); + + i++; + } + + newpos = 0; + sscanf(buf + pos, "%d.%d.%d.%d%n", &octet1, &octet2, &octet3, + &octet4, &newpos); + if (newpos == 0) { + break; + } + pos += newpos; + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(arp_ip_target, S_IRUGO | S_IWUSR , bonding_show_arp_targets, bonding_store_arp_targets); + +/* + * Show and set the up and down delays. These must be multiples of the + * MII monitoring value, and are stored internally as the multiplier. + * Thus, we must translate to MS for the real world. + */ +static ssize_t bonding_show_downdelay(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.downdelay * bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_downdelay(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (!(bond->params.miimon)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to set down delay as MII monitoring is disabled\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid down delay value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + if ((new_value % bond->params.miimon) != 0) { + printk(KERN_WARNING DRV_NAME + ": %s: Warning: down delay (%d) is not a multiple " + "of miimon (%d), delay rounded to %d ms\n", + bond->dev->name, new_value, bond->params.miimon, + (new_value / bond->params.miimon) * + bond->params.miimon); + } + bond->params.downdelay = new_value / bond->params.miimon; + printk(KERN_INFO DRV_NAME ": %s: Setting down delay to %d.\n", + bond->dev->name, bond->params.downdelay * bond->params.miimon); + + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(down_delay, S_IRUGO | S_IWUSR , bonding_show_downdelay, bonding_store_downdelay); + +static ssize_t bonding_show_updelay(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.updelay * bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; + +} + +static ssize_t bonding_store_updelay(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (!(bond->params.miimon)) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to set up delay as MII monitoring is disabled\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid up delay value %d.\n", + bond->dev->name, new_value); + ret = -EINVAL; + goto out; + } else { + if ((new_value % bond->params.miimon) != 0) { + printk(KERN_WARNING DRV_NAME + ": %s: Warning: up delay (%d) is not a multiple " + "of miimon (%d), updelay rounded to %d ms\n", + bond->dev->name, new_value, bond->params.miimon, + (new_value / bond->params.miimon) * + bond->params.miimon); + } + bond->params.updelay = new_value / bond->params.miimon; + printk(KERN_INFO DRV_NAME ": %s: Setting up delay to %d.\n", + bond->dev->name, bond->params.updelay * bond->params.miimon); + + } + +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(up_delay, S_IRUGO | S_IWUSR , bonding_show_updelay, bonding_store_updelay); + +/* + * Show and set the LACP interval. Interface must be down, and the mode + * must be set to 802.3ad mode. + */ +static ssize_t bonding_show_lacp(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%s %d\n", + bond_lacp_tbl[bond->params.lacp_fast].modename, + bond->params.lacp_fast) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_lacp(struct class_device *cd, const char *buf, size_t count) +{ + int new_value, ret = count; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + if (bond->dev->flags & IFF_UP) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update LACP rate because interface is up.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + if (bond->params.mode != BOND_MODE_8023AD) { + printk(KERN_ERR DRV_NAME + ": %s: Unable to update LACP rate because bond is not in 802.3ad mode.\n", + bond->dev->name); + ret = -EPERM; + goto out; + } + + new_value = bond_parse_parm((char *)buf, bond_lacp_tbl); + + if ((new_value == 1) || (new_value == 0)) { + bond->params.lacp_fast = new_value; + printk(KERN_INFO DRV_NAME + ": %s: Setting LACP rate to %s (%d).\n", + bond->dev->name, bond_lacp_tbl[new_value].modename, new_value); + } else { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid LACP rate value %.*s.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + ret = -EINVAL; + } +out: + up_write(&(bonding_rwsem)); + return ret; +} +static CLASS_DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR, bonding_show_lacp, bonding_store_lacp); + +/* + * Show and set the MII monitor interval. There are two tricky bits + * here. First, if MII monitoring is activated, then we must disable + * ARP monitoring. Second, if the timer isn't running, we must + * start it. + */ +static ssize_t bonding_show_miimon(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.miimon) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_miimon(struct class_device *cd, const char *buf, size_t count) +{ + int new_value; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + if (new_value < 0) { + printk(KERN_ERR DRV_NAME + ": %s: Ignoring invalid miimon value %d.\n", + bond->dev->name, new_value); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Setting MII monitoring interval to %d.\n", + bond->dev->name, new_value); + bond->params.miimon = new_value; + if(bond->params.updelay) + printk(KERN_INFO DRV_NAME + ": %s: Note: Updating updelay (to %d) " + "since it is a multiple of the miimon value.\n", + bond->dev->name, + bond->params.updelay * bond->params.miimon); + if(bond->params.downdelay) + printk(KERN_INFO DRV_NAME + ": %s: Note: Updating downdelay (to %d) " + "since it is a multiple of the miimon value.\n", + bond->dev->name, + bond->params.downdelay * bond->params.miimon); + if (bond->params.arp_interval) { + printk(KERN_INFO DRV_NAME + ": %s: MII monitoring cannot be used with " + "ARP monitoring. Disabling ARP monitoring...\n", + bond->dev->name); + bond->params.arp_interval = 0; + del_timer_sync(&bond->arp_timer); + /* Kill ARP timer, else it brings bond's link down */ + } + + if (bond->dev->flags & IFF_UP) { + /* If the interface is up, we may need to fire off + * the MII timer. If the interface is down, the + * timer will get fired off when the open function + * is called. + */ + if (bond->mii_timer.function) { + /* The timer's already set up, so fire it off */ + mod_timer(&bond->mii_timer, jiffies + 1); + } else { + /* Set up the timer. */ + init_timer(&bond->mii_timer); + bond->mii_timer.expires = jiffies + 1; + bond->mii_timer.data = + (unsigned long) bond->dev; + bond->mii_timer.function = + (void *) &bond_mii_monitor; + add_timer(&bond->mii_timer); + } + } + } + + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(miimon, S_IRUGO | S_IWUSR, bonding_show_miimon, bonding_store_miimon); + +/* + * Show and set the primary slave. The store function is much + * simpler than bonding_store_slaves function because it only needs to + * handle one interface name. + * The bond must be a mode that supports a primary for this be + * set. + */ +static ssize_t bonding_show_primary(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->primary_slave) + count = sprintf(buf, "%s\n", bond->primary_slave->dev->name) + 1; + + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_primary(struct class_device *cd, const char *buf, size_t count) +{ + int i; + struct slave *slave; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + write_lock_bh(&bond->lock); + if (!USES_PRIMARY(bond->params.mode)) { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set primary slave; %s is in mode %d\n", + bond->dev->name, bond->dev->name, bond->params.mode); + } else { + bond_for_each_slave(bond, slave, i) { + if (strnicmp + (slave->dev->name, buf, + strlen(slave->dev->name)) == 0) { + printk(KERN_INFO DRV_NAME + ": %s: Setting %s as primary slave.\n", + bond->dev->name, slave->dev->name); + bond->primary_slave = slave; + bond_select_active_slave(bond); + goto out; + } + } + + /* if we got here, then we didn't match the name of any slave */ + + if (strlen(buf) == 0 || buf[0] == '\n') { + printk(KERN_INFO DRV_NAME + ": %s: Setting primary slave to None.\n", + bond->dev->name); + bond->primary_slave = 0; + bond_select_active_slave(bond); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set %.*s as primary slave as it is not a slave.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + } + } +out: + write_unlock_bh(&bond->lock); + up_write(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary, bonding_store_primary); + +/* + * Show and set the use_carrier flag. + */ +static ssize_t bonding_show_carrier(struct class_device *cd, char *buf) +{ + int count; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + count = sprintf(buf, "%d\n", bond->params.use_carrier) + 1; + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_carrier(struct class_device *cd, const char *buf, size_t count) +{ + int new_value; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + sscanf(buf, "%d", &new_value); + if ((new_value == 0) || (new_value == 1)) { + bond->params.use_carrier = new_value; + printk(KERN_INFO DRV_NAME ": %s: Setting use_carrier to %d.\n", + bond->dev->name, new_value); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Ignoring invalid use_carrier value %d.\n", + bond->dev->name, new_value); + } + up_write(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(use_carrier, S_IRUGO | S_IWUSR, bonding_show_carrier, bonding_store_carrier); + + +/* + * Show and set currently active_slave. + */ +static ssize_t bonding_show_active_slave(struct class_device *cd, char *buf) +{ + struct slave *curr; + struct bonding *bond = to_bond(cd); + int count; + + down_read(&(bonding_rwsem)); + + read_lock(&bond->curr_slave_lock); + curr = bond->curr_active_slave; + read_unlock(&bond->curr_slave_lock); + + if (USES_PRIMARY(bond->params.mode)) { + count = sprintf(buf, "%s\n", (curr) ? curr->dev->name : "None") + 1; + } + else { + count = sprintf(buf, "%s\n", "None") + 1; + } + up_read(&(bonding_rwsem)); + return count; +} + +static ssize_t bonding_store_active_slave(struct class_device *cd, const char *buf, size_t count) +{ + int i; + struct slave *slave; + struct slave *old_active = NULL; + struct slave *new_active = NULL; + struct bonding *bond = to_bond(cd); + + down_write(&(bonding_rwsem)); + + write_lock_bh(&bond->lock); + if (!USES_PRIMARY(bond->params.mode)) { + printk(KERN_INFO DRV_NAME + ": %s: Unable to change active slave; %s is in mode %d\n", + bond->dev->name, bond->dev->name, bond->params.mode); + } else { + bond_for_each_slave(bond, slave, i) { + if (strnicmp + (slave->dev->name, buf, + strlen(slave->dev->name)) == 0) { + old_active = bond->curr_active_slave; + new_active = slave; + if (new_active && (new_active == old_active)) { + /* do nothing */ + printk(KERN_INFO DRV_NAME + ": %s: %s is already the current active slave.\n", + bond->dev->name, slave->dev->name); + goto out; + } + else { + if ((new_active) && + (old_active) && + (new_active->link == BOND_LINK_UP) && + IS_UP(new_active->dev)) { + printk(KERN_INFO DRV_NAME + ": %s: Setting %s as active slave.\n", + bond->dev->name, slave->dev->name); + bond_change_active_slave(bond, new_active); + } + else { + printk(KERN_INFO DRV_NAME + ": %s: Could not set %s as active slave; " + "either %s is down or the link is down.\n", + bond->dev->name, slave->dev->name, + slave->dev->name); + } + goto out; + } + } + } + + /* if we got here, then we didn't match the name of any slave */ + + if (strlen(buf) == 0 || buf[0] == '\n') { + printk(KERN_INFO DRV_NAME + ": %s: Setting active slave to None.\n", + bond->dev->name); + bond->primary_slave = 0; + bond_select_active_slave(bond); + } else { + printk(KERN_INFO DRV_NAME + ": %s: Unable to set %.*s as active slave as it is not a slave.\n", + bond->dev->name, (int)strlen(buf) - 1, buf); + } + } +out: + write_unlock_bh(&bond->lock); + up_write(&(bonding_rwsem)); + return count; + +} +static CLASS_DEVICE_ATTR(active_slave, S_IRUGO | S_IWUSR, bonding_show_active_slave, bonding_store_active_slave); + + +/* + * Show link status of the bond interface. + */ +static ssize_t bonding_show_mii_status(struct class_device *cd, char *buf) +{ + int count; + struct slave *curr; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + + read_lock(&bond->curr_slave_lock); + curr = bond->curr_active_slave; + read_unlock(&bond->curr_slave_lock); + + count = sprintf(buf, "%s\n", (curr) ? "up" : "down") + 1; + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(mii_status, S_IRUGO, bonding_show_mii_status, NULL); + + +/* + * Show current 802.3ad aggregator ID. + */ +static ssize_t bonding_show_ad_aggregator(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.aggregator_id) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_aggregator, S_IRUGO, bonding_show_ad_aggregator, NULL); + + +/* + * Show number of active 802.3ad ports. + */ +static ssize_t bonding_show_ad_num_ports(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0: ad_info.ports) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_num_ports, S_IRUGO, bonding_show_ad_num_ports, NULL); + + +/* + * Show current 802.3ad actor key. + */ +static ssize_t bonding_show_ad_actor_key(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.actor_key) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_actor_key, S_IRUGO, bonding_show_ad_actor_key, NULL); + + +/* + * Show current 802.3ad partner key. + */ +static ssize_t bonding_show_ad_partner_key(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + count = sprintf(buf, "%d\n", (bond_3ad_get_active_agg_info(bond, &ad_info)) ? 0 : ad_info.partner_key) + 1; + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_partner_key, S_IRUGO, bonding_show_ad_partner_key, NULL); + + +/* + * Show current 802.3ad partner mac. + */ +static ssize_t bonding_show_ad_partner_mac(struct class_device *cd, char *buf) +{ + int count = 0; + struct bonding *bond = to_bond(cd); + + down_read(&(bonding_rwsem)); + if (bond->params.mode == BOND_MODE_8023AD) { + struct ad_info ad_info; + if (!bond_3ad_get_active_agg_info(bond, &ad_info)) { + count = sprintf(buf,"%02x:%02x:%02x:%02x:%02x:%02x\n", + ad_info.partner_system[0], + ad_info.partner_system[1], + ad_info.partner_system[2], + ad_info.partner_system[3], + ad_info.partner_system[4], + ad_info.partner_system[5]) + 1; + } + } + up_read(&(bonding_rwsem)); + return count; +} +static CLASS_DEVICE_ATTR(ad_partner_mac, S_IRUGO, bonding_show_ad_partner_mac, NULL); + + + +static struct attribute *per_bond_attrs[] = { + &class_device_attr_slaves.attr, + &class_device_attr_mode.attr, + &class_device_attr_arp_interval.attr, + &class_device_attr_arp_ip_target.attr, + &class_device_attr_down_delay.attr, + &class_device_attr_up_delay.attr, + &class_device_attr_lacp_rate.attr, + &class_device_attr_miimon.attr, + &class_device_attr_primary.attr, + &class_device_attr_use_carrier.attr, + &class_device_attr_active_slave.attr, + &class_device_attr_mii_status.attr, + &class_device_attr_ad_aggregator.attr, + &class_device_attr_ad_num_ports.attr, + &class_device_attr_ad_actor_key.attr, + &class_device_attr_ad_partner_key.attr, + &class_device_attr_ad_partner_mac.attr, + NULL, +}; + +static struct attribute_group bonding_group = { + .name = "bonding", + .attrs = per_bond_attrs, +}; + +/* + * Initialize sysfs. This sets up the bonding_masters file in + * /sys/class/net. + */ +int bond_create_sysfs(void) +{ + int ret = 0; + struct bonding *firstbond; + + init_rwsem(&bonding_rwsem); + + /* get the netdev class pointer */ + firstbond = container_of(bond_dev_list.next, struct bonding, bond_list); + if (!firstbond) + { + return -ENODEV; + + } + netdev_class = firstbond->dev->class_dev.class; + if (!netdev_class) + { + return -ENODEV; + } + ret = class_create_file(netdev_class, &class_attr_bonding_masters); + + return ret; + +} + +/* + * Remove /sys/class/net/bonding_masters. + */ +void bond_destroy_sysfs(void) +{ + if (netdev_class) + class_remove_file(netdev_class, &class_attr_bonding_masters); +} + +/* + * Initialize sysfs for each bond. This sets up and registers + * the 'bondctl' directory for each individual bond under /sys/class/net. + */ +int bond_create_sysfs_entry(struct bonding *bond) +{ + struct net_device *dev = bond->dev; + int err; + + err = sysfs_create_group(&(dev->class_dev.kobj), &bonding_group); + if (err) { + printk(KERN_EMERG "eek! didn't create group!\n"); + } + + return err; +} +/* + * Remove sysfs entries for each bond. + */ +void bond_destroy_sysfs_entry(struct bonding *bond) +{ + struct net_device *dev = bond->dev; + + sysfs_remove_group(&(dev->class_dev.kobj), &bonding_group); +} + diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/Makefile linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/Makefile --- linux-2.6.12-rc2clean/drivers/net/bonding/Makefile 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/Makefile 2005-04-09 11:01:39.000000000 -0700 @@ -4,5 +4,5 @@ obj-$(CONFIG_BONDING) += bonding.o -bonding-objs := bond_main.o bond_3ad.o bond_alb.o +bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o From radheka.godse@intel.com Fri Apr 8 14:54:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 14:54:31 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38LsQpi007935 for ; Fri, 8 Apr 2005 14:54:26 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j38LsFXZ016570; Fri, 8 Apr 2005 21:54:15 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j38LsFgI031913; Fri, 8 Apr 2005 21:54:15 GMT Received: from [134.134.3.231] ([134.134.3.231]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j38LsFSL013154; Fri, 8 Apr 2005 14:54:15 -0700 Date: Fri, 8 Apr 2005 14:53:45 -0700 (PDT) From: Radheka Godse X-X-Sender: radheka@localhost.localdomain To: Radheka Godse cc: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH 2.6.12-rc2 r16/17] bonding: version, date and log update - revised In-Reply-To: Message-ID: References: ReplyTo: "Radheka Godse" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: radheka.godse@intel.com Precedence: bulk X-list: netdev Content-Length: 4331 Lines: 84 >This patch updates the bonding version number and adds entries to >the change log in bond_main. The major version number is changed to 3 >because of the sysfs interface. Revised to reflect sysfs stat file removal change! Signed-off-by: Radheka Godse diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bonding.h --- linux-2.6.12-rc2clean/drivers/net/bonding/bonding.h 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bonding.h 2005-04-09 11:19:27.000000000 -0700 @@ -37,8 +37,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.6.1" -#define DRV_RELDATE "October 29, 2004" +#define DRV_VERSION "3.1.6" +#define DRV_RELDATE "April 8, 2005" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" diff -urN -X dontdiff linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_main.c --- linux-2.6.12-rc2clean/drivers/net/bonding/bond_main.c 2005-04-07 11:24:41.000000000 -0700 +++ linux-2.6.12-rc2-sans_sysfs_stat/drivers/net/bonding/bond_main.c 2005-04-09 11:18:45.000000000 -0700 @@ -475,6 +475,59 @@ * Solution is to move call to dev_remove_pack outside of the * spinlock. * Set version to 2.6.1. + * 2004/12/14 - Mitch Williams + * - Split out bond creation code to allow for future addition of + * sysfs interface. + * - Added extra optional parameter to bond_enslave to return a + * a pointer to the new slave. This will be used by future + * sysfs functionality. + * - Removed static declaration on some functions and data items. + * Set version to 2.6.3 + * 2005/02/10 - Mitch Williams + * - Added sysfs support, including capability to add/remove/change + * any bond at runtime. + * Set version to 3.0.5 + * 2005/02/18 - Radheka Godse + * - Corrected bugs in bond_check_abi_version so sys fs interface can + * be used simultaneously with ifenslave version 1 and above + * Set version to 3.0.7 + * 2005/02/23 - Mitch Williams + * - fixed sysfs bug where the primary could not be cleared + * - ioctls call now grab the sysfs semaphore to prevent race + * conditions if both ifenslave and sysfs are being used + * Set version to 3.0.8 + * 2005/03/18 - Radheka Godse + * - added ifenslave -c type functionality to sysfs + * - split sysfs stat into separate files for attribs such as + * MII Status and 802.3ad aggregator values to sysfs + * - added "name value" format to sysfs "mode" and + * "lacp_rate", for e.g., "active-backup 1" or "slow 0" for + * consistency and ease of script parsing + * - fixed reversal of octets in arp_ip_targets via sysfs + * - added bonding: : prefix to sysfs log messages + * - sysfs support to handle bond interface re-naming + * - Added log messages to reflect/notify changes in updelay and + * downdelay values due to changes to miimon configuration + * - added arp_ip_targets to /proc entry + * - trivial fix: added missing modes description to modinfo + * - made "my_ip" a per bond value instead of a global + * Set version to 3.0.9 + * 2005/03/23 - Mitch Williams + * - Moved all sysfs entries into /sys/class/net instead of + * of using a standalone subsystem. + * - Added sysfs symlinks between masters and slaves + * - Corrected bug in ALB init where kmalloc is called inside + * a held lock + * Set version to 3.1.0 + * 2005/04/08 - Radheka Godse + * - Corrected behaviour to maintain bond link when changing + * from arp monitor to miimon and vice versa + * - Corrected bugs in sysfs unload path when creating bonds + * with existing interface names. + * - Added missing bonding: : prefix to alb, ad log messages + * - Removed redundant sysfs stat file since it duplicates slave info + * from the proc file + * Set version to 3.1.6 * */ From herbert@gondor.apana.org.au Fri Apr 8 15:19:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 15:19:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38MJDjr009360 for ; Fri, 8 Apr 2005 15:19:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK1oU-0000bc-00; Sat, 09 Apr 2005 08:18:54 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK1m9-0005W5-00; Sat, 09 Apr 2005 08:16:29 +1000 Date: Sat, 9 Apr 2005 08:16:29 +1000 To: Jay Vosburgh Cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050408221629.GA21125@gondor.apana.org.au> References: <200504082059.j38KwhaG009173@death.nxdomain.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504082059.j38KwhaG009173@death.nxdomain.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1784 Lines: 45 On Fri, Apr 08, 2005 at 01:58:43PM -0700, Jay Vosburgh wrote: > > There are several paths from a timer context, e.g., > > timer -> bond_mii_monitor -> bond_change_active_slave -> > bond_alb_handle_active_change -> alb_set_slave_mac_addr Is that what it's for. I sense an opportunity for you to greatly clean up this section of code :) The networking drivers are trying to switch over to using netif_carrier_ok as the interface for notification and monitoring of link status. In fact, even the bonding driver appears to do this by default. When you're using netif_carrier_ok, you're relying on the driver itself to monitor the physical status. It will usually do so in its own timer. In other words, it's pointless to examine netif_carrier_ok more often than the underlying driver timer. The standard interface to monitor its status is through a netdev notification (NETDEV_CHANGE). That is called in process context by net/core/link_watch.c. So I'd suggest that we get rid of directly MII monitoring in bonding, and always use netif_carrier_ok. Further more, instead of monitoring that in a timer you just move the code into bond_netdev_event. > As I said above, the timer case doesn't have an obviously good > way to change it to do the MAC sets in a sleepable context with no > locks. I also wonder how expensive it is to run work queue events every > 10ms as compared to running timer events every 10ms? If you really want to keep monitoring the MII status directly, then you can still schedule the changing of the MAC address via a work queue. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 8 15:37:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 15:37:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38MbYkk010379 for ; Fri, 8 Apr 2005 15:37:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK26E-0000jF-00; Sat, 09 Apr 2005 08:37:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK25V-0005Ye-00; Sat, 09 Apr 2005 08:36:29 +1000 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: Fw: Re: 2.6.12-rc2-mm2 Cc: netdev@oss.sgi.com, indrek.kruusa@tuleriit.ee Organization: Core In-Reply-To: <20050408093630.0ff78c67.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 09 Apr 2005 08:36:29 +1000 X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 716 Lines: 23 Andrew Morton wrote: > > dmesg is not clean though: > > TCP: time wait bucket table overflow > TCP: time wait bucket table overflow > TCP: time wait bucket table overflow > printk: 392 messages suppressed. > > What I did: > - "bombing" httpd with JMeter (from another computer) This is normal. The number of TCP connections held by your server in the TIME_WAIT state is exceeding tcp_max_tw_buckets. Check out tcp(7) on what this means and how it may or may not be a problem for you. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From indrek.kruusa@tuleriit.ee Fri Apr 8 16:00:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 16:00:43 -0700 (PDT) Received: from smtp.uninet.ee (smtp.uninet.ee [194.204.0.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38N0bUU011356 for ; Fri, 8 Apr 2005 16:00:37 -0700 Received: from [192.168.0.2] (dsl56-188.uninet.ee [194.204.56.188]) by smtp.uninet.ee (Postfix) with ESMTP id 77179615F3; Sat, 9 Apr 2005 02:00:35 +0300 (EEST) Message-ID: <42570D12.9080802@tuleriit.ee> Date: Sat, 09 Apr 2005 02:00:34 +0300 From: Indrek Kruusa Reply-To: indrek.kruusa@tuleriit.ee User-Agent: Mozilla Thunderbird 1.0 (X11/20050215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: Re: 2.6.12-rc2-mm2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: indrek.kruusa@tuleriit.ee Precedence: bulk X-list: netdev Content-Length: 618 Lines: 29 Herbert Xu wrote: >Andrew Morton wrote: > > >>dmesg is not clean though: >> >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>printk: 392 messages suppressed. >> >>What I did: >>- "bombing" httpd with JMeter (from another computer) >> >> > >This is normal. The number of TCP connections held by >your server in the TIME_WAIT state is exceeding >tcp_max_tw_buckets. > >Check out tcp(7) on what this means and how it may or >may not be a problem for you. > > Thanks for your answer! I'll try to tune this parameter. Indrek From mcr@sandelman.ottawa.on.ca Fri Apr 8 16:45:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 16:45:30 -0700 (PDT) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38NjJnb016189 for ; Fri, 8 Apr 2005 16:45:19 -0700 Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by pike.sandelman.ca (Postfix) with ESMTP id CBFCD63686; Fri, 8 Apr 2005 19:45:15 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C1EAABD9D; Fri, 8 Apr 2005 14:27:33 -0400 (EDT) From: "Michael Richardson" To: Herbert Xu Cc: dev@lists.openswan.org, netdev@oss.sgi.com Subject: tcpdump and UDP encap on 2.6 X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 08 Apr 2005 14:27:33 -0400 Message-ID: <21730.1112984853@marajade.sandelman.ottawa.on.ca> X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 2990 Lines: 98 --=-=-= Herbert, I think that there is a bug/mis-feature in net/ipv4/udp.c. The skb is modified without having checked if it is in fact shared/cloned. The result is that tcpdump sees the wrong thing. This can be confusing: First, get the latest tcpdump 3.9 beta (-096), which decodes UDP port 4500 packets. If I tcpdump on the incoming interface, without the ESP_IN_UDP option set (openswan "ikeping" has an option to turn this on): west:/testing/klips/west-natt-01# jobs [2]- Running tcpdump-3.9 -i eth1 -n -p & [3]+ Running ipsec ikeping --listen --ikeport 4500 & west:/testing/klips/west-natt-01# received 36() packet from 192.1.2.23/4500 of len: 116 rcookie=78563412_0f000000 icookie=353bc42c_e2464cf2 msgid=8cf7b22e np=239 version=13.7 xchg=(36) 18:11:00.673351 IP 192.1.2.23.4500 > 192.1.2.45.4500: UDP-encap: ESP(spi=0x12345678,seq=0xf), length 116 I'm clearly getting an UDP encapsulated packet. west:/testing/klips/west-natt-01# jobs [2]- Running tcpdump-3.9 -i eth1 -n -p & [3]+ Running ipsec ikeping --listen --ikeport 4500 --nat-t & west:/testing/klips/west-natt-01# 18:12:01.795291 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x11941194,seq=0x7c0000), length 116 Notice how the packet has been mangled before being passed to tcpdump. This is a problem for anyone trying to debug what's going on. I think that this fixes the problem. I must admit to being a bit ignorant as to which PRIO might be appropriate here. Also is there a good FAQ on the difference between cloned SKBs vs shared SKBs? --- /distros/kernel/linux-2.6.11.2/net/ipv4/udp.c 2005-03-09 03:11:09.000000000 -0500 +++ linux/net/ipv4/udp.c 2005-04-08 14:22:53.000000000 -0400 @@ -897,8 +897,9 @@ * 0 if we should drop this packet * -1 if it should get processed by xfrm4_rcv_encap */ -static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb) +static int udp_encap_rcv(struct sock * sk, struct sk_buff **pskb) { + struct sk_buff *skb = *pskb; #ifndef CONFIG_XFRM return 1; #else @@ -968,11 +969,14 @@ * transport header to point to ESP. Keep UDP on the stack * for later. */ + skb = skb_unshare(skb, 0); skb->h.raw = skb_pull(skb, len); /* modify the protocol (it's ESP!) */ iph->protocol = IPPROTO_ESP; + *pskb = skb; + /* and let the caller know to send this into the ESP processor... */ return -1; #endif @@ -1010,7 +1014,7 @@ */ int ret; - ret = udp_encap_rcv(sk, skb); + ret = udp_encap_rcv(sk, &skb); if (ret == 0) { /* Eat the packet .. */ kfree_skb(skb); --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUAQlbNFYqHRg3pndX9AQF+6AQA6CDPtnb+JDg4z8GFjjT3qxGvQfdOxn5y lhV8XeN53hStUK8xYbdLbBv1emRyaYXGMxy+xCY85U0xDLvsn4HkjFLDWdnP4Cb3 qkVuVs2UHtIeY0RAniAcjiTclWeBN8nGep2WYnwLXIwCVp5yUL8la5Ff0YpC3V8s Z5BUY4l2gk0= =2boW -----END PGP SIGNATURE----- --=-=-=-- From fubar@us.ibm.com Fri Apr 8 16:56:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 16:57:03 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38Numcb016979 for ; Fri, 8 Apr 2005 16:56:57 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j38Nuh5b523554 for ; Fri, 8 Apr 2005 19:56:43 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j38NuhvE194552 for ; Fri, 8 Apr 2005 17:56:43 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j38NugRG007615 for ; Fri, 8 Apr 2005 17:56:42 -0600 Received: from death.nxdomain.ibm.com (lig32-225-151-131.us.lig-dial.ibm.com [32.225.151.131]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j38NuP0I007000; Fri, 8 Apr 2005 17:56:41 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j38NuHNn010157; Fri, 8 Apr 2005 16:56:17 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j38Ntr7k010144; Fri, 8 Apr 2005 16:56:13 -0700 Message-Id: <200504082356.j38Ntr7k010144@death.nxdomain.ibm.com> To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address In-Reply-To: Message from Herbert Xu of "Sat, 09 Apr 2005 08:16:29 +1000." <20050408221629.GA21125@gondor.apana.org.au> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 08 Apr 2005 16:55:53 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2733 Lines: 61 Herbert Xu wrote: [...] >The networking drivers are trying to switch over to using >netif_carrier_ok as the interface for notification and >monitoring of link status. In fact, even the bonding driver >appears to do this by default. Yep. It's been that way for a couple of years, as I recall. [...] >In other words, it's pointless to examine netif_carrier_ok >more often than the underlying driver timer. The standard >interface to monitor its status is through a netdev >notification (NETDEV_CHANGE). That is called in process >context by net/core/link_watch.c. Looking at link_watch.c, it appears that it issues events on a one second timer, so there could be a lag of up to one second between the time a driver does "netif_carrier_off" and the time bonding would receive the event from link_watch. So, yes, it's pointless to check netif_carrier more often that the driver updates it, but it's not pointless to check netif_carrier on a timer if the granularity of events from link_watch is too slow (which it appears to be for a "hot standby" type of application). >So I'd suggest that we get rid of directly MII monitoring in >bonding, and always use netif_carrier_ok. Further more, >instead of monitoring that in a timer you just move the code >into bond_netdev_event. The direct MII monitor option has stayed because some drivers update netif_carrier at fairly long intervals; the extreme example is 3c59x, which checks every 60 seconds. For a hot standby use, even one second is a pretty long time. FWIW, It's been a while since a user has reported trouble with bonding link detection with a driver because it didn't support netif_carrier; lately, when it comes up it's the notification interval. We've also not been discussing the bonding "arp monitor," which does link integrity checking by means of detecting traffic flow across the link(s) (generating traffic, via ARP requests, when the link is idle). It will trigger the same kinds of failovers that the mii monitor does; the saving grace right now is that it doesn't currently run with the alb/tlb modes that do the MAC address swapping from the failover. My other question here is how much time is there left to get changes for this into 2.6.12? Rearchitecting the link monitor / failover gizmos is reasonably nontrivial; I don't know if it's feasible to make those kind of substantial changes this late in the cycle. So, either 2.6.12 goes out with the potential sleep from timer / with lock, the bonding MAC notifier change is partially backed out, the "gfp_any()" change goes into rtnetlink.c, or some other solution that eludes me occurs. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From herbert@gondor.apana.org.au Fri Apr 8 17:24:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 17:24:39 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j390OOov018009 for ; Fri, 8 Apr 2005 17:24:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK3lY-0001Oq-00; Sat, 09 Apr 2005 10:24:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK3jG-0005hJ-00; Sat, 09 Apr 2005 10:21:38 +1000 Date: Sat, 9 Apr 2005 10:21:37 +1000 To: Jay Vosburgh Cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050409002137.GA21726@gondor.apana.org.au> References: <20050408221629.GA21125@gondor.apana.org.au> <200504082356.j38Ntr7k010144@death.nxdomain.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504082356.j38Ntr7k010144@death.nxdomain.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2730 Lines: 61 On Fri, Apr 08, 2005 at 04:55:53PM -0700, Jay Vosburgh wrote: > > Looking at link_watch.c, it appears that it issues events on a > one second timer, so there could be a lag of up to one second between > the time a driver does "netif_carrier_off" and the time bonding would > receive the event from link_watch. Events are delivered immediately except when there are multiple failures within a second. Even then it will delay the subsequent failures only if they occured after the queue run has already started. Remember that whenever the queue run does trigger, it will update all devices that's on the linked list. We can easily change this to do something different if it really bothers you. > The direct MII monitor option has stayed because some drivers > update netif_carrier at fairly long intervals; the extreme example is > 3c59x, which checks every 60 seconds. For a hot standby use, even one > second is a pretty long time. Wouldn't it be better to modify those drivers so that they updated their status more frequently? That way everybody would benefit and not just bonding. > We've also not been discussing the bonding "arp monitor," which > does link integrity checking by means of detecting traffic flow across > the link(s) (generating traffic, via ARP requests, when the link is > idle). It will trigger the same kinds of failovers that the mii monitor > does; the saving grace right now is that it doesn't currently run with > the alb/tlb modes that do the MAC address swapping from the failover. The ARP monitor would presumably start changing MAC addresses only after a longish timeout. In that event, I don't see any problems with delaying it a little bit more by putting it into a work queue. > My other question here is how much time is there left to get > changes for this into 2.6.12? Rearchitecting the link monitor / > failover gizmos is reasonably nontrivial; I don't know if it's feasible > to make those kind of substantial changes this late in the cycle. So, > either 2.6.12 goes out with the potential sleep from timer / with lock, > the bonding MAC notifier change is partially backed out, the "gfp_any()" > change goes into rtnetlink.c, or some other solution that eludes me > occurs. It's up to Dave of course. Personally I'd rather we aimed for a proper solution that will be in 2.6.13 since the current symptom is only a warning which doesn't really hurt anyone. After all, we have lived with this problem for years so a few more weeks can't be fatal :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 8 17:31:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 17:31:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j390Vm1F018681 for ; Fri, 8 Apr 2005 17:31:49 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK3so-0001VN-00; Sat, 09 Apr 2005 10:31:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK3sS-0005iZ-00; Sat, 09 Apr 2005 10:31:08 +1000 Date: Sat, 9 Apr 2005 10:31:08 +1000 To: Jay Vosburgh Cc: davem@davemloft.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050409003108.GA21962@gondor.apana.org.au> References: <20050408221629.GA21125@gondor.apana.org.au> <200504082356.j38Ntr7k010144@death.nxdomain.ibm.com> <20050409002137.GA21726@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050409002137.GA21726@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 914 Lines: 24 On Sat, Apr 09, 2005 at 10:21:37AM +1000, herbert wrote: > > Personally I'd rather we aimed for a proper solution that will be in > 2.6.13 since the current symptom is only a warning which doesn't > really hurt anyone. Actually there is another reason why we need to move the MAC setting to process context rather than simply patching up the rtnetlink code. The driver implementation for set_mac_address may well want to sleep since it needs to communicate with the hardware. In fact I just looked at some USB net drivers and the very first one (zd1201) wants to sleep in there badly :) So if you want a quick and dirty fix, why not make bonding call dev_set_mac_address from a work queue? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 8 18:02:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 18:02:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3912bux019760 for ; Fri, 8 Apr 2005 18:02:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK4MS-0001eP-00; Sat, 09 Apr 2005 11:02:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK4Lk-0005np-00; Sat, 09 Apr 2005 11:01:24 +1000 Date: Sat, 9 Apr 2005 11:01:24 +1000 To: Michael Richardson Cc: dev@lists.openswan.org, netdev@oss.sgi.com, "David S. Miller" Subject: [IPSEC] COW skb header in UDP decap Message-ID: <20050409010124.GA22059@gondor.apana.org.au> References: <21730.1112984853@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <21730.1112984853@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2660 Lines: 74 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Michael: On Fri, Apr 08, 2005 at 02:27:33PM -0400, Michael Richardson wrote: > > Herbert, I think that there is a bug/mis-feature in net/ipv4/udp.c. > The skb is modified without having checked if it is in fact shared/cloned. > The result is that tcpdump sees the wrong thing. This can be confusing: Indeed, it's not just confusing but wrong :) This violates the laws of skb's. > I think that this fixes the problem. I must admit to being a bit Thanks for the patch. I think we can use something a little lighter than skb_unshare. The following patch just makes the header part of the skb writeable. This is needed since we modify the IP headers just a few lines below. Signed-off-by: Herbert Xu > ignorant as to which PRIO might be appropriate here. Also is there a > good FAQ on the difference between cloned SKBs vs shared SKBs? There might be, but the source is the ultimate documentation :) Shared skb's are the same object held by multiple users. No one must write to either the metadata or the data without the consent of everyone involved. Clone skb's only share the data. The metadata can be written freely. To get a completely standalone skb from a cloned skb, you can call skb_copy. However, it is pretty heavy weight and also copies the metadata which isn't necessary for skb's which are cloned but not shared. That's why we have pskb_expand_head (and its wrapper skb_cow) which can be used when you only need to modify the bits between skb->head and skb->tail (this is what we call the header of the skb, don't confuse it with the protocol header of a packet). As it doesn't copy the metadata, you can't call it on shared skb's. However, you can always clone it and then do pskb_expand_head. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/udp.c 1.78 vs edited ===== --- 1.78/net/ipv4/udp.c 2005-03-27 09:04:35 +10:00 +++ edited/net/ipv4/udp.c 2005-04-09 10:39:05 +10:00 @@ -955,6 +955,8 @@ * header and optional ESP marker bytes) and then modify the * protocol to ESP, and then call into the transform receiver. */ + if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + return 0; /* Now we can update and verify the packet length... */ iph = skb->nh.iph; --rwEMma7ioTxnRzrJ-- From herbert@gondor.apana.org.au Fri Apr 8 18:45:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 18:45:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j391jXc3020996 for ; Fri, 8 Apr 2005 18:45:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DK52B-0001t8-00; Sat, 09 Apr 2005 11:45:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DK51j-0005sz-00; Sat, 09 Apr 2005 11:44:47 +1000 Date: Sat, 9 Apr 2005 11:44:47 +1000 To: Dmitry Yusupov Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050409014447.GA22607@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> <1112917001.3893.77.camel@beastie> <20050408113654.GA26095@gondor.apana.org.au> <1112974214.17165.8.camel@mylaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112974214.17165.8.camel@mylaptop> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 576 Lines: 15 On Fri, Apr 08, 2005 at 08:30:14AM -0700, Dmitry Yusupov wrote: > > This is ideally how it should be for sendmsg paths. socket applications > like iscsi, nbd, etc will use it for TCP/IP type of socket. iscsi could > re-use the same generic "emergency pool" code for netlink. In that case we'll wait for the resolution of the discussion on TCP itself, OK? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 9 03:57:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 03:57:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39AvJi2008817 for ; Sat, 9 Apr 2005 03:57:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKDdp-0003x4-00; Sat, 09 Apr 2005 20:56:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKDc4-0001st-00; Sat, 09 Apr 2005 20:54:52 +1000 Date: Sat, 9 Apr 2005 20:54:52 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [1/4] [IPSEC] Improve xfrm to pfkey SA state conversion Message-ID: <20050409105452.GA7171@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <1112702604.1089.119.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2062 Lines: 63 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This series of patches will fix the spurious state/policy expire notification problem identified in the discussion regarding Jamal's IPsec events patch. It will also address other minor issues arising from the events patch. The first patch adjusts the SA state conversion in af_key such that XFRM_STATE_ERROR/XFRM_STATE_DEAD will be converted to SADB_STATE_DEAD instead of SADB_STATE_DYING. According to RFC 2367, SADB_STATE_DYING SAs can be turned into mature ones through updating their lifetime settings. Since SAs which are in the states XFRM_STATE_ERROR/XFRM_STATE_DEAD cannot be resurrected, this value is unsuitable. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-1 ===== net/key/af_key.c 1.73 vs edited ===== --- 1.73/net/key/af_key.c 2005-04-08 23:08:26 +10:00 +++ edited/net/key/af_key.c 2005-04-09 14:15:45 +10:00 @@ -656,13 +656,18 @@ sa->sadb_sa_exttype = SADB_EXT_SA; sa->sadb_sa_spi = x->id.spi; sa->sadb_sa_replay = x->props.replay_window; - sa->sadb_sa_state = SADB_SASTATE_DYING; - if (x->km.state == XFRM_STATE_VALID && !x->km.dying) - sa->sadb_sa_state = SADB_SASTATE_MATURE; - else if (x->km.state == XFRM_STATE_ACQ) + switch (x->km.state) { + case XFRM_STATE_VALID: + sa->sadb_sa_state = x->km.dying ? + SADB_SASTATE_DYING : SADB_SASTATE_MATURE; + break; + case XFRM_STATE_ACQ: sa->sadb_sa_state = SADB_SASTATE_LARVAL; - else if (x->km.state == XFRM_STATE_EXPIRED) + break; + default: sa->sadb_sa_state = SADB_SASTATE_DEAD; + break; + } sa->sadb_sa_auth = 0; if (x->aalg) { struct xfrm_algo_desc *a = xfrm_aalg_get_byname(x->aalg->alg_name, 0); --CE+1k2dSO48ffgeK-- From herbert@gondor.apana.org.au Sat Apr 9 04:14:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 04:14:45 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39BETao010249 for ; Sat, 9 Apr 2005 04:14:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKDuZ-00044V-00; Sat, 09 Apr 2005 21:13:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKDtM-0001ug-00; Sat, 09 Apr 2005 21:12:44 +1000 Date: Sat, 9 Apr 2005 21:12:44 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050409111244.GB7171@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20050409105452.GA7171@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4377 Lines: 155 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch ensures that the hard state/policy expire notifications are only sent when the state/policy is successfully removed from their respective tables. As it is, it's possible for a state/policy to both expire through reaching a hard limit, as well as being deleted by the user. Note that this behaviour isn't actually forbidden by RFC 2367. However, it is a quality of implementation issue. As an added bonus, the restructuring in this patch will help eventually in moving the expire notifications from softirq context into process context, thus improving their reliability. One important side-effect from this change is that SAs reaching their hard byte/packet limits are now deleted immediately, just like SAs that have reached their hard time limits. Previously they were announced immediately but only deleted after 30 seconds. This is bad because it prevents the system from issuing an ACQUIRE command until the existing state was deleted by the user or expires after the time is up. In the scenario where the expire notification was lost this introduces a 30 second delay into the system for no good reason. Signed-off-by: Herbert Xu include/net/xfrm.h | 2 +- net/xfrm/xfrm_policy.c | 8 +++++--- net/xfrm/xfrm_state.c | 16 +++++++--------- 3 files changed, 13 insertions(+), 13 deletions(-) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-2 ===== include/net/xfrm.h 1.80 vs edited ===== --- 1.80/include/net/xfrm.h 2005-04-08 23:08:26 +10:00 +++ edited/include/net/xfrm.h 2005-04-09 17:55:24 +10:00 @@ -669,7 +669,7 @@ return 0; } -extern void xfrm_policy_delete(struct xfrm_policy *pol, int dir); +extern int xfrm_policy_delete(struct xfrm_policy *pol, int dir); static inline void xfrm_sk_free_policy(struct sock *sk) { ===== net/xfrm/xfrm_policy.c 1.75 vs edited ===== --- 1.75/net/xfrm/xfrm_policy.c 2005-04-01 16:24:20 +10:00 +++ edited/net/xfrm/xfrm_policy.c 2005-04-09 18:02:53 +10:00 @@ -216,8 +216,8 @@ expired: read_unlock(&xp->lock); - km_policy_expired(xp, dir, 1); - xfrm_policy_delete(xp, dir); + if (!xfrm_policy_delete(xp, dir)) + km_policy_expired(xp, dir, 1); xfrm_pol_put(xp); } @@ -555,7 +555,7 @@ return NULL; } -void xfrm_policy_delete(struct xfrm_policy *pol, int dir) +int xfrm_policy_delete(struct xfrm_policy *pol, int dir) { write_lock_bh(&xfrm_policy_lock); pol = __xfrm_policy_unlink(pol, dir); @@ -564,7 +564,9 @@ if (dir < XFRM_POLICY_MAX) atomic_inc(&flow_cache_genid); xfrm_policy_kill(pol); + return 0; } + return -ENOENT; } int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol) ===== net/xfrm/xfrm_state.c 1.61 vs edited ===== --- 1.61/net/xfrm/xfrm_state.c 2005-04-08 23:08:26 +10:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-09 19:55:48 +10:00 @@ -154,6 +154,7 @@ next = tmo; } + x->km.dying = warn; if (warn) km_state_expired(x, 0); resched: @@ -169,9 +170,8 @@ next = 2; goto resched; } - if (x->id.spi != 0) + if (!__xfrm_state_delete(x) && x->id.spi) km_state_expired(x, 1); - __xfrm_state_delete(x); out: spin_unlock(&x->lock); @@ -566,16 +566,18 @@ if (x->curlft.bytes >= x->lft.hard_byte_limit || x->curlft.packets >= x->lft.hard_packet_limit) { - km_state_expired(x, 1); - if (!mod_timer(&x->timer, jiffies + XFRM_ACQ_EXPIRES*HZ)) + x->km.state = XFRM_STATE_EXPIRED; + if (!mod_timer(&x->timer, jiffies)) xfrm_state_hold(x); return -EINVAL; } if (!x->km.dying && (x->curlft.bytes >= x->lft.soft_byte_limit || - x->curlft.packets >= x->lft.soft_packet_limit)) + x->curlft.packets >= x->lft.soft_packet_limit)) { + x->km.dying = 1; km_state_expired(x, 0); + } return 0; } EXPORT_SYMBOL(xfrm_state_check_expire); @@ -833,10 +835,6 @@ { struct km_event c; - if (hard) - x->km.state = XFRM_STATE_EXPIRED; - else - x->km.dying = 1; c.data = hard; c.event = XFRM_SAP_EXPIRED; km_state_notify(x, &c); --XF85m9dhOBO43t/C-- From herbert@gondor.apana.org.au Sat Apr 9 04:16:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 04:16:31 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39BGFVV010760 for ; Sat, 9 Apr 2005 04:16:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKDwT-000464-00; Sat, 09 Apr 2005 21:15:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKDwN-0001vR-00; Sat, 09 Apr 2005 21:15:51 +1000 Date: Sat, 9 Apr 2005 21:15:51 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [3/4] [IPSEC] Turn km_event.data into a union Message-ID: <20050409111551.GA7378@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20050409111244.GB7171@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4546 Lines: 178 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch turns km_event.data into a union. This makes code that uses it clearer. Signed-off-by: Herbert Xu include/net/xfrm.h | 7 ++++++- net/key/af_key.c | 17 +++++------------ net/xfrm/xfrm_state.c | 5 ++--- net/xfrm/xfrm_user.c | 10 +++++----- 4 files changed, 18 insertions(+), 21 deletions(-) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-3 ===== include/net/xfrm.h 1.81 vs edited ===== --- 1.81/include/net/xfrm.h 2005-04-09 20:21:15 +10:00 +++ edited/include/net/xfrm.h 2005-04-09 20:37:05 +10:00 @@ -172,7 +172,12 @@ /* callback structure passed from either netlink or pfkey */ struct km_event { - u32 data; + union { + u32 hard; + u32 proto; + u32 byid; + } data; + u32 seq; u32 pid; u32 event; ===== net/key/af_key.c 1.74 vs edited ===== --- 1.74/net/key/af_key.c 2005-04-09 14:39:58 +10:00 +++ edited/net/key/af_key.c 2005-04-09 20:32:54 +10:00 @@ -1293,13 +1293,6 @@ if (c->event == XFRM_SAP_DELETED) hsc = 0; - if (c->event == XFRM_SAP_EXPIRED) { - if (c->data) - hsc = 2; - else - hsc = 1; - } - skb = pfkey_xfrm_state2msg(x, 0, hsc); if (IS_ERR(skb)) @@ -1534,7 +1527,7 @@ if (!skb) return -ENOBUFS; hdr = (struct sadb_msg *) skb_put(skb, sizeof(struct sadb_msg)); - hdr->sadb_msg_satype = pfkey_proto2satype(c->data); + hdr->sadb_msg_satype = pfkey_proto2satype(c->data.proto); hdr->sadb_msg_seq = c->seq; hdr->sadb_msg_pid = c->pid; hdr->sadb_msg_version = PF_KEY_V2; @@ -1556,7 +1549,7 @@ return -EINVAL; xfrm_state_flush(proto); - c.data = proto; + c.data.proto = proto; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; c.event = XFRM_SAP_FLUSHED; @@ -1969,7 +1962,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = PF_KEY_V2; - if (c->data && c->event == XFRM_SAP_DELETED) + if (c->data.byid && c->event == XFRM_SAP_DELETED) out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; else out_hdr->sadb_msg_type = event2poltype(c->event); @@ -2183,7 +2176,7 @@ c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { - c.data = 1; // to signal pfkey of SADB_X_SPDDELETE2 + c.data.byid = 1; c.event = XFRM_SAP_DELETED; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); } else { @@ -2463,7 +2456,7 @@ int hard; int hsc; - hard = c->data; + hard = c->data.hard; if (hard) hsc = 2; else ===== net/xfrm/xfrm_state.c 1.62 vs edited ===== --- 1.62/net/xfrm/xfrm_state.c 2005-04-09 20:21:15 +10:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-09 20:38:54 +10:00 @@ -835,7 +835,7 @@ { struct km_event c; - c.data = hard; + c.data.hard = hard; c.event = XFRM_SAP_EXPIRED; km_state_notify(x, &c); @@ -883,8 +883,7 @@ { struct km_event c; - c.data = hard; - c.data = hard; + c.data.hard = hard; c.event = XFRM_SAP_EXPIRED; km_policy_notify(pol, dir, &c); ===== net/xfrm/xfrm_user.c 1.53 vs edited ===== --- 1.53/net/xfrm/xfrm_user.c 2005-04-08 23:08:26 +10:00 +++ edited/net/xfrm/xfrm_user.c 2005-04-09 20:35:06 +10:00 @@ -894,7 +894,7 @@ struct xfrm_usersa_flush *p = NLMSG_DATA(nlh); xfrm_state_flush(p->proto); - c.data = p->proto; + c.data.proto = p->proto; c.event = XFRM_SAP_FLUSHED; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; @@ -1116,13 +1116,13 @@ static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c) { struct sk_buff *skb; - int hard = c ->data; + /* fix to do alloc using NLM macros */ skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; - if (build_expire(skb, x, hard) < 0) + if (build_expire(skb, x, c->data.hard) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; @@ -1148,7 +1148,7 @@ nlh->nlmsg_flags = 0; p = NLMSG_DATA(nlh); - p->proto = c->data; + p->proto = c->data.proto; nlh->nlmsg_len = skb->tail - b; @@ -1391,7 +1391,7 @@ if (skb == NULL) return -ENOMEM; - if (build_polexpire(skb, xp, dir, c->data) < 0) + if (build_polexpire(skb, xp, dir, c->data.hard) < 0) BUG(); NETLINK_CB(skb).dst_groups = XFRMGRP_EXPIRE; --cNdxnHkX5QqsyA0e-- From hadi@cyberus.ca Sat Apr 9 05:30:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 05:30:59 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39CUsZB016704 for ; Sat, 9 Apr 2005 05:30:55 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DKF6w-0008Ae-Qt for netdev@oss.sgi.com; Sat, 09 Apr 2005 08:30:50 -0400 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 1DKF6t-0001Qh-Ro; Sat, 09 Apr 2005 08:30:48 -0400 Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050409111244.GB7171@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113049844.1090.23.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Apr 2005 08:30:44 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1611 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: 851 Lines: 31 Herbert, This is nice since it seems to go on top of the patch i posted. I didnt get an ACK from Dave - so i assumed that patch is not on his tree yet. Which tree are you using? Small comment below: On Sat, 2005-04-09 at 07:12, Herbert Xu wrote: > ===== net/xfrm/xfrm_policy.c 1.75 vs edited ===== > --- 1.75/net/xfrm/xfrm_policy.c 2005-04-01 16:24:20 +10:00 > +++ edited/net/xfrm/xfrm_policy.c 2005-04-09 18:02:53 +10:00 > @@ -216,8 +216,8 @@ > > expired: > read_unlock(&xp->lock); > - km_policy_expired(xp, dir, 1); > - xfrm_policy_delete(xp, dir); > + if (!xfrm_policy_delete(xp, dir)) > + km_policy_expired(xp, dir, 1); > xfrm_pol_put(xp);> > } > If the policy was already dead you will still return a 0 from xfrm_policy_delete(). Fixable by policy_kill returning an int. cheers, jamal From joern@wohnheim.fh-wedel.de Sat Apr 9 06:52:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 06:52:24 -0700 (PDT) Received: from moskovskaya.fh-wedel.de (mail.fh-wedel.de [213.39.232.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39DqHYr018915 for ; Sat, 9 Apr 2005 06:52:19 -0700 Received: from wohnheim.fh-wedel.de ([213.39.233.138]:46365) by moskovskaya.fh-wedel.de with esmtp (Exim 4.34) id 1DKGNV-0004EF-9C; Sat, 09 Apr 2005 15:52:01 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1DKGNZ-0003Ss-00; Sat, 09 Apr 2005 15:52:05 +0200 Date: Sat, 9 Apr 2005 15:52:05 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Pavel Machek Cc: Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] s390: claw network device driver Message-ID: <20050409135205.GA13305@wohnheim.fh-wedel.de> References: <200503290533.j2T5XEYT028850@hera.kernel.org> <4248FBFD.5000809@pobox.com> <20050328230830.5e90396f.akpm@osdl.org> <20050329071002.GA16204@havoc.gtf.org> <20050329152057.GA27840@wohnheim.fh-wedel.de> <4249B52C.2000300@pobox.com> <20050408201606.GA1429@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050408201606.GA1429@elf.ucw.cz> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 625 Lines: 22 On Fri, 8 April 2005 22:16:07 +0200, Pavel Machek wrote: > > More importantly, it is still listed as "the list" for network > drivers... > > NETWORK DEVICE DRIVERS > P: Andrew Morton > M: akpm@osdl.org > P: Jeff Garzik > M: jgarzik@pobox.com > L: linux-net@vger.kernel.org > S: Maintained Maybe one of the two maintainers might want to change that? ;) Jörn -- There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare From indrek.kruusa@tuleriit.ee Sat Apr 9 08:07:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 08:08:00 -0700 (PDT) Received: from smtp.uninet.ee (smtp.uninet.ee [194.204.0.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39F7spx020938 for ; Sat, 9 Apr 2005 08:07:54 -0700 Received: from [192.168.0.2] (dsl56-188.uninet.ee [194.204.56.188]) by smtp.uninet.ee (Postfix) with ESMTP id B1AC261711; Sat, 9 Apr 2005 18:07:52 +0300 (EEST) Message-ID: <4257EFC8.3060804@tuleriit.ee> Date: Sat, 09 Apr 2005 18:07:52 +0300 From: Indrek Kruusa Reply-To: indrek.kruusa@tuleriit.ee User-Agent: Mozilla Thunderbird 1.0 (X11/20050215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: Re: 2.6.12-rc2-mm2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: indrek.kruusa@tuleriit.ee Precedence: bulk X-list: netdev Content-Length: 1271 Lines: 47 Herbert Xu wrote: >Andrew Morton wrote: > > >>dmesg is not clean though: >> >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>printk: 392 messages suppressed. >> >>What I did: >>- "bombing" httpd with JMeter (from another computer) >> >> > >This is normal. The number of TCP connections held by >your server in the TIME_WAIT state is exceeding >tcp_max_tw_buckets. > >Check out tcp(7) on what this means and how it may or >may not be a problem for you. > > This poor Celeron machine has only 128MB RAM and tcp_max_tw_buckets were calculated (ipv4/tcp.c) to be 16384. I have found that increasing this number by 2048 (that's 12.5%) = 18432 is enough to not get this overflow warning again (load average was over 90). Some other facts: - my current machine has 512MB RAM and calculated tcp_max_tw_buckets is 180000 (!) - from Documentation/networking/ip-sysctl.txt: This limit exists only to prevent simple DoS attacks I believe that those values are somewhat miscalculated. At least by changing calculation for machines with low memory a bit you will get some defence against poor shouting students who had to build load-balancing web-clusters ;) thanks, Indrek From christoph@graphe.net Sat Apr 9 08:28:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 08:28:58 -0700 (PDT) Received: from graphe.net (graphe.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39FSpm5026447 for ; Sat, 9 Apr 2005 08:28:52 -0700 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.50) id 1DKHsb-000479-F9; Sat, 09 Apr 2005 08:28:15 -0700 Date: Sat, 9 Apr 2005 08:28:13 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy? In-Reply-To: <20050408214529.GA29716@gondor.apana.org.au> Message-ID: References: <20050406111721.3ac67605.davem@davemloft.net> <20050407110724.GA8760@gondor.apana.org.au> <20050407212504.GA4939@gondor.apana.org.au> <20050408054831.GA569@gondor.apana.org.au> <20050408214529.GA29716@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 2134 Lines: 77 On Sat, 9 Apr 2005, Herbert Xu wrote: > Anyway, here is my last patch again. And here is my fixed up one: Index: linux-2.6.11/net/core/dst.c =================================================================== --- linux-2.6.11.orig/net/core/dst.c 2005-03-01 23:38:12.000000000 -0800 +++ linux-2.6.11/net/core/dst.c 2005-04-09 08:25:13.000000000 -0700 @@ -169,9 +169,8 @@ struct dst_entry *dst_destroy(struct dst struct neighbour *neigh; struct hh_cache *hh; - smp_rmb(); - again: + smp_rmb(); neigh = dst->neighbour; hh = dst->hh; child = dst->child; @@ -191,23 +190,46 @@ again: dst->ops->destroy(dst); if (dst->dev) dev_put(dst->dev); -#if RT_CACHE_DEBUG >= 2 +#if RT_CACHE_DEBUG >= 2 atomic_dec(&dst_total); #endif kmem_cache_free(dst->ops->kmem_cachep, dst); dst = child; if (dst) { - if (atomic_dec_and_test(&dst->__refcnt)) { - /* We were real parent of this dst, so kill child. */ - if (dst->flags&DST_NOHASH) + /* + * Note that the check for NO_HASH must be done before + * decrementing the __refcnt. If __refcnt reaches zero + * then the dst entry may be freed immediately by the gc + * running on another cpu. Therefore no field of the dst + * entry may be accessed after decrementing __refcnt + */ + if (dst->flags&DST_NOHASH) { + /* + * The child is not on a hash table or on the gc list. + * We are the owner and are the only ones who could + * free the dst. There is no possibility of racing + * with the gc code. + */ + atomic_dec(&dst->__refcnt); + if (!atomic_read(&dst->__refcnt)) + /* + * There are no other references and therefore + * the dst can be freed now + */ goto again; - } else { - /* Child is still referenced, return it for freeing. */ - if (dst->flags&DST_NOHASH) - return dst; - /* Child is still in his hash table */ + + /* + * Child is still referenced and will be put on the gc + * list by the function invoking dst_destroy. + */ + return dst; } + + /* + * Child is on the hash table. Just decrement the use counter. + */ + atomic_dec(&dst->__refcnt); } return NULL; } From dmitry_yus@yahoo.com Sat Apr 9 09:03:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 09:03:05 -0700 (PDT) Received: from smtp107.mail.sc5.yahoo.com (smtp107.mail.sc5.yahoo.com [66.163.169.227]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j39G30fB027703 for ; Sat, 9 Apr 2005 09:03:01 -0700 Received: from unknown (HELO beastie) (dmitry?yus@67.120.213.161 with plain) by smtp107.mail.sc5.yahoo.com with SMTP; 9 Apr 2005 16:03:00 -0000 Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event From: Dmitry Yusupov To: Herbert Xu Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net In-Reply-To: <20050409014447.GA22607@gondor.apana.org.au> References: <42540CF3.7070501@cs.wisc.edu> <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> <1112917001.3893.77.camel@beastie> <20050408113654.GA26095@gondor.apana.org.au> <1112974214.17165.8.camel@mylaptop> <20050409014447.GA22607@gondor.apana.org.au> Content-Type: text/plain Date: Sat, 09 Apr 2005 09:02:59 -0700 Message-Id: <1113062579.3893.110.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry_yus@yahoo.com Precedence: bulk X-list: netdev Content-Length: 639 Lines: 15 On Sat, 2005-04-09 at 11:44 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:30:14AM -0700, Dmitry Yusupov wrote: > > > > This is ideally how it should be for sendmsg paths. socket applications > > like iscsi, nbd, etc will use it for TCP/IP type of socket. iscsi could > > re-use the same generic "emergency pool" code for netlink. > > In that case we'll wait for the resolution of the discussion on TCP > itself, OK? "emergency pool" is a big and generic feature, needs design and resolution. it could definitely wait. Do you have something against one liner patch for using sk->sk_allocation instead of hard-coded vm priority? From indrek.kruusa@tuleriit.ee Sat Apr 9 09:14:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 09:14:30 -0700 (PDT) Received: from smtp.uninet.ee (smtp.uninet.ee [194.204.0.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39GEMEa028453 for ; Sat, 9 Apr 2005 09:14:24 -0700 Received: from [192.168.0.2] (dsl56-188.uninet.ee [194.204.56.188]) by smtp.uninet.ee (Postfix) with ESMTP id 061B86174B; Sat, 9 Apr 2005 19:14:21 +0300 (EEST) Message-ID: <4257FF5C.2050609@tuleriit.ee> Date: Sat, 09 Apr 2005 19:14:20 +0300 From: Indrek Kruusa Reply-To: indrek.kruusa@tuleriit.ee User-Agent: Mozilla Thunderbird 1.0 (X11/20050215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: Re: 2.6.12-rc2-mm2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: indrek.kruusa@tuleriit.ee Precedence: bulk X-list: netdev Content-Length: 756 Lines: 31 Herbert Xu wrote: >Andrew Morton wrote: > > >>dmesg is not clean though: >> >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>TCP: time wait bucket table overflow >>printk: 392 messages suppressed. >> >>What I did: >>- "bombing" httpd with JMeter (from another computer) >> >> > >This is normal. The number of TCP connections held by >your server in the TIME_WAIT state is exceeding >tcp_max_tw_buckets. > >Check out tcp(7) on what this means and how it may or >may not be a problem for you. > > Wait a moment.... with kernel 2.6.10-oci7 (Sam) load average is 3-4x lower and system does not reach this tcp_max_tw_buckets limit. If it is desired I can do more tests with different kernels. Indrek From bunk@stusta.de Sat Apr 9 11:03:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 11:04:03 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j39I3tiM031405 for ; Sat, 9 Apr 2005 11:03:56 -0700 Received: (qmail 6304 invoked from network); 9 Apr 2005 18:03:48 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 9 Apr 2005 18:03:48 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 9D088BB95C; Sat, 9 Apr 2005 20:03:48 +0200 (CEST) Date: Sat, 9 Apr 2005 20:03:48 +0200 From: Adrian Bunk To: Jeff Garzik , Andrew Morton Cc: Jesper Juhl , Maciej Soltysiak , "James P. Ketrenos" , netdev@oss.sgi.com, "David S. Miller" , linux-kernel@vger.kernel.org Subject: [-mm patch] net/ieee80211/ieee80211_tx.c: swapped memset arguments Message-ID: <20050409180348.GC3632@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 699 Lines: 26 Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Patch by Jesper Juhl. Signed-off-by: Jesper Juhl Signed-off-by: Adrian Bunk --- This patch was sent by Jesper Juhl on: - 3 Apr 2005 --- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c 2005-03-31 21:20:08.000000000 +0200 +++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c 2005-04-03 00:34:22.000000000 +0200 @@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx if (!txb) return NULL; - memset(txb, sizeof(struct ieee80211_txb), 0); + memset(txb, 0, sizeof(struct ieee80211_txb)); txb->nr_frags = nr_frags; txb->frag_size = txb_size; From herbert@gondor.apana.org.au Sat Apr 9 12:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 12:31:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39JVQ6o005305 for ; Sat, 9 Apr 2005 12:31:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKLfL-0006cZ-00; Sun, 10 Apr 2005 05:30:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKLe2-0002SM-00; Sun, 10 Apr 2005 05:29:26 +1000 Date: Sun, 10 Apr 2005 05:29:26 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050409192926.GA9423@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113049844.1090.23.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1264 Lines: 41 Hi Jamal: On Sat, Apr 09, 2005 at 08:30:44AM -0400, jamal wrote: > > This is nice since it seems to go on top of the patch i posted. > I didnt get an ACK from Dave - so i assumed that patch is not on his > tree yet. Which tree are you using? The Linus tree plus your patch. > On Sat, 2005-04-09 at 07:12, Herbert Xu wrote: > > > ===== net/xfrm/xfrm_policy.c 1.75 vs edited ===== > > --- 1.75/net/xfrm/xfrm_policy.c 2005-04-01 16:24:20 +10:00 > > +++ edited/net/xfrm/xfrm_policy.c 2005-04-09 18:02:53 +10:00 > > @@ -216,8 +216,8 @@ > > > > expired: > > read_unlock(&xp->lock); > > - km_policy_expired(xp, dir, 1); > > - xfrm_policy_delete(xp, dir); > > + if (!xfrm_policy_delete(xp, dir)) > > + km_policy_expired(xp, dir, 1); > > xfrm_pol_put(xp);> > > } > > > > If the policy was already dead you will still return a 0 from > xfrm_policy_delete(). Fixable by policy_kill returning an int. You're right. The other callers of xfrm_policy_kill needs to check it too. I'll fix this up. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 9 12:37:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 12:37:23 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39JbEAp005918 for ; Sat, 9 Apr 2005 12:37:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKLlJ-0006e9-00; Sun, 10 Apr 2005 05:36:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKLkx-0002Ts-00; Sun, 10 Apr 2005 05:36:35 +1000 Date: Sun, 10 Apr 2005 05:36:35 +1000 To: Dmitry Yusupov Cc: Mike Christie , netdev@oss.sgi.com, davem@davemloft.net Subject: Re: [PATCH] NETLINK_UESTABLISHED notifier event Message-ID: <20050409193635.GC9423@gondor.apana.org.au> References: <20050406212906.GA24775@gondor.apana.org.au> <1112823442.16753.68.camel@beastie> <20050406220417.GA4443@gondor.apana.org.au> <1112826385.16753.99.camel@beastie> <20050407213231.GA28738@gondor.apana.org.au> <1112917001.3893.77.camel@beastie> <20050408113654.GA26095@gondor.apana.org.au> <1112974214.17165.8.camel@mylaptop> <20050409014447.GA22607@gondor.apana.org.au> <1113062579.3893.110.camel@beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113062579.3893.110.camel@beastie> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 719 Lines: 19 On Sat, Apr 09, 2005 at 09:02:59AM -0700, Dmitry Yusupov wrote: > > "emergency pool" is a big and generic feature, needs design and > resolution. it could definitely wait. Do you have something against > one liner patch for using sk->sk_allocation instead of hard-coded vm > priority? Whatever we come up with will need to be maintained as part of the kernel ABI. So I'd rather not see a temporary hack carried around forever. You can always patch your kernels to do whatever you want of course. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 9 13:04:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 13:04:57 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39K4m79007210 for ; Sat, 9 Apr 2005 13:04:49 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKMBp-0006sm-00; Sun, 10 Apr 2005 06:04:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKMAc-0002W2-00; Sun, 10 Apr 2005 06:03:06 +1000 Date: Sun, 10 Apr 2005 06:03:06 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050409200306.GA9660@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050409192926.GA9423@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1303 Lines: 39 On Sun, Apr 10, 2005 at 05:29:26AM +1000, herbert wrote: > > > On Sat, 2005-04-09 at 07:12, Herbert Xu wrote: > > > > > ===== net/xfrm/xfrm_policy.c 1.75 vs edited ===== > > > --- 1.75/net/xfrm/xfrm_policy.c 2005-04-01 16:24:20 +10:00 > > > +++ edited/net/xfrm/xfrm_policy.c 2005-04-09 18:02:53 +10:00 > > > @@ -216,8 +216,8 @@ > > > > > > expired: > > > read_unlock(&xp->lock); > > > - km_policy_expired(xp, dir, 1); > > > - xfrm_policy_delete(xp, dir); > > > + if (!xfrm_policy_delete(xp, dir)) > > > + km_policy_expired(xp, dir, 1); > > > xfrm_pol_put(xp);> > > > } > > > > > > > If the policy was already dead you will still return a 0 from > > xfrm_policy_delete(). Fixable by policy_kill returning an int. > > You're right. The other callers of xfrm_policy_kill needs to > check it too. Actually, my code was right :) xfrm_policy_kill can only be called by the one who removed the policy from the linked list. Therefore it can never fail. If this logic is wrong we will be getting fat warnings from xfrm_policy_kill. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sat Apr 9 16:00:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Apr 2005 16:00:48 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j39N0elZ011190 for ; Sat, 9 Apr 2005 16:00:41 -0700 Received: (qmail 12243 invoked from network); 9 Apr 2005 23:00:35 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 9 Apr 2005 23:00:35 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id C12DCB000A; Sun, 10 Apr 2005 01:00:34 +0200 (CEST) Date: Sun, 10 Apr 2005 01:00:34 +0200 From: Adrian Bunk To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/ewrk3.c: remove dead code Message-ID: <20050409230034.GN3632@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 937 Lines: 32 This patch removes some obviously dead code found by the Coverity checker. Signed-off-by: Adrian Bunk --- drivers/net/ewrk3.c | 12 +++--------- 1 files changed, 3 insertions(+), 9 deletions(-) --- linux-2.6.12-rc2-mm2-full/drivers/net/ewrk3.c.old 2005-04-09 22:03:49.000000000 +0200 +++ linux-2.6.12-rc2-mm2-full/drivers/net/ewrk3.c 2005-04-09 22:04:15.000000000 +0200 @@ -1308,15 +1308,9 @@ static int __init eisa_probe(struct net_ if (ioaddr < 0x1000) goto out; - if (ioaddr == 0) { /* Autoprobing */ - iobase = EISA_SLOT_INC; /* Get the first slot address */ - i = 1; - maxSlots = MAX_EISA_SLOTS; - } else { /* Probe a specific location */ - iobase = ioaddr; - i = (ioaddr >> 12); - maxSlots = i + 1; - } + iobase = ioaddr; + i = (ioaddr >> 12); + maxSlots = i + 1; for (i = 1; (i < maxSlots) && (dev != NULL); i++, iobase += EISA_SLOT_INC) { if (EISA_signature(name, EISA_ID) == 0) { From herbert@gondor.apana.org.au Sun Apr 10 00:50:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 00:50:56 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3A7okWd030346 for ; Sun, 10 Apr 2005 00:50:47 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKXCp-00013P-00; Sun, 10 Apr 2005 17:50:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKXBa-0003SO-00; Sun, 10 Apr 2005 17:48:50 +1000 Date: Sun, 10 Apr 2005 17:48:50 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [4/4] [IPSEC] Set byid for km_event in xfrm_get_policy Message-ID: <20050410074849.GA13259@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20050409111551.GA7378@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1058 Lines: 40 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch fixes policy deletion in xfrm_user so that it sets km_event.data.byid. This puts xfrm_user on par with what af_key does in this case. Signed-off-by: Herbert Xu xfrm_user.c | 1 + 1 files changed, 1 insertion(+) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-4 ===== net/xfrm/xfrm_user.c 1.54 vs edited ===== --- 1.54/net/xfrm/xfrm_user.c 2005-04-09 20:40:43 +10:00 +++ edited/net/xfrm/xfrm_user.c 2005-04-09 20:41:29 +10:00 @@ -877,6 +877,7 @@ MSG_DONTWAIT); } } else { + c.data.byid = p->index; c.event = XFRM_SAP_DELETED; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; --FCuugMFkClbJLl1L-- From udovdh@xs4all.nl Sun Apr 10 01:16:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 01:16:47 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3A8GflH031313 for ; Sun, 10 Apr 2005 01:16:42 -0700 Received: from surfplank (pindarots.xs4all.nl [82.92.197.115]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3A8GLmJ080461; Sun, 10 Apr 2005 10:16:24 +0200 (CEST) (envelope-from udovdh@xs4all.nl) From: "Udo van den Heuvel" To: Cc: Subject: VIA Rhine ethernet driver bug Date: Sun, 10 Apr 2005 10:16:21 +0200 Message-ID: <000501c53da5$944b05d0$450aa8c0@hierzo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3A8GflH031313 X-archive-position: 1623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: udovdh@xs4all.nl Precedence: bulk X-list: netdev Content-Length: 3177 Lines: 98 Hello, I posted about the VIA Rhine ethernet bug to the LKML but received the suggestion to also post here. Let me explain about the bug, it gives messages like: Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x9 length 0 status 00000600! Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame cca77090 vs cca77090. Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame spanned multiple buffers, entry 0xa length 0 status 00000400! Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame cca770a0 vs cca770a0. [....] Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x7 length 0 status 00000400! Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame cca77070 vs cca77070. Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x8 length 24436 status 5f748d10! Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame cca77080 vs cca77080. Most of the time the ethernet connection is gone and needs and ifconfig down/up or reboot to make it work again. I see this error on a VIA EPIA CL-6000 board. Using google I see the mentionings of the error messages in relation to VIA Rhine go back to 1999. The other side of eth1 is an Alcatel Speedtouch Home. With different firewall hardware (Tulip DT5/xxx but same Alcatel) I did not see the errors. Any ideas? A patch to gather more info so the bug can be fixed? Etc? Please post! Info: eth0: VIA Rhine III at 0x1d000, 00:40:63:d6:xx:xx, IRQ 11. eth1: VIA Rhine II at 0x1e800, 00:40:63:d6:xx:xx, IRQ 9. Linux epia 2.6.11-rc1-mm2 #2 Sat Jan 22 10:51:45 CET 2005 i686 i686 i386 GNU/Linux 00:0f.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 8b) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) # cat /proc/interrupts CPU0 0: 5739616 XT-PIC timer 1: 78 XT-PIC i8042 2: 0 XT-PIC cascade 3: 12 XT-PIC serial 4: 12 XT-PIC serial 8: 1 XT-PIC rtc 9: 804990 XT-PIC VIA8233, uhci_hcd, uhci_hcd, eth1 11: 493428 XT-PIC HiSax, ehci_hcd, uhci_hcd, eth0 12: 512 XT-PIC i8042 14: 453632 XT-PIC ide0 15: 50784 XT-PIC ide1 NMI: 0 ERR: 1 (the ERR value has a relation to the bug? I just rebooted the box and the error occurred once...) # ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000001 (1) Link detected: yes Kind regards, Udo From herbert@gondor.apana.org.au Sun Apr 10 02:04:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 02:04:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3A94UMZ032374 for ; Sun, 10 Apr 2005 02:04:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKYMF-0001OE-00; Sun, 10 Apr 2005 19:03:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKYLC-0006m9-00; Sun, 10 Apr 2005 19:02:50 +1000 Date: Sun, 10 Apr 2005 19:02:50 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* Message-ID: <20050410090250.GA26022@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20050410074849.GA13259@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 10878 Lines: 426 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: I spotted some more issues while preparing the last patch of the series. So I'll extend it a little further. This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*. The netlink interface is meant to map directly onto the underlying xfrm subsystem. Therefore rather than using a new independent representation for the events we can simply use the existing ones from xfrm_user. I also killed a couple of inline's in af_key since 1) They are not performance critical. 2) None of the other x2y functions here are inlined. Signed-off-by: Herbert Xu include/net/xfrm.h | 12 -------- net/key/af_key.c | 70 +++++++++++++++++++++++++------------------------- net/xfrm/xfrm_state.c | 4 +- net/xfrm/xfrm_user.c | 63 ++++++++++++--------------------------------- 4 files changed, 55 insertions(+), 94 deletions(-) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-5 ===== include/net/xfrm.h 1.82 vs edited ===== --- 1.82/include/net/xfrm.h 2005-04-09 20:40:43 +10:00 +++ edited/include/net/xfrm.h 2005-04-10 18:01:39 +10:00 @@ -157,18 +157,6 @@ XFRM_STATE_DEAD }; -/* events that could be sent by kernel */ -enum { - XFRM_SAP_INVALID, - XFRM_SAP_EXPIRED, - XFRM_SAP_ADDED, - XFRM_SAP_UPDATED, - XFRM_SAP_DELETED, - XFRM_SAP_FLUSHED, - __XFRM_SAP_MAX -}; -#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1) - /* callback structure passed from either netlink or pfkey */ struct km_event { ===== net/key/af_key.c 1.75 vs edited ===== --- 1.75/net/key/af_key.c 2005-04-09 20:40:43 +10:00 +++ edited/net/key/af_key.c 2005-04-10 18:51:51 +10:00 @@ -1245,38 +1245,38 @@ return 0; } -static inline int event2poltype (int event) +static int event2poltype(int event) { switch (event) { - case XFRM_SAP_DELETED: + case XFRM_MSG_DELPOLICY: return SADB_X_SPDDELETE; - case XFRM_SAP_ADDED: + case XFRM_MSG_NEWPOLICY: return SADB_X_SPDADD; - case XFRM_SAP_UPDATED: + case XFRM_MSG_UPDPOLICY: return SADB_X_SPDUPDATE; - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: // return SADB_X_SPDEXPIRE; default: - printk("pfkey: Unknown policy event %d\n",event); + printk("pfkey: Unknown policy event %d\n", event); break; } return 0; } -static inline int event2keytype (int event) +static int event2keytype(int event) { switch (event) { - case XFRM_SAP_DELETED: + case XFRM_MSG_DELSA: return SADB_DELETE; - case XFRM_SAP_ADDED: + case XFRM_MSG_NEWSA: return SADB_ADD; - case XFRM_SAP_UPDATED: + case XFRM_MSG_UPDSA: return SADB_UPDATE; - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return SADB_EXPIRE; default: - printk("pfkey: Unknown SA event %d\n",event); + printk("pfkey: Unknown SA event %d\n", event); break; } @@ -1290,7 +1290,7 @@ struct sadb_msg *hdr; int hsc = 3; - if (c->event == XFRM_SAP_DELETED) + if (c->event == XFRM_MSG_DELSA) hsc = 0; skb = pfkey_xfrm_state2msg(x, 0, hsc); @@ -1337,9 +1337,9 @@ } if (hdr->sadb_msg_type == SADB_ADD) - c.event = XFRM_SAP_ADDED; + c.event = XFRM_MSG_NEWSA; else - c.event = XFRM_SAP_UPDATED; + c.event = XFRM_MSG_UPDSA; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; km_state_notify(x, &c); @@ -1376,7 +1376,7 @@ c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELSA; km_state_notify(x, &c); xfrm_state_put(x); @@ -1552,7 +1552,7 @@ c.data.proto = proto; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_FLUSHED; + c.event = XFRM_MSG_FLUSHSA; km_state_notify(NULL, &c); return 0; @@ -1962,7 +1962,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = PF_KEY_V2; - if (c->data.byid && c->event == XFRM_SAP_DELETED) + if (c->data.byid && c->event == XFRM_MSG_DELPOLICY) out_hdr->sadb_msg_type = SADB_X_SPDDELETE2; else out_hdr->sadb_msg_type = event2poltype(c->event); @@ -2060,9 +2060,9 @@ } if (hdr->sadb_msg_type == SADB_X_SPDUPDATE) - c.event = XFRM_SAP_UPDATED; + c.event = XFRM_MSG_UPDPOLICY; else - c.event = XFRM_SAP_ADDED; + c.event = XFRM_MSG_NEWPOLICY; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; @@ -2120,7 +2120,7 @@ c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELPOLICY; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); xfrm_pol_put(xp); @@ -2177,7 +2177,7 @@ c.pid = hdr->sadb_msg_pid; if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) { c.data.byid = 1; - c.event = XFRM_SAP_DELETED; + c.event = XFRM_MSG_DELPOLICY; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); } else { err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1); @@ -2240,7 +2240,7 @@ struct km_event c; xfrm_policy_flush(); - c.event = XFRM_SAP_FLUSHED; + c.event = XFRM_MSG_FLUSHPOLICY; c.pid = hdr->sadb_msg_pid; c.seq = hdr->sadb_msg_seq; km_policy_notify(NULL, 0, &c); @@ -2482,16 +2482,16 @@ static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c) { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return key_notify_sa_expire(x, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: + case XFRM_MSG_DELSA: + case XFRM_MSG_NEWSA: + case XFRM_MSG_UPDSA: return key_notify_sa(x, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHSA: return key_notify_sa_flush(c); default: - printk("pfkey: Unknown SA event %d\n",c->event); + printk("pfkey: Unknown SA event %d\n", c->event); break; } @@ -2501,16 +2501,16 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c) { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: return key_notify_policy_expire(xp, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: + case XFRM_MSG_DELPOLICY: + case XFRM_MSG_NEWPOLICY: + case XFRM_MSG_UPDPOLICY: return key_notify_policy(xp, dir, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHPOLICY: return key_notify_policy_flush(c); default: - printk("pfkey: Unknown policy event %d\n",c->event); + printk("pfkey: Unknown policy event %d\n", c->event); break; } ===== net/xfrm/xfrm_state.c 1.63 vs edited ===== --- 1.63/net/xfrm/xfrm_state.c 2005-04-09 20:40:43 +10:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-10 18:55:01 +10:00 @@ -836,7 +836,7 @@ struct km_event c; c.data.hard = hard; - c.event = XFRM_SAP_EXPIRED; + c.event = XFRM_MSG_EXPIRE; km_state_notify(x, &c); if (hard) @@ -884,7 +884,7 @@ struct km_event c; c.data.hard = hard; - c.event = XFRM_SAP_EXPIRED; + c.event = XFRM_MSG_POLEXPIRE; km_policy_notify(pol, dir, &c); if (hard) ===== net/xfrm/xfrm_user.c 1.55 vs edited ===== --- 1.55/net/xfrm/xfrm_user.c 2005-04-10 17:45:12 +10:00 +++ edited/net/xfrm/xfrm_user.c 2005-04-10 18:05:53 +10:00 @@ -292,10 +292,7 @@ c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; - if (nlh->nlmsg_type == XFRM_MSG_NEWSA) - c.event = XFRM_SAP_ADDED; - else - c.event = XFRM_SAP_UPDATED; + c.event = nlh->nlmsg_type; km_state_notify(x, &c); xfrm_state_put(x); @@ -327,7 +324,7 @@ c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; - c.event = XFRM_SAP_DELETED; + c.event = nlh->nlmsg_type; km_state_notify(x, &c); xfrm_state_put(x); @@ -721,11 +718,7 @@ } - if (!excl) - c.event = XFRM_SAP_UPDATED; - else - c.event = XFRM_SAP_ADDED; - + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(xp, p->dir, &c); @@ -878,7 +871,7 @@ } } else { c.data.byid = p->index; - c.event = XFRM_SAP_DELETED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(xp, p->dir, &c); @@ -896,7 +889,7 @@ xfrm_state_flush(p->proto); c.data.proto = p->proto; - c.event = XFRM_SAP_FLUSHED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_state_notify(NULL, &c); @@ -909,7 +902,7 @@ struct km_event c; xfrm_policy_flush(); - c.event = XFRM_SAP_FLUSHED; + c.event = nlh->nlmsg_type; c.seq = nlh->nlmsg_seq; c.pid = nlh->nlmsg_pid; km_policy_notify(NULL, 0, &c); @@ -1180,7 +1173,6 @@ struct xfrm_usersa_info *p; struct nlmsghdr *nlh; struct sk_buff *skb; - u32 nlt; unsigned char *b; int len = xfrm_sa_len(x); @@ -1189,16 +1181,7 @@ return -ENOMEM; b = skb->tail; - if (c->event == XFRM_SAP_ADDED) - nlt = XFRM_MSG_NEWSA; - else if (c->event == XFRM_SAP_UPDATED) - nlt = XFRM_MSG_UPDSA; - else if (c->event == XFRM_SAP_DELETED) - nlt = XFRM_MSG_DELSA; - else - goto nlmsg_failure; - - nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); nlh->nlmsg_flags = 0; p = NLMSG_DATA(nlh); @@ -1230,13 +1213,13 @@ { switch (c->event) { - case XFRM_SAP_EXPIRED: + case XFRM_MSG_EXPIRE: return xfrm_exp_state_notify(x, c); - case XFRM_SAP_DELETED: - case XFRM_SAP_UPDATED: - case XFRM_SAP_ADDED: + case XFRM_MSG_DELSA: + case XFRM_MSG_UPDSA: + case XFRM_MSG_NEWSA: return xfrm_notify_sa(x, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHSA: return xfrm_notify_sa_flush(c); default: printk("xfrm_user: Unknown SA event %d\n",c->event); @@ -1405,7 +1388,6 @@ struct xfrm_userpolicy_info *p; struct nlmsghdr *nlh; struct sk_buff *skb; - u32 nlt = 0 ; unsigned char *b; int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); @@ -1415,16 +1397,7 @@ return -ENOMEM; b = skb->tail; - if (c->event == XFRM_SAP_ADDED) - nlt = XFRM_MSG_NEWPOLICY; - else if (c->event == XFRM_SAP_UPDATED) - nlt = XFRM_MSG_UPDPOLICY; - else if (c->event == XFRM_SAP_DELETED) - nlt = XFRM_MSG_DELPOLICY; - else - goto nlmsg_failure; - - nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); p = NLMSG_DATA(nlh); @@ -1471,13 +1444,13 @@ { switch (c->event) { - case XFRM_SAP_ADDED: - case XFRM_SAP_UPDATED: - case XFRM_SAP_DELETED: + case XFRM_MSG_NEWPOLICY: + case XFRM_MSG_UPDPOLICY: + case XFRM_MSG_DELPOLICY: return xfrm_notify_policy(xp, dir, c); - case XFRM_SAP_FLUSHED: + case XFRM_MSG_FLUSHPOLICY: return xfrm_notify_policy_flush(c); - case XFRM_SAP_EXPIRED: + case XFRM_MSG_POLEXPIRE: return xfrm_exp_policy_notify(xp, dir, c); default: printk("xfrm_user: Unknown Policy event %d\n",c->event); --PNTmBPCT7hxwcZjr-- From herbert@gondor.apana.org.au Sun Apr 10 02:40:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 02:40:29 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3A9eJ7n002999 for ; Sun, 10 Apr 2005 02:40:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKYux-0001Y0-00; Sun, 10 Apr 2005 19:39:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKYtp-0006yC-00; Sun, 10 Apr 2005 19:38:37 +1000 Date: Sun, 10 Apr 2005 19:38:37 +1000 To: "David S. Miller" Cc: Masahide NAKAMURA , Patrick McHardy , jamal , netdev Subject: [6/*] [IPSEC] Add xfrm_userpolicy_delete for xfrm_user notification Message-ID: <20050410093837.GA26769@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20050410090250.GA26022@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2351 Lines: 83 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch changes the format of the XFRM_MSG_DELPOLICY notification so that we don't lose the byid information carried in km_event. Since this user interface is introduced by Jamal's patch we can still afford to change it. I know that this is a bit trivial but as it is the information carried in xfrm_user's notifications is a strict superset of that of af_key and I'd like to keep it that way :) Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-event-6 ===== include/linux/xfrm.h 1.24 vs edited ===== --- 1.24/include/linux/xfrm.h 2005-04-08 23:08:26 +10:00 +++ edited/include/linux/xfrm.h 2005-04-10 19:25:22 +10:00 @@ -227,6 +227,11 @@ __u8 dir; }; +struct xfrm_userpolicy_delete { + struct xfrm_userpolicy_info pol; + __u8 byid; +}; + struct xfrm_user_acquire { struct xfrm_id id; xfrm_address_t saddr; ===== net/xfrm/xfrm_user.c 1.56 vs edited ===== --- 1.56/net/xfrm/xfrm_user.c 2005-04-10 19:03:30 +10:00 +++ edited/net/xfrm/xfrm_user.c 2005-04-10 19:30:30 +10:00 @@ -1386,20 +1386,30 @@ static int xfrm_notify_policy( struct xfrm_policy *xp, int dir, struct km_event *c) { struct xfrm_userpolicy_info *p; + struct xfrm_userpolicy_delete *pdel; struct nlmsghdr *nlh; struct sk_buff *skb; unsigned char *b; int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr); - len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info)); + int payload; + + payload = (c->event == XFRM_MSG_DELPOLICY) ? + sizeof(*pdel) : sizeof(*p); + len += NLMSG_SPACE(payload); skb = alloc_skb(len, GFP_ATOMIC); if (skb == NULL) return -ENOMEM; b = skb->tail; - nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p)); + nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, payload); p = NLMSG_DATA(nlh); + if (c->event == XFRM_MSG_DELPOLICY) { + pdel = NLMSG_DATA(nlh); + pdel->byid = !!c->data.byid; + p = &pdel->pol; + } nlh->nlmsg_flags = 0; --CE+1k2dSO48ffgeK-- From herbert@gondor.apana.org.au Sun Apr 10 02:56:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 02:56:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3A9u7qD003799 for ; Sun, 10 Apr 2005 02:56:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKZ9Z-0001cE-00; Sun, 10 Apr 2005 19:54:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKZ7e-00070D-00; Sun, 10 Apr 2005 19:52:54 +1000 From: Herbert Xu To: johnpol@2ka.mipt.ru Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Cc: jmorris@redhat.com, kay.sievers@vrfy.org, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <1112942924.28858.234.camel@uganda> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 10 Apr 2005 19:52:54 +1000 X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1376 Lines: 38 Please add netdev to the CC list since this discussion pertains to the networking subsystem. Evgeniy Polyakov wrote: > > User should not know about low-level transport - > it is like socket layer - write only data and do not care about > how it will be delivered. The delineation between transport and upper layer is fuzzy. In one situation the protocol might be transport and in another it could be above the transport. So I don't buy this argument. > In the previous versions netlink group was assigned as incremented > counter, > that was not convenient, but now we have 2-way ID, which is better > from users point of view - idx is supposed to be major id, val - > some subsystem of that set. Actually netlink does let you bind to a specific ID. Of course you may argue that a single u32 is not enough. However, nothing is stopping you from introducing netlink v2 that extends this. In fact this is my main gripe with your patch: Why aren't you extending netlink instead of hacking something on top of the existing netlink? If the extensions require breaking compatibility: Fine, you just need to call it netlink v2. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Sun Apr 10 03:33:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 03:33:12 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AAX3Lf004879 for ; Sun, 10 Apr 2005 03:33:04 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3AAW6ls014356; Sun, 10 Apr 2005 14:32:06 +0400 Date: Sun, 10 Apr 2005 14:32:05 +0400 From: Evgeniy Polyakov To: Herbert Xu Cc: jmorris@redhat.com, kay.sievers@vrfy.org, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> In-Reply-To: References: <1112942924.28858.234.camel@uganda> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Sun, 10 Apr 2005 14:32:07 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 3907 Lines: 96 On Sun, 10 Apr 2005 19:52:54 +1000 Herbert Xu wrote: > Please add netdev to the CC list since this discussion pertains to > the networking subsystem. > > Evgeniy Polyakov wrote: > > > > User should not know about low-level transport - > > it is like socket layer - write only data and do not care about > > how it will be delivered. > > The delineation between transport and upper layer is fuzzy. > In one situation the protocol might be transport and in another > it could be above the transport. > > So I don't buy this argument. Connector allows to hide transport layer completely - concider acrypto or superio - that subsystems do not know about network, author of the temperature driver for superio should not know how skb is allocated and processed, and acrypto is not network related system, so why they should know about network API? Why should they know what is skb, how it is allocated, why shared skb can not be used in netlink and so on? Users of the connector are only cared about destination ID and how to send/receive message. And what to do if we do not want something like connector to be used for userspace control - we need to create each time new netlink socket unit, like kobject's one, or netlink_ulog, we need to register it in netlink.h, where already there too many units. > > In the previous versions netlink group was assigned as incremented > > counter, > > that was not convenient, but now we have 2-way ID, which is better > > from users point of view - idx is supposed to be major id, val - > > some subsystem of that set. > > Actually netlink does let you bind to a specific ID. > > Of course you may argue that a single u32 is not enough. However, > nothing is stopping you from introducing netlink v2 that extends > this. > > In fact this is my main gripe with your patch: Why aren't you > extending netlink instead of hacking something on top of the existing > netlink? If the extensions require breaking compatibility: Fine, > you just need to call it netlink v2. When connector was created in the middle of 2004, it's main aim was allowing easy userspace control over netlink. Creating it's own skb receive parser was acceptible for one project, for two, but it is definitely not the solution for general use. And also I think it is not so easy to include new netlink family unit for some completely unrelated to network subsystem. So I decided to create only one skb parser, and put all skb processing in one place, so any user has to do only registration with it's own receive callback, and sending function. Thus, transport layer was completely hidden from connector users, there are no complex netlink macros there, no network API and all complex related issues, no huge code duplication in each device, which does not want to mess with 32/64 ioctl issues, but want easy userspace control. Later connector was changed a bit to allow easy notification ability and new bus was added. Connector is the solution for d-bus related projects, since all control is in one place, there are destination ID, there is no complex API. Concider the latest xfrm event changes - good that we already have netlink socket there, but in each sending function [there are at least three new] we have all those skb_alloc, skb_put, NLMSG_* and so on which are absolutely identical. According to names and structures itself, they are too close to what connector is for, and how it is implemented, so we already have several connectors in the tree, and do we really want to proceed with it all over the place? > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From akpm@osdl.org Sun Apr 10 03:45:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 03:45:12 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AAj5w7005582 for ; Sun, 10 Apr 2005 03:45:05 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3AAiqs4029513 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 10 Apr 2005 03:44:52 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j3AAipki010751; Sun, 10 Apr 2005 03:44:51 -0700 Date: Sun, 10 Apr 2005 03:44:46 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: Felix Palmen Subject: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-Id: <20050410034446.39e3025e.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__10_Apr_2005_03_44_46_-0700_Adc8qDJbGBrDBpST" X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1628 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: 3167 Lines: 94 This is a multi-part message in MIME format. --Multipart=_Sun__10_Apr_2005_03_44_46_-0700_Adc8qDJbGBrDBpST Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit That sounds like a bug in appletalk or in the tap driver. Please describe a means by which other developers can reproduce that bug (a sequence of shell commands would be ideal). Thanks. Begin forwarded message: Date: Sun, 10 Apr 2005 11:16:25 +0200 From: Felix Palmen To: linux-kernel@vger.kernel.org Subject: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Hi lkml-members, I recently had a problem with appletalk. After starting atalkd on a TAP interface and stopping it later, unregister_netdevice() just stated | unregister_netdevice: waiting for tap0 to become free. Usage count = -1 So I assume there is a problem in the appletalk code, but I didn't try reproducing that on other systems so far. I changed my kernel to "correct" a negative refcnt to 0 and that kind of fixes the problem. I'm not sure whether this could break anything, but certainly waiting for a device to become free is no use when there is a negative number of users, so I think it would be better to allow the system to shut down cleanly in this case. Here's m suggestion: #v+ --- linux-2.6.11-orig/net/core/dev.c 2005-03-02 08:38:09.000000000 +0100 +++ linux-2.6.11/net/core/dev.c 2005-04-09 16:44:42.000000000 +0200 @@ -2876,7 +2876,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 0) { + while (atomic_read(&dev->refcnt) > 0) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); @@ -2910,6 +2910,13 @@ warning_time = jiffies; } } + if (atomic_read(&dev->refcnt) != 0) { + printk(KERN_ERR "unregister_netdevice: " + "%s has negative refcnt (%d). " + "This should never happen! Setting refcnt to 0.\n", + dev->name, atomic_read(&dev->refcnt)); + atomic_set(&dev->refcnt, 0); + } } /* The sequence is: #v- Greets, Felix PS: Please note I'm not subscribed to lkml and CC me in replies, thanks. -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/ | | \ / Campaign Against | fmp@palmen.homeip.net encrypted mail welcome | | X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | --Multipart=_Sun__10_Apr_2005_03_44_46_-0700_Adc8qDJbGBrDBpST Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppUUNWQXdVQlFsanU2UVNxKzNneEc5Y05BUUpHV1FQOENnSFA3NFJCRDdEQldTLzhE MXV2U2JrOFUyaEY1TmM5CkUrQmdUT2NGYjM0NVlDVnFTUHluajBjT1IxSVNMMmVTWTdOWERKanBE QXhGbkY1U1kvY091bGdxRkozTEhXSjQKa2l2azh1eXNUc1ZhZ2pGandUSmQ2ejRyRnhJd1IwVjR0 UmpGYk4wQkxhR3RPc2Z3T2Jqd0tkdk82WVQydEJVNwpGc0J3Tm5raWZDWT0KPUZPbU0KLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCgo= --Multipart=_Sun__10_Apr_2005_03_44_46_-0700_Adc8qDJbGBrDBpST-- From kay.sievers@vrfy.org Sun Apr 10 04:08:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 04:09:04 -0700 (PDT) Received: from soundwarez.org (soundwarez.org [217.160.171.123]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AB8q09006910 for ; Sun, 10 Apr 2005 04:08:53 -0700 Received: from dhcp-113.off.vrfy.org (c219227.adsl.hansenet.de [213.39.219.227]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by soundwarez.org (Postfix) with ESMTP id 1F570196CC; Sun, 10 Apr 2005 13:08:44 +0200 (CEST) Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] From: Kay Sievers To: johnpol@2ka.mipt.ru Cc: Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal In-Reply-To: <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> Content-Type: text/plain Date: Sun, 10 Apr 2005 13:08:44 +0200 Message-Id: <1113131325.6994.66.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 (2.2.1.1-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kay.sievers@vrfy.org Precedence: bulk X-list: netdev Content-Length: 4797 Lines: 106 On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: > On Sun, 10 Apr 2005 19:52:54 +1000 > Herbert Xu wrote: > > Evgeniy Polyakov wrote: > > > > > > User should not know about low-level transport - > > > it is like socket layer - write only data and do not care about > > > how it will be delivered. > > > > The delineation between transport and upper layer is fuzzy. > > In one situation the protocol might be transport and in another > > it could be above the transport. > > > > So I don't buy this argument. > > Connector allows to hide transport layer completely - > concider acrypto or superio - that subsystems do not know > about network, author of the temperature driver for superio > should not know how skb is allocated and processed, > and acrypto is not network related system, so why > they should know about network API? > Why should they know what is skb, how it is allocated, > why shared skb can not be used in netlink and so on? > Users of the connector are only cared about > destination ID and how to send/receive message. > And what to do if we do not want something like connector > to be used for userspace control - we need to create > each time new netlink socket unit, like kobject's one, > or netlink_ulog, we need to register it in netlink.h, > where already there too many units. > > > > In the previous versions netlink group was assigned as incremented > > > counter, > > > that was not convenient, but now we have 2-way ID, which is better > > > from users point of view - idx is supposed to be major id, val - > > > some subsystem of that set. > > > > Actually netlink does let you bind to a specific ID. > > > > Of course you may argue that a single u32 is not enough. However, > > nothing is stopping you from introducing netlink v2 that extends > > this. > > > > In fact this is my main gripe with your patch: Why aren't you > > extending netlink instead of hacking something on top of the existing > > netlink? If the extensions require breaking compatibility: Fine, > > you just need to call it netlink v2. > > When connector was created in the middle of 2004, it's main aim > was allowing easy userspace control over netlink. > Creating it's own skb receive parser was acceptible for > one project, for two, but it is definitely not the solution > for general use. And also I think it is not so easy to include new > netlink family unit for some completely unrelated to network subsystem. > > So I decided to create only one skb parser, and put all skb processing > in one place, so any user has to do only registration with it's > own receive callback, and sending function. Sure, but that would apply the a generic netlink extension too, right? > Thus, transport layer was completely hidden from connector users, > there are no complex netlink macros there, no network API > and all complex related issues, no huge code duplication in each device, > which does not want to mess with 32/64 ioctl issues, but > want easy userspace control. I don't see the need for unimplemented abstractions here. You can replace a generic netlink-use just the same way as you can replace the connector's own netlink code below the connector API. There is not much difference. > Later connector was changed a bit to allow easy notification > ability and new bus was added. > Connector is the solution for d-bus related projects, since > all control is in one place, there are destination ID, > there is no complex API. Sorry, what does this have to do with DBUS? > Concider the latest xfrm event changes - good that we already > have netlink socket there, but in each sending function > [there are at least three new] > we have all those skb_alloc, skb_put, NLMSG_* and so on which are > absolutely identical. > According to names and structures itself, they are too close > to what connector is for, and how it is implemented, so we already > have several connectors in the tree, and do we really want > to proceed with it all over the place? That's not the point. Nobody asks to replace the whole connector by raw netlink. But the message subscription and multicasting could be part of the generic netlink framework. The connector API would still be on-top if it and nothing changes besides that we would have a nice low-level api to use for other systems too. The basic idea behind the connector as a nice generic framework for netlink, as it fills the missing multicast case, while we already can do singlecast and broadcast with netlink. It is just the same way the kernel plays with other core functionality too. If something is not represented in the vfs-layer your are asked to add it to the generic part and not implement it privately for your filesystem only. Thanks, Kay From johnpol@2ka.mipt.ru Sun Apr 10 04:38:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 04:38:57 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ABcmc2016572 for ; Sun, 10 Apr 2005 04:38:49 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3ABbwV1009708; Sun, 10 Apr 2005 15:37:58 +0400 Date: Sun, 10 Apr 2005 15:37:57 +0400 From: Evgeniy Polyakov To: Kay Sievers Cc: Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410153757.104fe611@zanzibar.2ka.mipt.ru> In-Reply-To: <1113131325.6994.66.camel@localhost.localdomain> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Sun, 10 Apr 2005 15:37:59 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 7952 Lines: 182 On Sun, 10 Apr 2005 13:08:44 +0200 Kay Sievers wrote: > On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: > > On Sun, 10 Apr 2005 19:52:54 +1000 > > Herbert Xu wrote: > > > Evgeniy Polyakov wrote: > > > > > > > > User should not know about low-level transport - > > > > it is like socket layer - write only data and do not care about > > > > how it will be delivered. > > > > > > The delineation between transport and upper layer is fuzzy. > > > In one situation the protocol might be transport and in another > > > it could be above the transport. > > > > > > So I don't buy this argument. > > > > Connector allows to hide transport layer completely - > > concider acrypto or superio - that subsystems do not know > > about network, author of the temperature driver for superio > > should not know how skb is allocated and processed, > > and acrypto is not network related system, so why > > they should know about network API? > > Why should they know what is skb, how it is allocated, > > why shared skb can not be used in netlink and so on? > > Users of the connector are only cared about > > destination ID and how to send/receive message. > > And what to do if we do not want something like connector > > to be used for userspace control - we need to create > > each time new netlink socket unit, like kobject's one, > > or netlink_ulog, we need to register it in netlink.h, > > where already there too many units. > > > > > > In the previous versions netlink group was assigned as incremented > > > > counter, > > > > that was not convenient, but now we have 2-way ID, which is better > > > > from users point of view - idx is supposed to be major id, val - > > > > some subsystem of that set. > > > > > > Actually netlink does let you bind to a specific ID. > > > > > > Of course you may argue that a single u32 is not enough. However, > > > nothing is stopping you from introducing netlink v2 that extends > > > this. > > > > > > In fact this is my main gripe with your patch: Why aren't you > > > extending netlink instead of hacking something on top of the existing > > > netlink? If the extensions require breaking compatibility: Fine, > > > you just need to call it netlink v2. > > > > When connector was created in the middle of 2004, it's main aim > > was allowing easy userspace control over netlink. > > Creating it's own skb receive parser was acceptible for > > one project, for two, but it is definitely not the solution > > for general use. And also I think it is not so easy to include new > > netlink family unit for some completely unrelated to network subsystem. > > > > So I decided to create only one skb parser, and put all skb processing > > in one place, so any user has to do only registration with it's > > own receive callback, and sending function. > > Sure, but that would apply the a generic netlink extension too, right? Sending is the only and not the most significant part of the connector. Of course cn_netlink_send() can be split into prepare_send() and commit_send(), where commit_send() will live in af_netlink.c and do allocation and so on. But it will not change the fact, that kernel users still need to allocate a netlink socket, register it's own family unit, and so on... Direct netlink usage is like using raw socket or even tun/tap device for TCP/IP, noone use it in that way, although we can, but connector is like using socket interface. > > Thus, transport layer was completely hidden from connector users, > > there are no complex netlink macros there, no network API > > and all complex related issues, no huge code duplication in each device, > > which does not want to mess with 32/64 ioctl issues, but > > want easy userspace control. > > I don't see the need for unimplemented abstractions here. You can > replace a generic netlink-use just the same way as you can replace the > connector's own netlink code below the connector API. There is not much > difference. Kernel users do not want to implement it's own transport over netlink. Socket allocation was changed in 2.5 - we could need to change each driver that use it instead of changing only one place in connector.c Abstration over netlink already implemented in connector and is used in acrypto, superio and even kobject_uevent was changed to do it. > > Later connector was changed a bit to allow easy notification > > ability and new bus was added. > > Connector is the solution for d-bus related projects, since > > all control is in one place, there are destination ID, > > there is no complex API. > > Sorry, what does this have to do with DBUS? Kernel now has only two ways to inform to userspace about it's things - kobject [uevent] and hotplug. There is inotify/dnotify too, but it is diferent in some way. The second one is a huge monster that can not be used in embedded systems, calling userspace process from inside the kernel is now very flexible way. The first one has it's own socket, it's own protocol and infrastructure based on strings. What if we want to inform about some new event? Should we use kobject_uevent mechanism? Not anything can be described as kobject strings. Should we create new socket/proto/infratructure? We do not have another way. That is why connector is usefull here - only one set of methods, known proto, just change "val" in ID and drop it in the userspace if it is not updated to use new events. > > Concider the latest xfrm event changes - good that we already > > have netlink socket there, but in each sending function > > [there are at least three new] > > we have all those skb_alloc, skb_put, NLMSG_* and so on which are > > absolutely identical. > > According to names and structures itself, they are too close > > to what connector is for, and how it is implemented, so we already > > have several connectors in the tree, and do we really want > > to proceed with it all over the place? > > That's not the point. Nobody asks to replace the whole connector by raw > netlink. But the message subscription and multicasting could be part of > the generic netlink framework. The connector API would still be on-top > if it and nothing changes besides that we would have a nice low-level > api to use for other systems too. Netlink already has it's groups - why doesn't it meet your needs? If someone "subscribed" [bound to that group], so message sent to it will be delivered, otherwise - not. One thing may be added to raw netlink - ability to send to the group but not in a "that" multicast way, i.e. send message to all subscribed _exactly_ to that group, so one bound to -1 group will not receive message to 0x123 group when that group was specified in netlink header. I can prepare a patch it is something like following: --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.000000000 +0400 +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.000000000 +0400 @@ -747,7 +747,7 @@ if (p->exclude_sk == sk) goto out; - if (nlk->pid == p->pid || !(nlk->groups & p->group)) + if (nlk->pid == p->pid || (nlk->groups != p->group)) goto out; if (p->failure) { and requires new name... > The basic idea behind the connector as a nice generic framework for > netlink, as it fills the missing multicast case, while we already can do > singlecast and broadcast with netlink. > It is just the same way the kernel plays with other core functionality > too. If something is not represented in the vfs-layer your are asked to > add it to the generic part and not implement it privately for your > filesystem only. Exactly for that reason connector was created - so noone needs to create it's private sockets/netlink API wrappers/skb handlers and so on, just register callback and have a ->send() call. > Thanks, > Kay Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From linux_lover2004@yahoo.com Sun Apr 10 04:52:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 04:52:52 -0700 (PDT) Received: from web52205.mail.yahoo.com (web52205.mail.yahoo.com [206.190.39.87]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3ABqlB4017369 for ; Sun, 10 Apr 2005 04:52:47 -0700 Received: (qmail 83281 invoked by uid 60001); 10 Apr 2005 11:52:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=vxKPpV2kegCABIj9RSjk1kczp3x2If+Z/oi4DRatRCKK767Nqg4uM/Q7p7Cm6l5kn681RPqXnlH2utz8xhbv+gvEERz2S81M6t5EF7frJW6G4IRTaslyJI6MCYi4S8mrMsdTeYwGnU2DLOBR6gxZwSxATnj9SZfJA7XSyzZ6yHA= ; Message-ID: <20050410115240.83278.qmail@web52205.mail.yahoo.com> Received: from [202.56.231.117] by web52205.mail.yahoo.com via HTTP; Sun, 10 Apr 2005 04:52:40 PDT Date: Sun, 10 Apr 2005 04:52:40 -0700 (PDT) From: linux lover Subject: accessing skbuffs To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 371 Lines: 14 hello, Does skbuffs provide facility to access other layers headers at any layer? Say if packet is processed at LINK layer then can IP addresses(SRC & DST) of packets is readable at Link layer? regards, linux_lover __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From johnpol@2ka.mipt.ru Sun Apr 10 04:55:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 04:55:34 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ABtSRX017973 for ; Sun, 10 Apr 2005 04:55:28 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3ABsiMu025876; Sun, 10 Apr 2005 15:54:44 +0400 Date: Sun, 10 Apr 2005 15:54:43 +0400 From: Evgeniy Polyakov To: johnpol@2ka.mipt.ru Cc: Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410155443.2d4fe469@zanzibar.2ka.mipt.ru> In-Reply-To: <20050410153757.104fe611@zanzibar.2ka.mipt.ru> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Sun, 10 Apr 2005 15:54:44 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 337 Lines: 13 On Sun, 10 Apr 2005 15:37:57 +0400 Evgeniy Polyakov wrote: > The second one is a huge monster that can not be used in embedded > systems, calling userspace process from inside the kernel is > now very flexible way. is NOT very flexible way... Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From tgraf@suug.ch Sun Apr 10 05:09:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 05:09:58 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AC9pHR018726 for ; Sun, 10 Apr 2005 05:09:51 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id ED17E1C0EA; Sun, 10 Apr 2005 14:10:05 +0200 (CEST) Date: Sun, 10 Apr 2005 14:10:05 +0200 From: Thomas Graf To: Evgeniy Polyakov Cc: Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410121005.GF26731@postel.suug.ch> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050410153757.104fe611@zanzibar.2ka.mipt.ru> X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 540 Lines: 14 * Evgeniy Polyakov <20050410153757.104fe611@zanzibar.2ka.mipt.ru> 2005-04-10 15:37 > --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.000000000 +0400 > +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.000000000 +0400 > @@ -747,7 +747,7 @@ > if (p->exclude_sk == sk) > goto out; > > - if (nlk->pid == p->pid || !(nlk->groups & p->group)) > + if (nlk->pid == p->pid || (nlk->groups != p->group)) > goto out; > > if (p->failure) { Not valid, would break RTMGRP_*. From johnpol@2ka.mipt.ru Sun Apr 10 05:16:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 05:16:40 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ACGWAd019403 for ; Sun, 10 Apr 2005 05:16:32 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3ACFoP5013946; Sun, 10 Apr 2005 16:15:50 +0400 Date: Sun, 10 Apr 2005 16:15:49 +0400 From: Evgeniy Polyakov To: Thomas Graf Cc: Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@oss.sgi.com, jamal Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> In-Reply-To: <20050410121005.GF26731@postel.suug.ch> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Sun, 10 Apr 2005 16:15:50 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 882 Lines: 26 On Sun, 10 Apr 2005 14:10:05 +0200 Thomas Graf wrote: > * Evgeniy Polyakov <20050410153757.104fe611@zanzibar.2ka.mipt.ru> 2005-04-10 15:37 > > --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.000000000 +0400 > > +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.000000000 +0400 > > @@ -747,7 +747,7 @@ > > if (p->exclude_sk == sk) > > goto out; > > > > - if (nlk->pid == p->pid || !(nlk->groups & p->group)) > > + if (nlk->pid == p->pid || (nlk->groups != p->group)) > > goto out; > > > > if (p->failure) { > > Not valid, would break RTMGRP_*. Yes, it will break too many existing application, it would be new API, like do_one_broadcast_direct(). If I understand Kay right, it is what he needs for the new multicast. Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From hadi@cyberus.ca Sun Apr 10 07:10:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 07:10:59 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AEArUL021810 for ; Sun, 10 Apr 2005 07:10:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DKd9H-0003kn-6V for netdev@oss.sgi.com; Sun, 10 Apr 2005 10:10:51 -0400 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 1DKd9D-0000Ld-Am; Sun, 10 Apr 2005 10:10:47 -0400 Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050409200306.GA9660@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113142244.1088.287.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Apr 2005 10:10:44 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1635 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: 432 Lines: 16 On Sat, 2005-04-09 at 16:03, Herbert Xu wrote: > xfrm_policy_kill can only be called by the one who removed the > policy from the linked list. Therefore it can never fail. > > If this logic is wrong we will be getting fat warnings from > xfrm_policy_kill. > The warning will kick in but it may be as rare as the issue of a delete and expire happening on the same policy that your patch was supposed to stop ;-> cheers, jamal From hadi@cyberus.ca Sun Apr 10 07:15:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 07:15:24 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AEFKDA022419 for ; Sun, 10 Apr 2005 07:15:20 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DKdDW-0004pM-8M for netdev@oss.sgi.com; Sun, 10 Apr 2005 08:15:14 -0600 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 1DKdDW-0000lP-9i; Sun, 10 Apr 2005 10:15:14 -0400 Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050410090250.GA26022@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113142510.1091.294.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Apr 2005 10:15:11 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1636 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: 932 Lines: 25 On Sun, 2005-04-10 at 05:02, Herbert Xu wrote: > Hi: > > I spotted some more issues while preparing the last patch of the > series. So I'll extend it a little further. > > This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*. > The netlink interface is meant to map directly onto the underlying > xfrm subsystem. Therefore rather than using a new independent > representation for the events we can simply use the existing ones > from xfrm_user. > The main reason i did the XFRM_SAP_* is to be able to cover a case where a message was relevant to one KM but not the other. That may not exist now (actually it does with policy expiration that pfkey cant handle - but thats easy to take care of). Hopefully XFRM_MSG_xxx is the superset and will be sufficient. Do you have anymore patches? If not i can give these a quick test; Masahide has a better test setup and if he has time he should as well. cheers, jamal From hadi@cyberus.ca Sun Apr 10 07:39:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 07:39:41 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AEdZQo023329 for ; Sun, 10 Apr 2005 07:39:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DKdaz-00020N-R3 for netdev@oss.sgi.com; Sun, 10 Apr 2005 08:39:29 -0600 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 1DKdat-0002k6-9u; Sun, 10 Apr 2005 10:39:23 -0400 Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Thomas Graf , Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev In-Reply-To: <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113143959.1089.316.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Apr 2005 10:39:19 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1637 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: 1267 Lines: 29 Evgeniy, Please crosspost on netdev - you should know that by now;-> I actually disagreee with Herbert on this. Theres definetely good need to have a more usable messaging system that rides on top of netlink. It is not that netlink cant be extended (I actually think thats a separate topic) - its just that its usability curve is too high. Thats what the original motivation for konnector was. To make it easy for joe dumbass. And i think if konnector sticks to just doing that it will end up being valuable. I do think (and ive said this before) that Evgeniy is pushing it by going beyond this simple agenda/focus. Unfortunately, I actually dont think he is listening _at all_ on this specific issue. Evgeniy, just stick to the original focus and if it is accepted and understood then lets move on to adding new features. Otherwise the result of you adding yet one more feature for CBUS or whatever is clearly to question what the original motivation was. And i dont think you are able to add any other points to justify the existence of any new konnector feature other than describe the original goals. At least thats what i saw reading this thread. Otherwise if you really dont know what you want yet lets just pull this whole thing out IMO. cheers, jamal From jmorris@redhat.com Sun Apr 10 07:57:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 07:57:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AEv9jI024151 for ; Sun, 10 Apr 2005 07:57:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3AEuKis015756; Sun, 10 Apr 2005 10:56:20 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3AEuJO29866; Sun, 10 Apr 2005 10:56:19 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j3AEuH1P013175; Sun, 10 Apr 2005 10:56:18 -0400 Date: Sun, 10 Apr 2005 10:56:17 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: jamal cc: johnpol@2ka.mipt.ru, Thomas Graf , Kay Sievers , Herbert Xu , , , , , , netdev Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] In-Reply-To: <1113143959.1089.316.camel@jzny.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1638 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 Content-Length: 216 Lines: 14 On 10 Apr 2005, jamal wrote: > Thats what the original motivation for konnector was. To make it easy > for joe dumbass. Who you really want writing kernel code :-) - James -- James Morris From hadi@cyberus.ca Sun Apr 10 08:08:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 08:08:37 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AF8XVo024954 for ; Sun, 10 Apr 2005 08:08:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DKe31-0004ET-1r for netdev@oss.sgi.com; Sun, 10 Apr 2005 09:08:27 -0600 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 1DKe2y-0005h1-I0; Sun, 10 Apr 2005 11:08:24 -0400 Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] From: jamal Reply-To: hadi@cyberus.ca To: James Morris Cc: johnpol@2ka.mipt.ru, Thomas Graf , Kay Sievers , Herbert Xu , ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1113145700.1088.324.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Apr 2005 11:08:21 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1639 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: 565 Lines: 18 On Sun, 2005-04-10 at 10:56, James Morris wrote: > On 10 Apr 2005, jamal wrote: > > > Thats what the original motivation for konnector was. To make it easy > > for joe dumbass. > > Who you really want writing kernel code :-) Ok, let me take that back then ;-> The value is in allowing people who are kernel hackers that are trying to focus on an entirely different problem to not really know much about the internals of the messaging subsystem (if you wanna call netlink that). A good example will be the fork patches which were posted recently. cheers, jamal From chas@cmf.nrl.navy.mil Sun Apr 10 08:27:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 08:27:13 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AFR6ws029278 for ; Sun, 10 Apr 2005 08:27:07 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j3AFR09g007587; Sun, 10 Apr 2005 11:27:00 -0400 (EDT) Message-Id: <200504101527.j3AFR09g007587@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 2/3][ATM]: [he] Use the DMA_32BIT_MASK constant from dma-mapping.h Date: Sun, 10 Apr 2005 11:27:01 -0400 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1641 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: 2062 Lines: 60 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/10 10:43:13-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [he] Use the DMA_32BIT_MASK constant from dma-mapping.h # # Signed-off-by: Tobias Klauser # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/he.h # 2005/04/10 10:42:53-04:00 chas@relax.cmf.nrl.navy.mil +0 -2 # [ATM]: [he] Use the DMA_32BIT_MASK constant from dma-mapping.h # # Signed-off-by: Tobias Klauser # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/he.c # 2005/04/10 10:42:53-04:00 chas@relax.cmf.nrl.navy.mil +2 -1 # [ATM]: [he] Use the DMA_32BIT_MASK constant from dma-mapping.h # # Signed-off-by: Tobias Klauser # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/he.c b/drivers/atm/he.c --- a/drivers/atm/he.c 2005-04-10 11:15:02 -04:00 +++ b/drivers/atm/he.c 2005-04-10 11:15:02 -04:00 @@ -70,6 +70,7 @@ #include #include #include +#include #include #include #include @@ -371,7 +372,7 @@ if (pci_enable_device(pci_dev)) return -EIO; - if (pci_set_dma_mask(pci_dev, HE_DMA_MASK) != 0) { + if (pci_set_dma_mask(pci_dev, DMA_32BIT_MASK) != 0) { printk(KERN_WARNING "he: no suitable dma available\n"); err = -EIO; goto init_one_failure; diff -Nru a/drivers/atm/he.h b/drivers/atm/he.h --- a/drivers/atm/he.h 2005-04-10 11:15:02 -04:00 +++ b/drivers/atm/he.h 2005-04-10 11:15:02 -04:00 @@ -380,8 +380,6 @@ #define PCI_VENDOR_ID_FORE 0x1127 #define PCI_DEVICE_ID_FORE_HE 0x400 -#define HE_DMA_MASK 0xffffffff - #define GEN_CNTL_0 0x40 #define INT_PROC_ENBL (1<<25) #define SLAVE_ENDIAN_MODE (1<<16) From chas@cmf.nrl.navy.mil Sun Apr 10 08:27:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 08:27:20 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AFRGvE029295 for ; Sun, 10 Apr 2005 08:27:16 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j3AFR9Kv007592; Sun, 10 Apr 2005 11:27:10 -0400 (EDT) Message-Id: <200504101527.j3AFR9Kv007592@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 3/3][ATM]: [fore200e] pci doesn't use global board list; use pci_register_driver() Date: Sun, 10 Apr 2005 11:27:10 -0400 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1642 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: 1097 Lines: 37 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/10 10:59:57-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [fore200e] pci doesn't use global board list; use pci_register_driver() # # Signed-off-by: Chas Williams # # drivers/atm/fore200e.c # 2005/04/10 10:59:37-04:00 chas@relax.cmf.nrl.navy.mil +1 -3 # [ATM]: [fore200e] pci doesn't use global board list; use pci_register_driver() # # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c 2005-04-10 11:21:37 -04:00 +++ b/drivers/atm/fore200e.c 2005-04-10 11:21:37 -04:00 @@ -2792,8 +2792,6 @@ fore200e = pci_get_drvdata(pci_dev); - list_del(&fore200e->entry); - fore200e_shutdown(fore200e); kfree(fore200e); pci_disable_device(pci_dev); @@ -2850,7 +2848,7 @@ } #ifdef CONFIG_ATM_FORE200E_PCA - if (!pci_module_init(&fore200e_pca_driver)) + if (!pci_register_driver(&fore200e_pca_driver)) return 0; #endif From chas@cmf.nrl.navy.mil Sun Apr 10 08:26:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 08:26:58 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AFQrMa029269 for ; Sun, 10 Apr 2005 08:26:54 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j3AFQlPS007582; Sun, 10 Apr 2005 11:26:47 -0400 (EDT) Message-Id: <200504101526.j3AFQlPS007582@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1/3][ATM]: net/atm/resources.c: remove __free_atm_dev Date: Sun, 10 Apr 2005 11:26:48 -0400 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1640 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: 1443 Lines: 60 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/10 10:36:30-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: net/atm/resources.c: remove __free_atm_dev # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/resources.c # 2005/04/10 10:36:11-04:00 chas@relax.cmf.nrl.navy.mil +3 -8 # [ATM]: net/atm/resources.c: remove __free_atm_dev # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # diff -Nru a/net/atm/resources.c b/net/atm/resources.c --- a/net/atm/resources.c 2005-04-10 11:14:12 -04:00 +++ b/net/atm/resources.c 2005-04-10 11:14:12 -04:00 @@ -44,11 +44,6 @@ return dev; } -static void __free_atm_dev(struct atm_dev *dev) -{ - kfree(dev); -} - static struct atm_dev *__atm_dev_lookup(int number) { struct atm_dev *dev; @@ -90,7 +85,7 @@ if ((inuse = __atm_dev_lookup(number))) { atm_dev_put(inuse); spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); + kfree(dev); return NULL; } dev->number = number; @@ -119,7 +114,7 @@ spin_lock(&atm_dev_lock); list_del(&dev->dev_list); spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); + kfree(dev); return NULL; } @@ -148,7 +143,7 @@ } } - __free_atm_dev(dev); + kfree(dev); } void shutdown_atm_dev(struct atm_dev *dev) From mycooc@yahoo.it Sun Apr 10 11:03:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 11:03:10 -0700 (PDT) Received: from smtp104.mail.sc5.yahoo.com (smtp104.mail.sc5.yahoo.com [66.163.169.223]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3AI31kH001550 for ; Sun, 10 Apr 2005 11:03:01 -0700 Received: from unknown (HELO ?192.168.1.4?) (mycooc@82.54.169.113 with plain) by smtp104.mail.sc5.yahoo.com with SMTP; 10 Apr 2005 18:02:57 -0000 Message-ID: <42596C3E.5020506@yahoo.it> Date: Sun, 10 Apr 2005 20:11:10 +0200 From: TommyDrum User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: el, en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: Re: r8169 native module problems on 2.6.11] X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------000905000008070802080408" X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mycooc@yahoo.it Precedence: bulk X-list: netdev Content-Length: 56370 Lines: 1127 This is a multi-part message in MIME format. --------------000905000008070802080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarded because I forgot to Cc: it... (sorry) O/H Francois Romieu έγÏ?αÏÆε: |>ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 11 (level, low) -> IRQ 11 |>eth0: Identified chip type is 'RTL8169s/8110s'. |>eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |>0xe08ee000, 00:c0:49:f2:86:1e, IRQ 11 |>eth0: Auto-negotiation Enabled. | | | Can you check that the message above is _really_ the output of your | native kernel ? I have not checked gentoo's sources but the real vanilla | kernel can not issue this string. | Sorry, my mistake... the output above was from a modprobe of the same external module. I was confused because the kernel doesn't show like its native module is present anyway, even when modprobed (as you can see from the info you requested). | You can send for both working/non-working after module insertion (wait | for a few seconds): | - complete dmesg (the beginning of it could be in /var/log/dmesg or such) dmesg_native is the kernel's native r8169 module dmesg, while dmesg_external is the external module dmesg provided by usr cd. | - lspci -vx | - lsmod | - ifconfig -a | - ethtool eth0 | - cat /proc/interrupts All follow the same naming scheme as you can see from attached messages. I noticed that the kernel totally ignores native module r8169, even if it shows it as modprobed in lsmod. All logs were taken in two separate reboots. | - source code Did you mean the source code of the external module? It's the r8169_external.tar.gz file. Modinfo says it's GPL'ed, but I didn't find any notice of it in the cdrom. | - brand name of the motherboard It's a Supermicro 370SDA which accepts pentium celeron and pentium III's up to 1GHz (socket 370). There's a pIII 933 mounted on it. | - the name given by USR to the adapter (check the box) It's referred to as "High-Performance 10/100/1000Mbps Desktop/Server Networking Model 7902". The part number is USR997902 "PCI NIC ASSEMBLED IN CHINA IN 2004". | I do not mind if the info is mailed, available on some web site or stuffed | at bugzilla.kernel.org. Please Cc: netdev@oss.sgi.com on further messages. Ehmm.... I'm not sure if I have to Cc: this message to netdev@oss.sgi.com together with attached files... please say so if needed. Oh, mind that I'm not subscribed to the linux-kernel mailing list. Ciao! TIA, Tommy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWWw4gpUvhTIUBAERAhFsAJ9VJRmWH0IwnbYZ52n7rBnJwNm46ACeJl6d GiunYz3TC3+eUx/gi7T2Rmg= =jGck -----END PGP SIGNATURE----- --------------000905000008070802080408 Content-Type: text/plain; name="dmesg_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_external" Linux version 2.6.11-gentoo-r5 (root@Pitagora) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #1 Wed Apr 6 05:09:01 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. 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 VIA694 ) @ 0x000f6bc0 ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 Allocating PCI resources starting at 20000000 (gap: 20000000:dfff0000) Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.11-r5 ro root=341 no-hlt root=/dev/hdb3 init=/linuxrc video=aty128fb:accel,1280x1024@16 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 933.275 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514228k/524224k available (3067k kernel code, 9440k reserved, 1043k data, 176k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1839.10 BogoMIPS (lpj=919552) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Coppermine) stepping 0a Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... disabled ACPI: setting ELCR to 0200 (from 1e20) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb3b0, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. inotify device minor=63 NTFS driver 2.1.22 [Flags: R/W]. Initializing Cryptographic API lp: driver loaded but no devices found Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA Pro 266 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 64M @ 0xf0000000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 12 (level, low) -> IRQ 12 [drm] Initialized r128 2.5.0 20030725 on minor 0: ATI Technologies Inc Rage 128 Pro Ultra TF ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 12 (level, low) -> IRQ 12 aty128fb: Found Intel x86 BIOS ROM Image aty128fb: Rage128 BIOS located aty128fb: Rage128 TF Ultra AGP [chip rev 0x4] 32M 128-bit SDR SGRAM (1:1) Console: switching to colour frame buffer device 160x64 fb0: ATY Rage128 frame buffer device on Rage128 TF Ultra AGP aty128fb: Rage128 MTRR set to ON ACPI: Power Button (FF) [PWRF] ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 2 throttling states) ACPI: Thermal Zone [THRM] (0 C) serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PC Speaker parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected lp0: using parport0 (polling). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) 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:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1 ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: IC35L080AVVA07-0, ATA DISK drive hdb: ST38410A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: HL-DT-ST CD-RW GCE-8240B, ATAPI CD/DVD-ROM drive hdd: JLMS XJ-HD166S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 < hda5 > hda3 hda4 hdb: max request size: 128KiB hdb: 16841664 sectors (8622 MB) w/512KiB Cache, CHS=16708/16/63, UDMA(66) hdb: cache flushes not supported hdb: hdb1 hdb2 hdb3 hdc: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, DMA Uniform CD-ROM driver Revision: 3.20 hdd: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC). ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 5 (level, low) -> IRQ 5 ALSA device list: #0: Sound Fusion CS46xx at 0xfb102000/0xfb000000, irq 5 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP established hash table entries: 32768 (order: 6, 262144 bytes) TCP bind hash table entries: 32768 (order: 5, 131072 bytes) TCP: Hash tables configured (established 32768 bind 32768) NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 ACPI wakeup devices: PCI0 USB0 USB1 USB2 LAN0 UAR1 ECP1 ACPI: (supports S0 S1 S4 S5) EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 176k freed kjournald starting. Commit interval 5 seconds Adding 506016k swap on /dev/hdb2. Priority:1 extents:1 EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hdb3, internal journal usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.2 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 10 (level, low) -> IRQ 10 uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:11.2: irq 10, io base 0xd800 uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 10 (level, low) -> IRQ 10 uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:11.3: irq 10, io base 0xdc00 uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 11 (level, low) -> IRQ 11 eth0: Identified chip type is 'RTL8169s/8110s'. eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at 0xe0892000, 00:c0:49:f2:86:1e, IRQ 11 eth0: Auto-negotiation Enabled. usb 1-2: new low speed USB device using uhci_hcd and address 2 usbcore: registered new driver hiddev input: USB HID v1.00 Mouse [04b4:0001] on usb-0000:00:11.2-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hdb3, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on hda5, internal journal EXT3-fs: mounted filesystem with ordered data mode. --------------000905000008070802080408 Content-Type: text/plain; name="dmesg_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_native" Linux version 2.6.11-gentoo-r5 (root@Pitagora) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #1 Wed Apr 6 05:09:01 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. 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 VIA694 ) @ 0x000f6bc0 ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 Allocating PCI resources starting at 20000000 (gap: 20000000:dfff0000) Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.11-r5 ro root=341 no-hlt root=/dev/hdb3 init=/linuxrc video=aty128fb:accel,1280x1024@16 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 933.275 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514228k/524224k available (3067k kernel code, 9440k reserved, 1043k data, 176k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1839.10 BogoMIPS (lpj=919552) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Coppermine) stepping 0a Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... disabled ACPI: setting ELCR to 0200 (from 1e20) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb3b0, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. inotify device minor=63 NTFS driver 2.1.22 [Flags: R/W]. Initializing Cryptographic API lp: driver loaded but no devices found Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA Pro 266 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 64M @ 0xf0000000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 12 (level, low) -> IRQ 12 [drm] Initialized r128 2.5.0 20030725 on minor 0: ATI Technologies Inc Rage 128 Pro Ultra TF ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 12 (level, low) -> IRQ 12 aty128fb: Found Intel x86 BIOS ROM Image aty128fb: Rage128 BIOS located aty128fb: Rage128 TF Ultra AGP [chip rev 0x4] 32M 128-bit SDR SGRAM (1:1) Console: switching to colour frame buffer device 160x64 fb0: ATY Rage128 frame buffer device on Rage128 TF Ultra AGP aty128fb: Rage128 MTRR set to ON ACPI: Power Button (FF) [PWRF] ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 2 throttling states) ACPI: Thermal Zone [THRM] (0 C) serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PC Speaker parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected lp0: using parport0 (polling). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) 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:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1 ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: IC35L080AVVA07-0, ATA DISK drive hdb: ST38410A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: HL-DT-ST CD-RW GCE-8240B, ATAPI CD/DVD-ROM drive hdd: JLMS XJ-HD166S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 < hda5 > hda3 hda4 hdb: max request size: 128KiB hdb: 16841664 sectors (8622 MB) w/512KiB Cache, CHS=16708/16/63, UDMA(66) hdb: cache flushes not supported hdb: hdb1 hdb2 hdb3 hdc: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, DMA Uniform CD-ROM driver Revision: 3.20 hdd: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC). ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 5 (level, low) -> IRQ 5 ALSA device list: #0: Sound Fusion CS46xx at 0xfb102000/0xfb000000, irq 5 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP established hash table entries: 32768 (order: 6, 262144 bytes) TCP bind hash table entries: 32768 (order: 5, 131072 bytes) TCP: Hash tables configured (established 32768 bind 32768) NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 ACPI wakeup devices: PCI0 USB0 USB1 USB2 LAN0 UAR1 ECP1 ACPI: (supports S0 S1 S4 S5) EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 176k freed kjournald starting. Commit interval 5 seconds Adding 506016k swap on /dev/hdb2. Priority:1 extents:1 EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hdb3, internal journal usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.2 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 10 (level, low) -> IRQ 10 uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:11.2: irq 10, io base 0xd800 uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 10 (level, low) -> IRQ 10 uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:11.3: irq 10, io base 0xdc00 uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usb 1-2: new low speed USB device using uhci_hcd and address 2 usbcore: registered new driver hiddev kjournald starting. Commit interval 5 seconds EXT3 FS on hda5, internal journal EXT3-fs: mounted filesystem with ordered data mode. input: USB HID v1.00 Mouse [04b4:0001] on usb-0000:00:11.2-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver --------------000905000008070802080408 Content-Type: text/plain; name="ethtool_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ethtool_external" Settings for eth0: No data available --------------000905000008070802080408 Content-Type: text/plain; name="ethtool_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ethtool_native" Settings for eth0: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device No data available --------------000905000008070802080408 Content-Type: text/plain; name="ifconfig_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifconfig_external" eth0 Link encap:Ethernet HWaddr 00:C0:49:F2:86:1E inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:29 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:7182 (7.0 Kb) Interrupt:11 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 b) TX bytes:100 (100.0 b) --------------000905000008070802080408 Content-Type: text/plain; name="ifconfig_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifconfig_native" lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 b) TX bytes:100 (100.0 b) --------------000905000008070802080408 Content-Type: text/plain; name="lsmod_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lsmod_external" Module Size Used by usbhid 34464 0 r8169 15008 0 uhci_hcd 33104 0 usbcore 122200 3 usbhid,uhci_hcd --------------000905000008070802080408 Content-Type: text/plain; name="lsmod_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lsmod_native" Module Size Used by usbhid 34464 0 r8169 25516 0 uhci_hcd 33104 0 usbcore 122200 3 usbhid,uhci_hcd --------------000905000008070802080408 Content-Type: text/plain; name="lspcivx_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspcivx_external" 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266] (rev 01) Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, medium devsel, latency 8 Memory at f0000000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 91 30 06 00 10 22 01 00 00 06 00 08 00 00 10: 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: f8000000-f9ffffff Prefetchable memory behind bridge: f4000000-f7ffffff Expansion ROM at 0000c000 [disabled] [size=4K] Capabilities: [80] Power Management version 2 00: 06 11 91 b0 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 c0 c0 00 00 20: 00 f8 f0 f9 00 f4 f0 f7 00 00 00 00 d9 15 66 18 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00 0000:00:08.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) Subsystem: Hercules: Unknown device a010 Flags: bus master, slow devsel, latency 32, IRQ 5 Memory at fb102000 (32-bit, non-prefetchable) Memory at fb000000 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Power Management version 2 00: 13 10 03 60 06 00 10 04 01 00 01 04 00 20 00 00 10: 00 20 10 fb 00 00 00 fb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 81 16 10 a0 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 04 18 0000:00:09.0 Ethernet controller: U.S. Robotics USR997902 10/100/1000 Mbps PCI Network Card (rev 10) Subsystem: U.S. Robotics USR997902 10/100/1000 Mbps PCI Network Card Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 11 I/O ports at d000 Memory at fb103000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 00: ec 16 16 01 07 00 b0 02 10 00 00 02 08 20 00 00 10: 01 d0 00 00 00 30 10 fb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 16 16 01 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 20 40 0000:00:0a.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01) Subsystem: Micro-Star International Co., Ltd.: Unknown device 6834 Flags: bus master, slow devsel, latency 32, IRQ 10 Memory at fb100000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 00: 14 18 01 02 07 00 10 04 01 00 80 02 08 20 00 00 10: 00 00 10 fb 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 01 06 00 00 62 14 34 68 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 74 30 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, medium devsel, latency 32 I/O ports at d400 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d4 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00 0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 07 00 10 02 18 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d8 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0a 04 00 00 0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at dc00 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 07 00 10 02 18 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 dc 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0a 04 00 00 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 12 Memory at f4000000 (32-bit, prefetchable) I/O ports at c000 [size=256] Memory at f9000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 00: 02 10 46 54 87 00 b0 02 00 00 00 03 08 20 00 00 10: 08 00 00 f4 01 c0 00 00 00 00 00 f9 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 18 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 01 08 00 --------------000905000008070802080408 Content-Type: text/plain; name="lspcivx_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspcivx_native" 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266] (rev 01) Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, medium devsel, latency 8 Memory at f0000000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 91 30 06 00 10 22 01 00 00 06 00 08 00 00 10: 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: f8000000-f9ffffff Prefetchable memory behind bridge: f4000000-f7ffffff Expansion ROM at 0000c000 [disabled] [size=4K] Capabilities: [80] Power Management version 2 00: 06 11 91 b0 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 c0 c0 00 00 20: 00 f8 f0 f9 00 f4 f0 f7 00 00 00 00 d9 15 66 18 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00 0000:00:08.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) Subsystem: Hercules: Unknown device a010 Flags: bus master, slow devsel, latency 32, IRQ 5 Memory at fb102000 (32-bit, non-prefetchable) Memory at fb000000 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] Power Management version 2 00: 13 10 03 60 06 00 10 04 01 00 01 04 00 20 00 00 10: 00 20 10 fb 00 00 00 fb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 81 16 10 a0 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 04 18 0000:00:09.0 Ethernet controller: U.S. Robotics USR997902 10/100/1000 Mbps PCI Network Card (rev 10) Subsystem: U.S. Robotics USR997902 10/100/1000 Mbps PCI Network Card Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 11 I/O ports at d000 Memory at fb103000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 00: ec 16 16 01 07 00 b0 02 10 00 00 02 08 20 00 00 10: 01 d0 00 00 00 30 10 fb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 16 16 01 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 20 40 0000:00:0a.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01) Subsystem: Micro-Star International Co., Ltd.: Unknown device 6834 Flags: bus master, slow devsel, latency 32, IRQ 10 Memory at fb100000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 00: 14 18 01 02 07 00 10 04 01 00 80 02 08 20 00 00 10: 00 00 10 fb 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 01 06 00 00 62 14 34 68 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 74 30 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Super Micro Computer Inc: Unknown device 1866 Flags: bus master, medium devsel, latency 32 I/O ports at d400 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d4 00 00 00 00 00 00 00 00 00 00 d9 15 66 18 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00 0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 07 00 10 02 18 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d8 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0a 04 00 00 0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at dc00 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 07 00 10 02 18 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 dc 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0a 04 00 00 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 12 Memory at f4000000 (32-bit, prefetchable) I/O ports at c000 [size=256] Memory at f9000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 00: 02 10 46 54 87 00 b0 02 00 00 00 03 08 20 00 00 10: 08 00 00 f4 01 c0 00 00 00 00 00 f9 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 18 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 01 08 00 --------------000905000008070802080408 Content-Type: text/plain; name="procinterrupts_external" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="procinterrupts_external" CPU0 0: 291227 XT-PIC timer 1: 1521 XT-PIC i8042 2: 0 XT-PIC cascade 5: 0 XT-PIC CS46XX 8: 2 XT-PIC rtc 9: 1 XT-PIC acpi 10: 90 XT-PIC uhci_hcd, uhci_hcd 11: 16 XT-PIC eth0 14: 2511 XT-PIC ide0 15: 48 XT-PIC ide1 NMI: 0 ERR: 0 --------------000905000008070802080408 Content-Type: text/plain; name="procinterrupts_native" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="procinterrupts_native" CPU0 0: 788943 XT-PIC timer 1: 2185 XT-PIC i8042 2: 0 XT-PIC cascade 5: 0 XT-PIC CS46XX 6: 32 XT-PIC floppy 8: 2 XT-PIC rtc 9: 1 XT-PIC acpi 10: 2201 XT-PIC uhci_hcd, uhci_hcd 14: 12762 XT-PIC ide0 15: 48 XT-PIC ide1 NMI: 0 ERR: 0 --------------000905000008070802080408 Content-Type: application/gzip; name="r8169_external.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="r8169_external.tar.gz" H4sIABJRWUIAA+w8a3faSLLzFf2KXmd2B7w8JIGx40fOxVi22QD2FTBOdmaujpAao2shMXrY eDLZ336rulsPQI6TPUnm7J3o2Eaq7np0dVV1VbdwcKC0Xza++6KXDNfe3h77hGvzk90rsqq2 1T25uQ9wRW625O/I3pcVi19xGJkBId8Fvh99qN9z7f+hV8Dmf2De0Znj0i/D47n5399Xsvlv t2D+VVlpfkfkLyPO+vUnn/8XpPY5L/JCekESayIzPyA6Nd0xvSP6uI+mFjYOFEUOyYVza06d iGjRnAYejUjf8eIVOQucexpUiSrLrQb8KG1G8XPLKJmue0gsl5oeWfh27NKQOB5YgutKkgAc SqXvy4POa61Cal0SBlYj6SpJDLOgA4NL5I+8JDGOAunSEeIl5p/7v651zgbal7KxZ/xfbTU3 47+iquo3//8a17HwS+F/d+iMLrGZG76SwJR/pEHo+N4hUesyPJ6ZET1EO0MPrcGP0sZe47kD HhQS8OYiSiSg4BkhtVlIgP4fGxUs34sC33VpUAebPdbpr7ET0AX1opBJV0v4hH4cWJREAaWk HMbLpR9EwO6eSx+C9K36igBztd6uryoM1fIXSwhTQWMKEkeOGzLpBEHeaEaAje5y/N+xY90l LkQenGhOloG/pClCSKPI8W65XBNvaUJ3VAeY1xRRwCFj7zdnSZjLGS5qyQ7ujfvVqg5gxOrO Te8WMHyGaMNIrcgPHgHTsjka9urNyKMfEzOgJIg9D3gmfG5BY1yaKoI81i+c+7FrkykFVHPq MvK2D+JIpQUE6vUoWCqbIUFTR1WxQYax7VdE1ySAlGy6BARSM1koOT73UfcDajsmGS0ptVEH Y5BpwUAW0J+y1cCCKQH2vkeJP2NS7yFniL4mKt91/YewLqUBtLuwD8kOcEVmbPyC4gkZaWNj oJ31Ojtpb5CC0JW5WLr0MIvBxejySm7twABhXphY5PryLZMMJhQsHEZKFFkeLKchuTTdWc2O geoqJ1omgBje4VbYNxTZQOTkmXFVCrudxyBIvpta1G2NHB9DcbccOdbtoLBbvh92U2SJjY/P JtdU9Ljky/gidiMHdACjDewQvIPbFAF9QTN0hhk8lD6o9hMUuIp8dljHh7ljzYvVb0ZM/dNl SOaZ+onp2QjnDTMQPpsXsMKOfW96aGEzakZxQEWAGPFgEJJ/xIupT84Dc0FZwyWM5AG9aLxq 6CsyA+NL4k26PP6/v/j6j+nBl+Px6fUfJAD73+q/r3Fl8//lasBn5l/ZU5WN+Vf3oCT8lv99 hetPWv+9/lHTc8vh4Qn5vhzOKSyHsQfrA6kFFen1WW+jT8N1pg2RKTW+LyORSmMaO64tvR70 Rt3nO/PsrMGz4rABA29Ir7U342JZqDX3iUAlvxPMn2uQOv0QNv5H/bn+0157/5ef6/Xdxl1j +UPFl16f9zsXa4TUj6TU4nRaSGeVq4CdGf2VlAEPKVeqagsy56ysnKUzzbNZaJaoG9K1yhOQ QY8VMpqcwufo5Pvy9c1ZBSNOWk5Tz3ZmUlZVBwukvVv34fcO/vwLluWA7pI6pJ3wd7du4x9r YUM70Khb8GnCb4jgmWveQoWeK4OTnL22IO1Wi9QsnpTUQTLQfAUlxMmrINLM2x6w41lubFOS Sd7YGHd7JcZA/uMSh+34n87lZ+Px3PrfUtob8b/V3JO/xf+vcW1Ea5NMzdCxkpqWe6gkdbul EoSTW8uSBldnXXSOEQJqV21Su2HOdQYNk74GN4bxWtOHWt8w4KHfG07eSEPtxugNu/3JmWZc d8aXiNojjTgMmOkxi6ttReCG8LxGFpFE8ezVLQwy3S56byoRPmxyqqT+jkik5gvn99fCDcaa 2uw/znk/w/Wk/7e/mv8ralPd8v/W/jf//xrXnzP/29wO+aqXxHyu5k//N8QcLQlO/h8sFcgD GdLfT9IA+ceK8yeMxX/ElcX/dJH87Dw+GP+Vltps7W3W/y1l71v8/xpXY1c6+VyXlCVah6Tz 0ZFfHBHhYrF2dMSObOrSZwn+kkQunZAfppBzOiWkhWuMWqoRK6AmHhU5nhM5kMo+kukjGc3j Lh6gHIfz2IKb/4JObkTv6pa/qEcPr0CsgfkIJBIqHdsmkDjdETCnKA75tnYNzzbYrvX4tMcO Oog4mqp/Rq1LQsEGFPej3tWQ7Ch1Zad0jJI1FLnReiVJJTyNAa23DmU8eRn0eiSgt6ARUHwL D+4sGDkoYSekLjt0IjOHuvZOlUk/N+/ZsdEUSnvms1N8cqDktXC3XowJCfc0TQMV2ORAVutN YscBHk8Nb0BXy8C3aBhCL6lEVxYedWFbH5XWRdXc+IFNyuf960q9cEwqH1Oz0W4o+6+k0mRp I3dhPrxCIFg71KXSwIdy/JH0Rno9Xcdwiqy5syQLa3ZbzKKZsVDlV9uYS4ZZwuclsK29Ws4f jchZ0MCIqiSIXEYwBzRgmLZLg3KFYyVd5g/G9eVbw/K9mXP7RGNAQxpBW5GgrUTQ/YYC88vQ o5UxfYxoCIKIu+JB7uVwDwB3BD4or3BecVbxJMbEuZyFHD7N1Jlqr8o0IZXyR0Vbp0T1Iubt hPlBQ917lVIOqEVhGgnMKJSg8WzGDnwL8PcT/JdceBx47mAn868i5IMEGbxCVQD7mp9e4bER M/Tu9YRMIsd1fjMd3yOaN8cmPG4uJvgyJag21JdAUPPYEev2iVIRvlqXOT6kus2G2gb8Uwrj F4fWoHdxdsV0y8oyfnwt7UJJLL1INqaOWZPYa6zPX221LC2nCAzB16b3jlWIQzE8P91sU9d8 LGpIhIemrTbmFEVIGHsZhvTChtLBo6RQWWkr32sYdgYa2ZnUR3Wi+1M/cqxwZ4vAmd4DGgbr S9YQCViBIrNfmVx3e2TY6ybRRIwCOm0IktK/Pn+zRu2Q7KD4sQftGXPtdHKxCfzHZHB6ZZzr gGaMJtfXV/pYdCklXS5vjPP+1Y3RvRqO9at+2m2LQe+qO+5vUMm4vwXRet2EisRsZrYtXykZ kxmGNIjKdLUMKuTnNPyVnFn5LxxaIe8w8nnRXZnsdFh3VNPMhHLP/gv5a1jlPzCt9OSv9s8e rCAvELNqGOe9vmYYeDMZdsegS/bQ7w0BWjki7zM5zk4vjGu9NxyXyWwBgdUMbsN6vV4BWQTz HZZpgM55hxcvWJ/KkfSCb0AXjsj2ybv3eOwMHlqWKx/FDyni1m6p0SBwg2tcoQ4lqbErAqG/ jNgrJ+Ckqb123hiTYW88IgcSJgiOBatnxPv/lDb+Qk7Iu5pSJU//vj9ijAbmylnEC0Lv8U0Y UoZgg++b0AiCP40skBwiOV96MJhT05ojQxoE8TKqo2R5KcyVkTYaD35wB3Ko8jonD2Is+AUM n8V4ywwjYto2rFEhDZEbFPyYTJTvQ/DGVQ3SiVras8IWYUxBQGlsFQlJHIJopN0ikHBggAVx wzmJWPicsleFwK7wDZE0T+zq3TrZlD1hYXD+hussILc8IU1VyN/pJnISl3q30XxtWrpG5+xM N8CJE2Nv52LQG7DZ8ytjfKlro0vevC+6Ael9mD8T5nl4BXICg7nv2lUYu1i/gN09ZLFTCsGb gnoC0BhGmRWubSRvHcDnbNAxTif6KD0IyvFJpgCRpzGQqZIf2j9g0gZFUytPaPy5CGnj8Xyz IpdXzXNBiN1uDx4p5EhcGpfrqiVKK20+0847k/7YGIwnWfOeLG91AOWcTs45GWWv2d4OYoXx NOd4+XZgVyqzd0hkUlnrBXxGr0/POuOOMer9U4NeBbjk72vjqohw8wE6RGnjoFgMIY0GhpCP ED9TYw8dk6U2F+YynQm5KWaiKaZhvdsJcxyYkwCSwIi9bpWfmuFkYKCpaLkTS3BEQXKYevp4 RWwaWoGzxIIgqRfCnJ0gJf0jKOlPUlpb8Y1BbwhLGlccH+mBnLfucW+gXU1yp6Xl9u7lPytb iz720w3tzXVP19gDTjmoH/7ySP0QOBFtQFFnk8Ggd5UVQ3m3BIFuDsrQVCX3pnuAywHDm5Jy mQGqxPExuIBZYLdKZR1XaafISrvCcR84Ljw/g9xUU+SmKpBdjgzPH0bWmdSVVEs4ThD6gyhc 2Eoe5eEZFC5iilIux17o3HoQul3fAzjScLdoVHJzPuieXxgDcKmrM0Mpldj7cUVtKmtTC9ua rK1Z2NZiba2M4fU2Q1jZsebR6S13LKiS5VqTnJyIoqgQVwj0DK5SiCsEfgZXLcjWNvK5NIvm 2ZCBNfwU0oD6fCeJOMUhZzsxhCoFAoVYWMMoiK2IvJNKHAy1OjgGVtZHUik+YBXgUamELm7T JcuKvIQ2JFkWS31KcVMFv++yCndghndHpAQI4m1UPHsLWJSCYYcke2F3+ghQ3I/AUhPIvMeq 2MAnyFFm/k8sR5JK78iOYAgJ5roZVTFszGb7VDk4kMn7ar6z2IPaxFH/DZzmFg7mZtK6CqHw MngNZThZfY/QaOrCWAzWCsUPq3vFyPANSWpVMfhB7you10Zn+Nbona3fy/xHiAtYba1bZe+Y Ku2PxJKridy8lIFI/mOvCyGzc9rXSBkErW5KXcHeFNLB1JrScI7iQ0ol85dOq/ig84cDeBiv zmAJGEVmEEHRHpQQrsqs4XKthTUgxnm/M7pk/ZrYDwownT+14akLJtFd2Bywz8hc+67LnxEb lsQA7Y4J0OwKyIhvzzGYxrC4hTJIC9noa5AWgwycEDNSBkFK3dnty2arzQB7iMRRZMZ9T0kB CgeoKUDlgGYKaHJAKwW0OGAvBexxAI55gNkujoIzRkkghHS4VtpMl6e9rtBSu8WfYeY7OkNo HwhI/zqBdDiJMNNKu8tHbK5Gzm+Ugc6wV/fajUNQOINoXFHbE6ohU8weIaxxAJI7jz1Lw1KF gc7lPAiniINbAnzNNr5woihvOBANbLcpR6fLbbfQGHFrLcKyAmyysdtLyhs+/acQczBEjd6O tCAgJUbuAIIuaqM7GjsL6secSYtDRzdAgveTFVlOzXnimfdQ+woCTClYMlzhHkIpNSnc4+zO b0lm8/oKu7ANohJ/95qRZNLwV7bZ89Vr8cjNMGtWOY2kGSwOh6mv+PhQMhyfvoLChXujrLLT Fm7felcA5YMUqE+GYw5Usp76zVj0bAkgshGul2gRbnWcMZIOBCErzZuSdCgAGWcQPprTeKYt ltEjyQ9BeFZKmz8afd+6E5Jk7mdMPDeBd4VswcrAfXZjKgh0LIsuI1RcqnsO0mMvJzGHnQaQ qrDSNhWcNwzSmjeVXzQ8Xs8fQ5LOCYd2XDcDp3PD3TkZGTzPbtFWRnNnhnSVZlVAoYZLgAcc ebyBPF6tJfxJb7XFDXMLP4nhqaszIhAJ+H5lZr7j1TnYZDcK3Mx69XUY0yH7/sB0GZ5n1osg gJQy+wVIBmgJP+AWmlkxfgfhLF6W1gz5onfROe2NxTZ4Vi1grDK6Yx2ST+0C1cvDlzEad8YC pAhQZzK+MobaxZWAtwScffEhR+LlNkdoMOA+4QfGjTHO6MSRbwzprS+ElxPuXIkb7UriLo1N AY+EgLy75Rtdf7EsJV6a4WyNQCB2zWXy1ZJSDi3fhkpN2lrrbQKRtx1stjHELMolomwpbU2U NTyV4yWt153JSEtMQM6z64zeDkQzt5h1xGE2BD5DBvt+0fhxSXFiUg0kZlNKx52a1sZoWwko 63WQmHIGUxJ2fCkFjxO+gsabBlweTWWRPPElyBDLIV9gcOG5uhlCHEpXFxFWtSs9gbYy6Pko AaoZsJ8CFXmNo8gv+SKErCDbLpW4bx+Jp3vX9IzIvE2ep/HMwEos/3zJAUhTkNQ/I0kJvz6E hYegzQ/FXHBnyCqTI7LccNJUM3Du8WgPhLj3IXHeXSwcnzPa3JVKLrb7uvCDR7Iwl2QJ0Rfi tZts/eEUrqfkZFfcbFEESj3Ppivct8CdMp6/sw27hIZHoyStR/2ErHAKj9ZosEIgxDMJJMTO uTkhRmfpsKXLiAh+fGhU2JV1IvhmM8PGjU+2iUpBeeyJVWT8dslvM/2KQ3n2hPOUr9EJXS2d gLJGmIeNRjzHxDNtw/YfPMPyoi10Kw6MYFUkfqpFkIl/nXF9D0jskTLVrNDqyPKO70wXsIg+ ksX432NhO0H0iExyDVjzlna5f3WCwHzcmN7URIDn2RbPNR6clP48Kf0pUtzsRMq5JtVRkT6A lLrXrpku8Gdb60/KKAjrgrD+qYSfkzi8MxCIIhvhHd7+lNt8/OVoTZGB6YW4eZ87Ay6kpa/R 0nO09O1T5O2pgAHZASu6DTy2QrNnDhUHgbGIYiOEskf4UrQywGQMl3oCEOQAHDJ/MNaAz+y0 JBFEbNhM0T2jow/uD29t1mwNB300idP5Yh4SiMsrnZR3dP7yyg7U7mmdP+rqvWs8hYP2tSPU DxyL5ghABTkgZXaAVSU7Sm2HGIZoGo313vCinB5rVciOk8Ps97racKSVdy6u+zuV3J4JU7BY Afwl9Uh5K9ySXfgEnAIMnqOt0IASPGExZBfMpUqeJIZzRth76skhL+j6TCPHRLzHLqBltbpX lSsJc7YyJdzT8zNSRqGc4Ncq74A8DPYNFM+iqRDLCNPakOzi3/TUMhlV8GtAozjwjOjz0edf sSkWHTyBvabzrL7X8MDymc4/bZos1w/px6DgCTLBPUT2IoJhBRYfOj/Eq5J1J9hFl39CUFgm DVEWfuIQwf8jvhfwPOJTqUFae91CCwMVkeKvYlS2A0jR6VCRWtl/DsD49YSgVdbdow/Yp/Lh iFN4IvWECWRvMX26+WQvOT2HyfehY6WddwgI13x7L9le+Z3ktlXwId2K+Z3wvRX8hBwe2/gj 20PZZJNYVl7BYEBWsi1Y3jgYPj4m69U8fsWuvHaqm3RJSnPswY8X4NKOCl58udF7Y824GPR6 ST1aFmc+VcIOhqAygKqDfd5Dplv5WXpHfuaLEjwfsftZOWk+gcKTVN4Rdk/KKRv8zy8plzUO hI2Cox8fc24VAP6NbXtDWD0i75EJhq5PpPs3Uv5XmZ+QpJSLSBfrYkMPbPA43PdPvuCSzqjp QiYNcwkLAuazuINwtKX5Tr9/1YW8YvT6tAzrB+YDlf9r70mb2liufV/Fr2g7BRmBBBqBbS5C pIgvJFRs48g4y0s5lJBGoGch6WqxcS683/76LL1Oj2aE8ZI8q+7FUu/r6bMfUQI4S9VlZZ3e SDW5sSHSTR63jo64RVlOtva+N0kSbAl+p1upVgOtvDo6OzmWzXAbJXld+j1ZaWEbjoD6XlNc ejZLDnwx9sPaNfDZ2vp8ZdmtLWKZwxegrUtvPl1fjAbwczsulY4ljYXfa9V6XALgNPmQdCGl XqvGT0tPqqC6DCdxy9GhZToTCsZPqrVS/DSjILxTDzIRBKZZF4RQA3VNACS0kstD/UNemXki yiu/Irgo9QGZZaGzvMK4PhWLZ4HQjOqv1W6Oj8v7+xIS31IzZaCaUBswAowRnrBSbzSRlxS1 iGq1hvx2IGoC/pVHsiw7BWWq51cJ+NMhLzBKeHjVnqLjnUECskCQeaN3G6LupuOk0+/1ZYa9 orI1AHOP5BBZJo3jL6+Z8Zep09LFJGm/l8Mt3cn/EWxBqhl8GfOMoleBdlfs8jDtsiQpR2MJ ix5ij3HjwgA1c4f1top+hTe6KapxxhZn7O0X3FSJ2k76IPS8JDKtNxld52+vuwf4UOjTSZur pgpIYtmvgFM7PsZ53e8cLBxA1ikoER5P29DAB8oDb57+pifQ7486s8Fm5/FCCOk2cX+lAd3N ioWNaPQn+WWeTJmnFBEjr8L8POIhTdXP3nzYUd9xh0GVlFGTvmoB/+KrXcKv1QNuBXbQVSOJ /qffk8diKjbc/pzaLD/3q5pROKVhiKi3KmvQRVJFIYeKyouVHqtRFH3srAgoWdZuVmu7gxtU efXGYVq4Sy+tPHbyYqiVlb80404vnE6MrOzUiOyGcgbkNxMYliSXFu22GVy6YMaGWVjaQ0DH YiD0q3XkEDchCxAE2aV1+2IApA6TPnAyAzllU7theEke13wdvlgNpPLLQp4jMF6RCQDr7LdE 1iPLFsNyl7Cf1ahVVqd3KaG/o3WDoNUtBpxose+qPgl8SjRA3Y20RBJgqpEPElA3NjYOGxrQ donaAvhW0DurJGLj9IRkFTmQlFGdHxEJxU96ZMc1Qg9wtYrycAbccIHU6iaU5CksonXSgjOY Y0psBs9HqYTdO/AlQCfLq0wvWClIRYOEgZ84ectKuesHC3iHMr6HMLFTlnayOQ0SQLe4La5B ATqRMKHTB6bxx/YnQOnmZL4FTz8BCDI5gye0PRRtCaDB6AwtRh56iBJLD4C5aC1l01WuoOJo md7u/3SoRZN24JX4DuEVwY8oGxbJa7am8kNAiOkB67Idn/xNFnkjqgeLQLi6fguuFWQvfATs 5UQQli8ygLGmxQbrE+hwjac5mZVdOGdkAsD6saENQhoX94u4OsKDpWQRK4sukiV4lBeJ0iyB 43/wtbI4tFrF02W4X4zaYO0qUlJp5NUGrhIy+kfzmeL783sNSXgvvUf81dsXLxpZtzXnLiph l0Tj+ymRL+IFyPiv0Hd5TPgbut7i7yQNUyiBvI0wu0c0LoMqKOVwmIWVu1KyZmcmo5ZAp8C7 gI/ev5LJCBm2aMV9rmwXl5XslAiSOW2ICPqSW9L/VyKfpghXqGwszagKsc1MnUBpIq3kFUVo BrcSZysYfRnO3osIhnV+1GqhdeHj+VD568XmgXtP0pChQQWYwqwevTp9efSSIEoJfdOStO30 r6+OWtFiQddB1nJAO6+Ozn4++gsoBkd4NNfGCIupRT0rBuEaTPPeJDQDPnoRkJ6bKFN8/VKi Ae+T+Zjsy0ez8WB+CS6U52PZ76QDaKi8ElRfHV08RDBrWMNJB/Cmy5FcnWSCBwX6NKeTW5CY EXqGVrIqul8xtKJOr18SklLl8Gz7JSkxVVaefb8kJFnlcHHQpfJ0PknIIKsNBnFweWPAmsAq hSb6KLIGsCZOTltHb07ftp4fyffsZXnR+QEeikRjfxOL4WgGSBWbutCYKqJ9MZoAg02fJVh2 OElysxupxWVUUXSQxwMWyR+T/qS7dTEZvZezgzlwh5NkTA3TBDRAkPfON/JZNPyT4Yf2QAI1 q2W4VtG0fJ+hW6dKke7UqN5APLxg5bD4iJljTXZ00+p1GzhVOF9oHuSNlKRPLFXrSzwYtJO0 xdFoKDtSEFvlRikIK5dODUmVzgcenfYQdt30mLloJ6f+ip0jP18eFLV0cvBvRr0Z0T+IsoP+ 0SazFHflHrNOcEUobWB1yoklOLtqm3rIEexJKDu9An/gMlXRVXCqIuAxxobHKP+pVhFrwcMU MeHIHQJJpbtE45l8Xq+I4prBd2hrupIyQRcHJOS7lnB21CXcy33/0P4KhYDMEVS6ucBkfNYh piBOHrExLi7L127i/f36rmJGW+hr07VZskctQm08zW1jO7eN7dw26tltaMllLa+ROLUFuUXv vFVH+T6Y2zn8PUgtR2EKnAnwbdgROcaeRo2pFRq/M/IxDed11siFVzvOqx1cPFW7nld7O2PV FhTFa6qvz2Grdfh3grCRYz9VFlUR48Vq+jfL3pimZ3XVf7cJGQRveDCsgQiQC1kOCECu27PO lXO1ZNPz4fuhpJHw7lfAJH8ukf82aJlp4+/f1CpiNOlf9oftATwSVZQc9IdsDNYGTMuBcygX JEhnKWmuTvec3pQfB+4VhA6qcWSLEi4zHYxm5wrw+5MDO3ic1Z6PldIPFy8l5JqRMqjqQ9Q9 eiM4Hob7BJVNeQwWoW1ZSDtEMBpH4lb9izubdJia+qoUVT6hA8bHUZjKUUaHAVO5dXkoFrMb XAIni6fApbKIIz14JMdkxzcsLCMBGv9LDh0wR75v7XFcA3oazQ/oJ/0oRO/AYbcJHd3xxgbW h9sbIhRpxdboL01E4wQSr6rR1eSz0GdsLYSVu4RXaIgZI8fG7KHLZ/MP8orYHha2tiwghA/4 vutkQSZtbCDIUVQE8pglgJEV+GUXaEO4ISszh4TKgkogGATYKoINzruCRbQ0AK1iJlUV1opY oNtqldTpquB0NhoLu0tUXlO5lnKYVcSk6lYAHdRuKlD5vRnSTVPlPwKw6Y4uqR1o2xi+qzL9 yS84sLH6pTKAisAVxWzfIFtBrCJKZtSe0Stz1kGn3kORbKH4ko/FiESfzuJjyuL+PFFoHmNN sc42CaIg7F5OEzd1wUokRFBgCPl8cCnU+03wj3dOvzZa1gI5epO2topsE79XtvayGhHuDxcw qsxWruvOQpedLFHW0X/WwiMraUPsNmAqyx4Tmz2bzcoXTMs4YlAecFOsdgU+8yrJKxleOlUp kBus76ysW9lkBWtOsmtOFtf0V92t7OR69XOXkoxTztE6BV9zxc2FFMzPQEsM8dudfICDb8jq MlkTyIuBH+YgoUr5OUvuSUSwEsTyHgNad0IUWj9hV3wYmUjihr9dnf52EyavyfeKi7s6CN27 TQvPM/2cvDo+pW5Wpyw6H9xUxGOUtT1erW/Wb/YW/tVlT1p/FuT3Cn+bQeHPgFMyq5wG3laa fiFr7/gc65T4XahcPVVuO1huJ1XuiV1Ovimab8H28K//+PcVX/DIDgzVCbAO2htGDcC/xfON 5y1xqjwK7tav2DL2im8ve1rBvArTV0rOY5El+y6Nm5LiQJdADLyQoHfY+dQE+zots5FnE32o 8JDRQSKfUHCP8OLw7OjV87+T55gKmuYp7MMbRdMjk4PDKDrzjKmnp2U8hVxwGzW7jYVqslCp wkS7bF1u6UdME/ETURM1wwTpoZ9SeamAcyQB9cUg6dL8H0Uheb2xIGZuAmgTkiZwAdm4a98a 0H3P8oKHyl7itikcI1NxK9KmpcJ/0T3N1ExHe6WSxvojQxxIqtkya/mdXL09duKmy7xrkCoc ucZUOnAYT86Y1YAkbguDuQHmt8nsCe4R9Oo0gwCc3Xkg6ti4lqXF725az5yCb6WSQ6mYFOv3 9GNf4pq6Y+q0BNS2Dl63h0luY54RcsMu4hQAG16VqxlyVgewDDkdoMzy9sG6LDIpDrN3+0WH kT/1QKdfY2TfcGi698D45L1tSyJqL5UDbLJcCJgCNzYdfyuQO7dWu3keH4syQchBAj6P02CK fSjPh0QDdYv27igCGbaBYkM7nL7AnQdnAdVhcjma9TEkqb75qYvPakwsoiCgY8GblxJsVMRD z85dW9wjb9dzTkagkC7l705qijxBnNs99yOglYX9eFrANoQG5AiGwS5/2/4OgWBzQq4jOLOv Mws82ranC/rlu5ng1Uq5p6BD5agz00g/tvvkSjg1VvbNLYtpLW90OGCLYLSKXEcpeaeaUVre UC5bQc6eofKLoTTjXKcY6kXyVLOttzmFlVC+tVdrQvsqUc1l3DEdWfTYRBbliKTg0Dj0xBL0 MZc3q+nVKTa8Os1rtsLwrRQ5w5eVAd14LL8+liiH/Bd0enUR9qGCReA7loEL9Vg44/Sgphm2 v8Bp5fcF+xiTOnwdFeF1VXmQqqAED+oL+QdvJW9PF+5oWuVJuI+JA2FlU6nFpWUItBNcZAOd 9gxSwetqeygwC7xEy1bDdrv0f4oT4DQJGt/1G4sTYHIRCFjb6iD6bUL01XC902D1ufiKVLBV dOi/On0EwzBCUnSmwjQDeVLB03r6Jzyrx+g/+rEoMEpbuvLN5B0oT0CBR3JjCTwmyfXoQ5It 8lgs0YCilx77pJwv4iiuNrksgz9TAgVaC/MhKit4DEzkrCySby2rkeXIuljlCmVpNCKdofSQ XBaUkpvwlL6pfKyQawPrgGTttyXNITW9BCx0G+iZUy4CwAswmz+7eX31iUz+WuorSZg0O8N2 g6EMhFf0E4YPlwrWwm7xcezk7N17uES2NhoNEIQerHcD0otIcZkqtkk3+TioiDeH52/+eNL6 s/0yClv5C5t0ZF56GVhh5SE/itltu4OR83l/jXp5keNQeZ01BdUOU53yRv3JU1ERfzh+zdER ccEkpCPfLNqHyjBJulPwsiIwgofQvlYa6OGS9lH2/aEPHn5G5xfzaZQeHLQNZwGs9WRTVRHp utXIfBcHB2K3vL8v/5Sd9jea6iil2rYgDnufWi8HRiA2sAXiC2Nua8HitTIWr5WzeK3ii9da uHithYvXshavlbF4rczFawUXr+UtXitj8VDpKXT8CFCL21sRWl/OtTXEDFL6+BCWHoCKPTa5 gPY+0zVXPEaEufK6WveW76OlPOIcQYGgO+NwWpVamZX8TQmDF+Y7khZKwPOLpS2M1E2/WWv0 961T11Ai6RKVDhnJBzy7E6YM0BSqPXIWHJs6Z/NxEaH/mTryFURMh5POJiq/nbwmy5fpJooK NbZo/ByhdFx+D6HuC6A17aDWH8ZQTdhgmJYJPQrorVCjn18EtAb80CjNlpSnGVub8p62Pzlm H45ZJx/+tOWCOSQpT/PWuD2j2YJmEZWwPU4FfL+TrSqsAhhTyuPSH+KbHCE3wpoZEZ1ROeDx gqOyWA+rE5ElVYNlflqj6Y446RI7L4bRfFMcfRlvM8puXqIRFfR9h6XZepW3/UktHyG3EbR8 00pv08iTrnI9DjyRAIevoLOVmiA3M7vIadTeVRr5jlVqyq0KKN+M5DkDCh6uJhDx2hCSYW++ JaTqfdfSGA2tb7WK0Ma3xLeJd1uv9w5D+UThvQIFR2GRPVnFhDHv+y6OaI4zpSUJhLzzp90F rQS0DEDc2VztVix7Xo7pZPIrJi+oqfBt2khLbVPmyubwZhoKKj1da0BWI4+aMdgZWhVk9bo2 0QUtoCutT46RkNWlxgE9RzWGIuzq7ZiFt7ES3m7Hoi7PbVykdh1rx5botx6T4BfSCrWwAy08 fdJ5plvYoRYgLbsF12eVbCSOERRQG7KJGP7DIRSSGe8wFKkRDMsf+I6CYqrDJ2DpXWjO27Tk bbPkLCyXSYXWjLdsVy+Zql/bLVKfN62ul0vvWb3Q+Gv+pteK7Hlwx2J/xxYswNJbnvt02JvO z9kzEEzcf/8XnFhv/3u9HX//Ianw/neTpzVv/yGp8P7X4h1//yGp8P7Xas+eefsPSf/u+9/+ vP1vF97/bq/m7z8kFd//Xj21/71i9zem8/fTE2//Ianw/vfaqfsPSf/u+3/xeft/8RXvf3r/ kyX2//Pv/8VF6v5fLJj/v8f+9z5v/3v/b+7/RS91/yHp+9j/wlivrs5Yb23Fs6yzbeOavruh 5RB4WX9bY/CFkFKJZf0kTPlbFeuh0AGFyhalXajCsUUMFKtSO0T8/acnT4tXwUBi3YvtpHCV GGKL3Wy3n3WL9/IM/tZ3duvFq+zi351kiSq/h78/7VzUiq9y7Scc2bPtdvFuEvj77KJ3UXzJ UCt3dydO7rH/SywAAoNnndoSC6C7MSpqd0Z8+h2wSha7Hn9oLgkIVPvEeF4PWsJjmIE8Y/j1 ZYzhscV8e3ill636FAGDeKGZZggzXSP4uxV74BRYq6K+cIQto6PvTY5iet0KFfDLKchh4Cr4 RVkMHssZXbKYgreGq8RPSxIbUIHnbJeFGMi2HLJ8Ua2CinzrRhkqGN+htjWl8eB9K4w/Tx2i EhduoeWIHcxSTxTdqaqciuiX9SmRQ/r55SEFWkaxJmoEYtyuHsTtEhCpF0LNmbODjZ3pxqIz z4W4Ce2FvrndoL+Ynw4LRhqTK3qR5QZyJL+KDvyqUspqQeu12nY1jqvxLrHJAnWjVOXbKN7f j3fo3+1yOWjIEDaMOKrtge5pdRvXCL7FO/wOKxHf1pYahCyO6FX8JH6GXYSy6m1jXmFl1Hcp Q1nHooGXPBpsv+tsgxPdsLJY4l52D4RXWWyIHYKn/rnJ7aOV2Ucrt4/gjcZIelDEAQNuwxTu sqIY6MFACkoTiFdY1tPRKc3B0kmExB8r1ximkorS6aiBkGd/LEmuwknD9Zd5Mjc9p+VQ+c/C 9/B45cfbuIcSUL8RPNBW0sxNUjGPOPE6uQbJWOpc44mq2Aou60H1lrLfRivYRivYRku3oV68 JnqW3rf1aozluBqkkY432aD/ztRH23NbyI/VBfP8+81mZGVW47KtSGqNHTxfaPXKzngOl3OQ yHcjothuEgxTODcEyK65dYYxZsixR5EedYeFu5F/fn0wx5moHxHUrkhrKxCWmVKNsFVhvRmr QHLenG14CG2xo+eyo7EQaApj0DVrIX2JkJBcj13pzSySkBfUlnjAhb/7xoqulm8DitudqXKK qqba/7wLkzSswSuKNgbkP35fpO65MP6e0rfd17UBA1YdgSJcg/YskKF9gahcdACxKWfanYzG 46QLbjl88udbb0JeTKIHp352xex6vMs0TLc/RYOXs5sKGIGga7mBJDC6nxCRhZKWLw9NlrDm JmavadqhrLFLh7TgUv+rizHKJrv/mbvX2qJTiBmP5xJjRVxZWQLQCIs28zAOInAVbfYGvH20 JbHRnlDsH24DAxRMO+0PyfASekClA/ERPBglmzqaIxvMg2aray9fSt8eVsimevNhVs2VBRpQ jBeBD0UXLfouVJzvG4vtSyg3JHK7P+lcBkSrNsjhgvBukDeFpzXPDUJgb8gHMTxS8D7JNyuN O/0Du1avOWDA9ISXm03UggmgMlTDKPtltlngvdTPZdmnw+DdO/sbRMM0Pi/wxXMVwbABhU3w Y44JYr+ZcnChQqzoRVSFQxiPVlg8mkzkY1Ctghb0uN15nxClHK1KUvRAQDQz+W0DaUHnPVaN u6497O798WmMCCZCZ0I+I5F1DCQS6JgTZe5kJiaIIXzlvxi1FxBCHk4W1rd8D4Rr5ndlA9Wz m9ejwUC5NABqGWjusUwDaCarQ2nyaAQROLX3VI7i0DDnVL+NpF29AeKbSB+KA/QP898vjl6B ZY9O3jPJ5kTTNcS31ZBxllfv7JWxA6/QRVrJB6TsOdIBAVUbBCCjzCOM8Cwo8nM0dsGsHXsA GqdyWARLS8yBitKJyoLW2k/e92LTZD1WVsjJrJCCi2B1xQlRhKA9HHW3AmFWB0lvhvh6UZCN vrsoRitYGRr/68uaOWU7RAPdR0Mlu6dD1uNR++OsWuGEV0qsoRipwgfAjgXv9Naw9yWaYi33 +cfR5L3yp3H/RwZZv/jM5LnB8r3By6FHll95FEb6D5VeGGdb3qn3YjkvWh4Kj2YGRXvMQO2z Smfj+/T8TAnf1xvPP3n7WD8Vl1wTBiVrKwmiMcDx4Mmjpj4Z2irDZcRYhysHqCyEKYZS+aYg ZPIlQAhHaoag4/TDQmIwpglFaYYo4FZIBjaTa6ykOBjDc9tCJJUNXREq5udMbpwMHUKb+n5g MKRZejaHDzmz2JvMWEuzQqjUOw2F4AV0YAlVpivg4acKSlkrmQmlVkoAi01JdGSJaQC9FnfY umkdvVno7KZ1I45ardPWo0ePQkYr9iWWW5IAPqnuMD76i/uP5AD+enYr/759dVamSDx+mxRw eOmmWzfPW8+DDXYmHbs1WKk7+sfgh3yqmxTNbnFPRMbGx8fH5eqOYb3pm3GQdspnWHFpVLy1 HCquuvFR8ZJ1M/3+mUvmqWbgdueTJSqfZdm/3tcUCAdJ1zjAxNS3B0opKLGUZRhuAtX0jcNc 6zAsU9g+jBqAQFXyiUWbLpoDpUOfPCeP7armig7ftKdiPZox8JO4qllj5T7CVB5PRrNRZwTM zkTeCvDCd450g1W7q8NQldBmz1o5FQkWQMs5RX+FaEz4wfMzACepCOs0/UG53iXSJIgaakY5 61kvgAilcaHJTSRSyJA5gcsiOiVF74Q2iktkHEW5JMNzZQSYdjziXSRt4UknkEwBEYTatwms yPI61S8d3dkVPn5vKXyX3CqAR2SAq4+9erCYwm75FHaIdc89KkLv4eQtYS8tS/W+rOzFrBRj EHkQRi1a6OIqiF9ERsJteHKSvMOCQhA90sIiEILgnynpYFzB8ziTu0Ead+D6GkWK+NuGPGyr ttCxYSMquSiTNR6NPRUYlMOckFiUskSyEKmDZgCTSjmRRB7daCSu550rgSXaqOKiqwVseO9W 0kJghSsa3a2vF21rXZw53Hi2ZBXdEdrmD2BxMVDwjfwHJAg8UbnswCmXbwrEB+pBIBUodqaK Idd9SUciYUm8Jk9QXgVG7URxAD3aH8o6Q4iTo1y5YMSYqcT95d8yOyNR3O/JL8TCOZ89WPPo 0uTXZSPuCbvxxtKKBBejy/mUKKf0KS3KczcOidiAFA63TlTKISCIeWOcEyFSbULWUcRmRKBZ fU1zNUERyVSuqO6IVmJen76RKbUSoVgjXtPkTkJPGNESa0hILJz+Sb4BrRuJKwt5um/R19Hz q0tMPP2QTHqD0Uf8cXxyfAoJ61vMAQxTxUgCE6mrffpDv3c8oLPFAzqjAZ3BgDgSlBFbpARR pVKYuxcahGqImKp+U3qI6rQgY+ROQUp9hoDbpdivOnG/qaIV5IE7PcYQ6Rc8CWTgTIj0cxS2 AZgxc6XIV1MElcsGQ2MW7Unrz+eto7O/HL6IahoB/D7Ebhie4KtaDvcbS/piMCJNN+y1RrEt 3wh8obNY8LkSOiXTVZq2v53CfYLXBUhccjyXTLNUd1mT7svKnN9aMXCR/u6M5sMZj8mjZK5R KY85B0D5KBVWpa9nqQc6SnxmrRaJSKafhp2ryWgo6RoqAM0pry8i5fZlkVx7keOXRf5d0jUM Zy5dw89zfRRlVbO8wTycbpQ623n+ZWzMNlufRavnH7eOjojLIIL1ykbbaOUBFY54Nl/Jn8g3 g5wmlBiGIVKBNc/Ho8Gn4ei6j9Y/YGvSiePuxbO3DQNyB+BCHGwCsBIw9AjFI1ZhRbixy9ZR CK+51xR1L7b4stUqVUSfFXQI3BYgCEUynJ2POjPkpmCLxIpEnA1j25BeFZCpGHoHvuyLXfyy sVHx2jiAqOeIAdF4Ivhnfx98ef5TRPQLxvJPpKesimtQ5HfB1doT2qCAt7fjBKX6tuIIR3n5 aylOOQJPjODZIGOS6855rz+QT8Y/6u8a8BK8VBGCwB7kSlAmPgP4zlaEiRIE9WfXYxSXMnKF o9IRQo+P5bU9fXkCcm04TPDQDOUp7/bBS6e8j5/kgC5h9mLWHvNr4wbEeHV6dvL8iFjwrydy f6ed+Uginbh8SZbvaWQTYpGmOOx0kvHs9xO5OjitW04xE9Upn15fSXCufh4OBvAbWjOrFAMn yvysvcO72eMPIp9sDyhPLzGiJbUNjykwr3X0Jap+PuhfIwfpNrByhy9evHz74uykrNcO8dL2 EIPW876MJaqfdGZyIatV0cZhI6ape1KLev/1uN/8idDCEwx0oKyBAafWrzvw7+ftUIERNZb2 72mFC6sIGqW6ZTz4hkpeW0NlUWd3UVvUqkhf5IFMbmbQOpFE8poDOIwscA1KKYcvjl5VdJXu dZ9cmIJjv/rTipkcKWrIhpQD0q8xaAbs58MJsdpp4PnjRpxAfI0PdGQOAI9VjuHJOzCDjeE5 iTh1TWzHTILy8btt+qeNxOlET8mlxnfEwfCn4LPexlsrBFIRoZAAMcPWS/doQrYqe61lTb7C Nl+ya9cy5+VhC+LX1SrO/QiW2bHLxO9CqDr4kB9NMmeeNoMp9NJ9sSd5JdUjB9tbT8XZyx7c Uu8w6gIxxrFmEU1fFvVQSIbt53mCbhf1kE1SEwAzPJJ7pRIFZufQT/3u+Qwe072SXWt2MagA 7TK6gAp+OM0K4FfgaNrKM56nZe50Ph3LM7FXwsj1UBoirsrS9Puu8e1YFefn6Qih8qDOAQ0G dApRMN5LWAnKU4HI0itLrB7yOM2uqnnJo+5EnqRv6Nft/NzxDY4c7fk4PVsYvOVpWw0/OFmc T4HoeSHmkI7ZmKmLA8WHyUco89CoMElBuHFwxnb4N2fgL8/epp1Pa5UErse6CIG6kONHUlC1 KqEKhKyyO9m4YYUZpciBXNexYHGiBOoCofiKap4FwisuLlosuuISBtz3NLLOsScte+4Ds7kK 30G8xvtHXbxPpEfNprYWXVYtP1y4Ro/76/nOJd+smmdnsV2Wjsj5DZw/WOA/CrwZck5cAkBt FAa1stB//fj8+Pz4/Pj8+Pz4/Pj8+Pz4qM//AT8eJg4A8AAA --------------000905000008070802080408-- From daniel.ritz@gmx.ch Sun Apr 10 11:29:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 11:29:32 -0700 (PDT) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AITPnx003499 for ; Sun, 10 Apr 2005 11:29:26 -0700 Received: from toshba.local (84-72-221-60.dclient.hispeed.ch [84.72.221.60]) (authenticated bits=0) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j3AITNWM014062; Sun, 10 Apr 2005 20:29:23 +0200 From: Daniel Ritz Reply-To: daniel.ritz@gmx.ch To: Jeff Garzik Subject: [PATCH] 3c574_cs: disable interrupts in el3_close Date: Sun, 10 Apr 2005 20:27:45 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504102027.45729.daniel.ritz@gmx.ch> X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on smtp-07.tornado.cablecom.ch X-Virus-Status: Clean X-archive-position: 1645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.ritz@gmx.ch Precedence: bulk X-list: netdev Content-Length: 522 Lines: 18 3c574_cs forgets to disable interrupts during el3_close(). fix it by doing what 3c59x does. Signed-off-by: Daniel Ritz --- 1.40/drivers/net/pcmcia/3c574_cs.c 2005-01-25 22:50:25 +01:00 +++ edited/drivers/net/pcmcia/3c574_cs.c 2005-04-09 21:49:02 +02:00 @@ -1274,6 +1274,9 @@ spin_lock_irqsave(&lp->window_lock, flags); update_stats(dev); spin_unlock_irqrestore(&lp->window_lock, flags); + + /* force interrupts off */ + outw(SetIntrEnb | 0x0000, ioaddr + EL3_CMD); } link->open--; From tgraf@suug.ch Sun Apr 10 12:27:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 12:27:21 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AJRCdY008384 for ; Sun, 10 Apr 2005 12:27:13 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id AC8421C0EB; Sun, 10 Apr 2005 21:27:27 +0200 (CEST) Date: Sun, 10 Apr 2005 21:27:27 +0200 From: Thomas Graf To: jamal Cc: johnpol@2ka.mipt.ru, Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050410192727.GI26731@postel.suug.ch> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> <1113143959.1089.316.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113143959.1089.316.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3612 Lines: 99 * jamal <1113143959.1089.316.camel@jzny.localdomain> 2005-04-10 10:39 > Please crosspost on netdev - you should know that by now;-> > > I actually disagreee with Herbert on this. Theres definetely good > need to have a more usable messaging system that rides on top of > netlink. It is not that netlink cant be extended (I actually think thats > a separate topic) I find it quite easy already but I guess a few macros would improve it even more. The routing attribute macros could be made generic to so can benefit from the advanages of TLVs. Evgeniy, Sorry for not having time earlier to give your patch a review. I'm not yet through completely and won't comment on the overall architecture until I have understood it all. diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.000000000 +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb) +{ + struct cn_callback_entry *cbq, *n, *__cbq; + int found = 0; + + cbq = cn_queue_alloc_callback_entry(cb); + if (!cbq) + return -ENOMEM; + + atomic_inc(&dev->refcnt); + cbq->pdev = dev; + + spin_lock(&dev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->queue_list, callback_entry) { Why _safe? There is no way a entry can be removed here. + if (cn_cb_equal(&__cbq->cb->id, &cb->id)) { + found = 1; + break; + } + } diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c --- /tmp/empty/connector.c 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.000000000 +void cn_netlink_send(struct cn_msg *msg, u32 __groups) +{ + struct cn_callback_entry *n, *__cbq; + unsigned int size; + struct sk_buff *skb; + struct nlmsghdr *nlh; + struct cn_msg *data; + struct cn_dev *dev = &cdev; + u32 groups = 0; + int found = 0; + + if (!__groups) + { + spin_lock(&dev->cbdev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { Same here + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + found = 1; + groups = __cbq->group; + } + } + spin_unlock(&dev->cbdev->queue_lock); + + if (!found) { + printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", + msg->id.idx, msg->id.val, msg->seq); + return; + } + } + else + groups = __groups; + + size = NLMSG_SPACE(sizeof(*msg) + msg->len); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + return; + } + + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); This is not correct, what happens is: size = NLMSG_SPACE(sizeof(*msg) + msg->len); --> align(hdr)+align(data) size - sizeof(*nlh) --> (align(hdr)-hdr)+align(data) NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH) --> align(hdr)+(align(hdr)-hdr)+align(data) At the moment align(hdr) == hdr since nlmsghdr is already aligned but this might change and your code will break. From akpm@osdl.org Sun Apr 10 13:50:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 13:50:13 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AKo4fq010298 for ; Sun, 10 Apr 2005 13:50:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3AKnes4008043 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 10 Apr 2005 13:49:41 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j3AKndC1000681; Sun, 10 Apr 2005 13:49:39 -0700 Date: Sun, 10 Apr 2005 13:49:34 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: avvisi@spalletti.it Subject: Fw: [Bug 4467] New: Debug: sleeping function called from invalid context at mm/slab.c:2090 Message-Id: <20050410134934.0bf9d6b8.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1647 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: 1356 Lines: 43 proto_register() is doing kmem_cache_create() inside write_lock(). Begin forwarded message: Date: Sun, 10 Apr 2005 05:09:39 -0700 From: bugme-daemon@osdl.org To: akpm@digeo.com Subject: [Bug 4467] New: Debug: sleeping function called from invalid context at mm/slab.c:2090 http://bugme.osdl.org/show_bug.cgi?id=4467 Summary: Debug: sleeping function called from invalid context at mm/slab.c:2090 Kernel Version: 2.6.12.rc2 Status: NEW Severity: normal Owner: akpm@digeo.com Submitter: avvisi@spalletti.it Distribution: Ubuntu 5.04 Hardware Environment: Asus M6Ne Laptop Software Environment: gcc 3.3.5, libc6 2.3.2 Problem Description: On startup, at ipv6 module loading dmesg prints this error: Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [] __might_sleep+0xa6/0xb0 [] load_module+0x8cd/0xb70 [] kmem_cache_alloc+0x6d/0x70 [] kmem_cache_create+0x100/0x5b0 [] proto_register+0xa4/0xd0 [] inet6_init+0x19/0x200 [ipv6] [] sys_init_module+0x182/0x240 [] sysenter_past_esp+0x54/0x75 I'll attach my config ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fmp@palmen.homeip.net Sun Apr 10 14:27:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 14:27:38 -0700 (PDT) Received: from postman.arcor.de (postman1.arcor-online.net [151.189.20.156]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ALRVk0011493 for ; Sun, 10 Apr 2005 14:27:32 -0700 Received: from router.palmen.homeip.net (pD95E380C.dip.t-dialin.net [217.94.56.12]) (authenticated bits=0) by postman.arcor.de (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j3ALRS7g026130 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 10 Apr 2005 23:27:29 +0200 (MEST) Received: from fmp by router.palmen.homeip.net with local (Exim 4.44 #1 (Debian)) id 1DKjxn-0003nx-Mi for ; Sun, 10 Apr 2005 23:27:27 +0200 Date: Sun, 10 Apr 2005 23:27:27 +0200 To: netdev@oss.sgi.com Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050410212727.GA13829@palmen.homeip.net> Mail-Followup-To: fmp, netdev@oss.sgi.com References: <20050410034446.39e3025e.akpm@osdl.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20050410034446.39e3025e.akpm@osdl.org> Organization: University of Karlsruhe, Germany X-Face: K~w3A&?OT;vit*S.e$nb*yhXg?1~W$[{'\ac!fDp)'/c2g@rs-=Rm|%qi`!)J4QmlC2$x-' ^gR/WY=6e$E#PY'(~.5%U"h[yh.C^AK^8%t=tuq`8s`'+a]15|Bo&Uk>PD~Cu:_cJ5B!oVU0*3A!hH dUPeD{&b5hpczhAh&O0oeH.U@[|inep"(ye[R^7_I?8of&8eF\hIAZbRV3(D>n)1\^yjoy}\ User-Agent: Mutt/1.5.6+20040907i From: Felix Palmen X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fmp@palmen.homeip.net Precedence: bulk X-list: netdev Content-Length: 1864 Lines: 58 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Felix M. Palmen [20050410 11:16]: > So I assume there is a problem in the appletalk code, but I didn't try > reproducing that on other systems so far. I've now tested this issue on a vanilla 2.6.11.7 kernel. I only applied my own patch from the previous post so that I am able to shut down the computer cleanly. So I did the following: - boot 2.6.11.7 - create a tap device with 'openvpn --mktun --dev tap0' - create /etc/netatalk/atalkd.conf with a single line 'tap0' - launch atalkd, wait. - stop atalkd. - destroy tap device with 'openvpn --rmtun --dev tap0' refcnt was -256, very strange. Would you consider my patch harmful? I intend using it for now, because otherwise, my system won't shut down cleanly any more... Greets, Felix PS: Please CC replies to me. PPS: I'm sorry for the multipost (lkml and here), at first I didn't realize Andrew was directing this thread to linux-netdev --=20 | /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/= | | \ / Campaign Against | fmp@palmen.homeip.net encrypted mail welcome= | | X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt = | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683= | --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUBQlmaPwSq+3gxG9cNAQIjhAQAkmq9/KH9O76j5nQef9FDnXLdF6bTr7sI lMDBqTe6VVC6bUpFzbXbWUz8AHUkcQRxD5UIccUAnRb6eS99ME/VIQ2tyifMxowj 5ePIY5EAPpYukkk9tX0TxUcFHLs+3ks0OqgXFJaZktpJrrchusMvim9daEWdhglq H5mhWeRZRmY= =WPAX -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From herbert@gondor.apana.org.au Sun Apr 10 14:29:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 14:29:26 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ALTG7R011853 for ; Sun, 10 Apr 2005 14:29:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKjzG-0006Rl-00; Mon, 11 Apr 2005 07:28:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKjz6-0007tz-00; Mon, 11 Apr 2005 07:28:48 +1000 Date: Mon, 11 Apr 2005 07:28:48 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* Message-ID: <20050410212848.GB30337@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113142510.1091.294.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 840 Lines: 22 On Sun, Apr 10, 2005 at 10:15:11AM -0400, jamal wrote: > > The main reason i did the XFRM_SAP_* is to be able to cover a case where > a message was relevant to one KM but not the other. That may not > exist now (actually it does with policy expiration that pfkey cant > handle - but thats easy to take care of). > Hopefully XFRM_MSG_xxx is the superset and will be sufficient. Since xfrm_user is meant to be the native interface, this should never happen. > Do you have anymore patches? If not i can give these a quick test; > Masahide has a better test setup and if he has time he should as well. That's it for now. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Apr 10 14:29:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 14:29:27 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ALTGHV011848 for ; Sun, 10 Apr 2005 14:29:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKjys-0006Rf-00; Mon, 11 Apr 2005 07:28:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKjxU-0007tX-00; Mon, 11 Apr 2005 07:27:08 +1000 Date: Mon, 11 Apr 2005 07:27:07 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050410212707.GA30337@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> <1113142244.1088.287.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113142244.1088.287.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 817 Lines: 22 On Sun, Apr 10, 2005 at 10:10:44AM -0400, jamal wrote: > On Sat, 2005-04-09 at 16:03, Herbert Xu wrote: > > > xfrm_policy_kill can only be called by the one who removed the > > policy from the linked list. Therefore it can never fail. > > > > If this logic is wrong we will be getting fat warnings from > > xfrm_policy_kill. > > The warning will kick in but it may be as rare as the issue of a delete > and expire happening on the same policy that your patch was supposed to > stop ;-> What I am saying is that this is impossible. If it really bothers you we can turn the WARN_ON into a BUG. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sun Apr 10 14:50:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 14:50:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ALoBnw013786 for ; Sun, 10 Apr 2005 14:50:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DKkGn-0004ut-00; Sun, 10 Apr 2005 14:47:05 -0700 Date: Sun, 10 Apr 2005 14:47:05 -0700 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com, avvisi@spalletti.it Subject: Re: Fw: [Bug 4467] New: Debug: sleeping function called from invalid context at mm/slab.c:2090 Message-Id: <20050410144705.3b8ace07.davem@davemloft.net> In-Reply-To: <20050410134934.0bf9d6b8.akpm@osdl.org> References: <20050410134934.0bf9d6b8.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 275 Lines: 9 On Sun, 10 Apr 2005 13:49:34 -0700 Andrew Morton wrote: > > proto_register() is doing kmem_cache_create() inside write_lock(). Didn't you integrate Arnaldo's patch to fix this into -mm? I was certain I got an ACK email back from your -mm automatic thingy. From tgraf@suug.ch Sun Apr 10 14:50:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 14:50:40 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ALoYx8013800 for ; Sun, 10 Apr 2005 14:50:34 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id BA6F71C0EB; Sun, 10 Apr 2005 23:50:50 +0200 (CEST) Date: Sun, 10 Apr 2005 23:50:50 +0200 From: Thomas Graf To: Felix Palmen Cc: netdev@oss.sgi.com Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050410215050.GJ26731@postel.suug.ch> References: <20050410034446.39e3025e.akpm@osdl.org> <20050410212727.GA13829@palmen.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050410212727.GA13829@palmen.homeip.net> X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3ALoYx8013800 X-archive-position: 1652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1092 Lines: 29 * Felix Palmen <20050410212727.GA13829@palmen.homeip.net> 2005-04-10 23:27 > I've now tested this issue on a vanilla 2.6.11.7 kernel. I only applied > my own patch from the previous post so that I am able to shut down the > computer cleanly. So I did the following: > > - boot 2.6.11.7 > - create a tap device with 'openvpn --mktun --dev tap0' > - create /etc/netatalk/atalkd.conf with a single line 'tap0' > - launch atalkd, wait. > - stop atalkd. > - destroy tap device with 'openvpn --rmtun --dev tap0' > > refcnt was -256, very strange. Is it always 256? Do you have any appletalk routes configured? If so, is the 256 dependand on the number of routes? I'm asking because: ddp.c: for (nodect = 0; nodect < 256; nodect++) { ddp.c: for (nodect = 0; nodect < 256; nodect++) { However, I have not checked if this could be invovled at all. > Would you consider my patch harmful? I intend using it for now, because > otherwise, my system won't shut down cleanly any more... Your system is not fully reliable with and without the patch so it doesn't matter at all. ;-> From akpm@osdl.org Sun Apr 10 15:06:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 15:06:09 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3AM63nf015151 for ; Sun, 10 Apr 2005 15:06:04 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3AM5vs4013349 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 10 Apr 2005 15:05:57 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j3AM5uwI003603; Sun, 10 Apr 2005 15:05:57 -0700 Date: Sun, 10 Apr 2005 15:05:51 -0700 From: Andrew Morton To: "David S. Miller" Cc: netdev@oss.sgi.com, avvisi@spalletti.it Subject: Re: Fw: [Bug 4467] New: Debug: sleeping function called from invalid context at mm/slab.c:2090 Message-Id: <20050410150551.3fa38390.akpm@osdl.org> In-Reply-To: <20050410144705.3b8ace07.davem@davemloft.net> References: <20050410134934.0bf9d6b8.akpm@osdl.org> <20050410144705.3b8ace07.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1653 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: 393 Lines: 16 "David S. Miller" wrote: > > On Sun, 10 Apr 2005 13:49:34 -0700 > Andrew Morton wrote: > > > > > proto_register() is doing kmem_cache_create() inside write_lock(). > > Didn't you integrate Arnaldo's patch to fix this into -mm? Seems I did. > I was certain I got an ACK email back from your -mm automatic > thingy. This report is against 2.6.12-rc2. From mycooc@yahoo.it Sun Apr 10 17:18:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 17:18:52 -0700 (PDT) Received: from smtp108.mail.sc5.yahoo.com (smtp108.mail.sc5.yahoo.com [66.163.170.6]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3B0IfRu022680 for ; Sun, 10 Apr 2005 17:18:41 -0700 Received: from unknown (HELO ?192.168.1.2?) (mycooc@82.56.115.121 with plain) by smtp108.mail.sc5.yahoo.com with SMTP; 11 Apr 2005 00:18:39 -0000 Message-ID: <4259C449.7000306@yahoo.it> Date: Mon, 11 Apr 2005 02:26:49 +0200 From: TommyDrum User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: el, en-us, en MIME-Version: 1.0 To: Francois Romieu Subject: Re: r8169 native module problems on 2.6.11 [SOLVED] References: <42591914.2000800@yahoo.it> <20050410132601.GA9027@electric-eye.fr.zoreil.com> <425951F6.301@yahoo.it> <20050410170251.GA9537@electric-eye.fr.zoreil.com> In-Reply-To: <20050410170251.GA9537@electric-eye.fr.zoreil.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mycooc@yahoo.it Precedence: bulk X-list: netdev Content-Length: 1517 Lines: 48 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 O/H Francois Romieu έγÏαψε: | Ok, new pci id, no wonder it does not work. Can you give the attached patch | a quick but carefull test on your vanilla kernel ? Wasn't too quick, sorry, had to supper (very long, I admit it!). It's modprobed very quick (much faster than the USR provided module) and works pretty good up 'til now; dmesg is clean, lspci also, and cat /proc/interrupts doesn't show any conflicts. ifconfig also seems to be in line, and the interface is up and running smoothly. IMO all is quiet on this front ;) I forwarded last message to netdev, also do it with this one. Keep up the good work Francois, and thanks really a lot! A presto! Tommy P.S. Any other info needed, I'll be glad to provide. | ------------------------------------------------------------------------ | | --- a/drivers/net/r8169.c 2005-04-10 18:45:05.200274476 +0200 | +++ b/drivers/net/r8169.c 2005-04-10 18:52:41.197933777 +0200 | @@ -176,6 +176,7 @@ const static struct { | static struct pci_device_id rtl8169_pci_tbl[] = { | {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, | {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, | + {0x16ec, 0x0116, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, | {0,}, | }; | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWcRCgpUvhTIUBAERArnEAJ9A8/LbF2Mra0pVJS9Lcp+hg0pZ4wCeKAsu N4L1zAsNmRg15EQOuqcPmEE= =S2E/ -----END PGP SIGNATURE----- From fmp@palmen.homeip.net Sun Apr 10 19:31:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 19:31:30 -0700 (PDT) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.20.158]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B2VLir026649 for ; Sun, 10 Apr 2005 19:31:22 -0700 Received: from router.palmen.homeip.net (pD95E380C.dip.t-dialin.net [217.94.56.12]) (authenticated bits=0) by postman.arcor.de (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j3B2UuCk004746 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 11 Apr 2005 04:31:16 +0200 (MEST) Received: from fmp by router.palmen.homeip.net with local (Exim 4.44 #1 (Debian)) id 1DKohC-0005DF-SQ for ; Mon, 11 Apr 2005 04:30:38 +0200 Date: Mon, 11 Apr 2005 04:30:38 +0200 To: netdev@oss.sgi.com Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050411023038.GB13829@palmen.homeip.net> Mail-Followup-To: fmp, netdev@oss.sgi.com References: <20050410034446.39e3025e.akpm@osdl.org> <20050410212727.GA13829@palmen.homeip.net> <20050410215050.GJ26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <20050410215050.GJ26731@postel.suug.ch> Organization: University of Karlsruhe, Germany X-Face: K~w3A&?OT;vit*S.e$nb*yhXg?1~W$[{'\ac!fDp)'/c2g@rs-=Rm|%qi`!)J4QmlC2$x-' ^gR/WY=6e$E#PY'(~.5%U"h[yh.C^AK^8%t=tuq`8s`'+a]15|Bo&Uk>PD~Cu:_cJ5B!oVU0*3A!hH dUPeD{&b5hpczhAh&O0oeH.U@[|inep"(ye[R^7_I?8of&8eF\hIAZbRV3(D>n)1\^yjoy}\ User-Agent: Mutt/1.5.6+20040907i From: Felix Palmen X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fmp@palmen.homeip.net Precedence: bulk X-list: netdev Content-Length: 1535 Lines: 51 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hallo Thomas, * Thomas Graf [20050410 23:50]: > Is it always 256? Do you have any appletalk routes configured? > If so, is the 256 dependand on the number of routes? That could really be the case: - In my test with vanilla 2.6.11.7, there was no other appletalk station on the net -> refcnt was -256 - On my working system, I use a single route and get refcnt =3D -1 - When I first tried appletalk without configuring anything but the interface and PearPC with Mac OS X runnning on the other side, refcnt was -2 I'll try to double-check that tomorrow. Greets, Felix --=20 | /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/= | | \ / Campaign Against | fmp@palmen.homeip.net encrypted mail welcome= | | X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt = | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683= | --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUBQlnhTgSq+3gxG9cNAQKVyQP9FSOgwHSky9rGx8WLFbya25ZBHqJZMQ4H whyBqfhCOkA1YG3CvHcDqzqcQMz0zHa7PaZWe8GqiXD4ONIqLzQlvDWMfwuAnuV+ pX/LwVdYjIUf3BQWX6/JUFUROpmBTQkeUW9f2Hline8tZbx8G4OjkYf2DCwHlel9 KvGFLNyF3Kk= =Oz45 -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From johnpol@2ka.mipt.ru Sun Apr 10 22:23:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 22:23:27 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B5NJVR002824 for ; Sun, 10 Apr 2005 22:23:20 -0700 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j3B5MVZc002194; Mon, 11 Apr 2005 09:22:31 +0400 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.12.11/8.12.1/Submit) id j3B5MSB6002163; Mon, 11 Apr 2005 09:22:28 +0400 Date: Mon, 11 Apr 2005 09:22:28 +0400 From: Evgeniy Polyakov To: Thomas Graf Cc: jamal , Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050411092228.A32699@2ka.mipt.ru> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> <1113143959.1089.316.camel@jzny.localdomain> <20050410192727.GI26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050410192727.GI26731@postel.suug.ch>; from tgraf@suug.ch on Sun, Apr 10, 2005 at 09:27:27PM +0200 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [0.0.0.0]); Mon, 11 Apr 2005 09:22:31 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 4108 Lines: 107 On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf (tgraf@suug.ch) wrote: > * jamal <1113143959.1089.316.camel@jzny.localdomain> 2005-04-10 10:39 > > Please crosspost on netdev - you should know that by now;-> > > > > I actually disagreee with Herbert on this. Theres definetely good > > need to have a more usable messaging system that rides on top of > > netlink. It is not that netlink cant be extended (I actually think thats > > a separate topic) > > I find it quite easy already but I guess a few macros would improve > it even more. The routing attribute macros could be made generic to > so can benefit from the advanages of TLVs. > > Evgeniy, Sorry for not having time earlier to give your patch a > review. I'm not yet through completely and won't comment on the > overall architecture until I have understood it all. > > diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c > --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.000000000 +0300 > +++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.000000000 > +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb) > +{ > + struct cn_callback_entry *cbq, *n, *__cbq; > + int found = 0; > + > + cbq = cn_queue_alloc_callback_entry(cb); > + if (!cbq) > + return -ENOMEM; > + > + atomic_inc(&dev->refcnt); > + cbq->pdev = dev; > + > + spin_lock(&dev->queue_lock); > + list_for_each_entry_safe(__cbq, n, &dev->queue_list, callback_entry) { > > Why _safe? There is no way a entry can be removed here. No particular reason - it easier to copy-paste it from other line :) > + if (cn_cb_equal(&__cbq->cb->id, &cb->id)) { > + found = 1; > + break; > + } > + } > diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c > --- /tmp/empty/connector.c 1970-01-01 03:00:00.000000000 +0300 > +++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.000000000 > +void cn_netlink_send(struct cn_msg *msg, u32 __groups) > +{ > + struct cn_callback_entry *n, *__cbq; > + unsigned int size; > + struct sk_buff *skb; > + struct nlmsghdr *nlh; > + struct cn_msg *data; > + struct cn_dev *dev = &cdev; > + u32 groups = 0; > + int found = 0; > + > + if (!__groups) > + { > + spin_lock(&dev->cbdev->queue_lock); > + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { > > Same here > > + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > + found = 1; > + groups = __cbq->group; > + } > + } > + spin_unlock(&dev->cbdev->queue_lock); > + > + if (!found) { > + printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", > + msg->id.idx, msg->id.val, msg->seq); > + return; > + } > + } > + else > + groups = __groups; > + > + size = NLMSG_SPACE(sizeof(*msg) + msg->len); > + > + skb = alloc_skb(size, GFP_ATOMIC); > + if (!skb) { > + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); > + return; > + } > + > + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); > > This is not correct, what happens is: > size = NLMSG_SPACE(sizeof(*msg) + msg->len); > --> align(hdr)+align(data) > size - sizeof(*nlh) > --> (align(hdr)-hdr)+align(data) > NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH) > --> align(hdr)+(align(hdr)-hdr)+align(data) > > At the moment align(hdr) == hdr since nlmsghdr is already aligned > but this might change and your code will break. As far as I remember, header is always supposed to be aligned properly "by design", so it even could be nonaligned here. -- Evgeniy Polyakov ( s0mbre ) From nakam@linux-ipv6.org Sun Apr 10 22:46:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 22:46:12 -0700 (PDT) Received: from mail206.noc.n-bone.net (mail2.noc.n-bone.net [138.243.50.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B5k7Mo003977 for ; Sun, 10 Apr 2005 22:46:08 -0700 Received: from [222.13.22.57] (P222013022057.ppp.prin.ne.jp [222.13.22.57]) by mail206.noc.n-bone.net (NBONE-MTA) with ESMTP id 65D09F92; Mon, 11 Apr 2005 14:45:48 +0900 (JST) Message-ID: <425A0F00.8070509@linux-ipv6.org> Date: Mon, 11 Apr 2005 14:45:36 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca, Herbert Xu Cc: "David S. Miller" , Patrick McHardy , netdev Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> In-Reply-To: <1113142510.1091.294.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 43 > Do you have anymore patches? If not i can give these a quick test; > Masahide has a better test setup and if he has time he should as well. I can, but about 24 hours later. I'll test it there is no update and if it isn't too late then. Thanks, -- Masahide NAKAMURA jamal wrote: > On Sun, 2005-04-10 at 05:02, Herbert Xu wrote: > >>Hi: >> >>I spotted some more issues while preparing the last patch of the >>series. So I'll extend it a little further. >> >>This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*. >>The netlink interface is meant to map directly onto the underlying >>xfrm subsystem. Therefore rather than using a new independent >>representation for the events we can simply use the existing ones >>from xfrm_user. >> > > > The main reason i did the XFRM_SAP_* is to be able to cover a case where > a message was relevant to one KM but not the other. That may not > exist now (actually it does with policy expiration that pfkey cant > handle - but thats easy to take care of). > Hopefully XFRM_MSG_xxx is the superset and will be sufficient. > > Do you have anymore patches? If not i can give these a quick test; > Masahide has a better test setup and if he has time he should as well. > > cheers, > jamal > > From linux_lover2004@yahoo.com Sun Apr 10 23:05:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Apr 2005 23:05:21 -0700 (PDT) Received: from web52201.mail.yahoo.com (web52201.mail.yahoo.com [206.190.39.83]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3B65GXQ005100 for ; Sun, 10 Apr 2005 23:05:16 -0700 Received: (qmail 12210 invoked by uid 60001); 11 Apr 2005 06:05:10 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=tj/lYJeTw187+EL+qIuhZC9JD+QSWqYPVubCgY7yEYpc8Ql4KEDcZk6rj7G2Jt2r0ir0jI2YuuYb4x8vJ2MRyOXUiSlSl3Qv3aJoPblaMjjWq1iVfLY7q8uO1A6l6Aisbi/w/XysxIOMnrilZQIuD6JGEaSjn42sSwvG/oSuW7Q= ; Message-ID: <20050411060510.12208.qmail@web52201.mail.yahoo.com> Received: from [203.199.141.99] by web52201.mail.yahoo.com via HTTP; Sun, 10 Apr 2005 23:05:10 PDT Date: Sun, 10 Apr 2005 23:05:10 -0700 (PDT) From: linux lover Subject: Function to read IP address in dot format To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 668 Lines: 25 Hello, what is the function to read IP address in kernel code as human readable dot quad format? IP address are unsigned int's in ip.h file as __u32 saddr; __u32 daddr; In ip_build_xmit ip header gets IP addresses from rtable struct as iph->saddr=rt->rt_src; iph->daddr=rt->rt_dst; Now if i want to know to which ip current packet is being sent i am using printks but it prints iph->saddr in int format not in user readable format. how to do that? regards, linux_lover __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From romieu@fr.zoreil.com Mon Apr 11 00:09:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 00:09:50 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B79f5O007474 for ; Mon, 11 Apr 2005 00:09:42 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j3B796B8019921; Mon, 11 Apr 2005 09:09:06 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j3B790Dt019920; Mon, 11 Apr 2005 09:09:00 +0200 Date: Mon, 11 Apr 2005 09:09:00 +0200 From: Francois Romieu To: TommyDrum Cc: netdev@oss.sgi.com Subject: Re: [Fwd: Re: r8169 native module problems on 2.6.11] Message-ID: <20050411070900.GA19913@electric-eye.fr.zoreil.com> References: <42596C3E.5020506@yahoo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42596C3E.5020506@yahoo.it> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1659 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: 159 Lines: 9 TommyDrum : [scrontch] It was just a matter of adding a new PCI ID to the driver. I'll forward the patch to akpm/jg for 2.6.12. -- Ueimor From tgraf@suug.ch Mon Apr 11 03:45:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 03:45:48 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BAjYWY022715 for ; Mon, 11 Apr 2005 03:45:35 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 53B041C0EB; Mon, 11 Apr 2005 12:45:50 +0200 (CEST) Date: Mon, 11 Apr 2005 12:45:50 +0200 From: Thomas Graf To: Evgeniy Polyakov Cc: jamal , Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] Message-ID: <20050411104550.GK26731@postel.suug.ch> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> <1113143959.1089.316.camel@jzny.localdomain> <20050410192727.GI26731@postel.suug.ch> <20050411092228.A32699@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411092228.A32699@2ka.mipt.ru> X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1553 Lines: 38 * Evgeniy Polyakov <20050411092228.A32699@2ka.mipt.ru> 2005-04-11 09:22 > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf (tgraf@suug.ch) wrote: > > + size = NLMSG_SPACE(sizeof(*msg) + msg->len); > > + > > + skb = alloc_skb(size, GFP_ATOMIC); > > + if (!skb) { > > + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); > > + return; > > + } > > + > > + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); > > > > This is not correct, what happens is: > > size = NLMSG_SPACE(sizeof(*msg) + msg->len); > > --> align(hdr)+align(data) > > size - sizeof(*nlh) > > --> (align(hdr)-hdr)+align(data) > > NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH) > > --> align(hdr)+(align(hdr)-hdr)+align(data) > > > > At the moment align(hdr) == hdr since nlmsghdr is already aligned > > but this might change and your code will break. > > As far as I remember, header is always supposed to be aligned properly > "by design", so it even could be nonaligned here. No, have a look at the macros: #define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr))) #define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len)) NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE represents the total size aligned properly for a possible next multipart message. It is unlikely that nlmsghdr will ever be unaligned but there can be no reason to introduce code that can break with perfectly legal changes just because of that. From johnpol@2ka.mipt.ru Mon Apr 11 04:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 04:16:51 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BBGRQV024734 for ; Mon, 11 Apr 2005 04:16:33 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j3BBCsVd010766; Mon, 11 Apr 2005 15:12:55 +0400 Subject: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Thomas Graf Cc: jamal , Kay Sievers , Herbert Xu , jmorris@redhat.com, ijc@hellion.org.uk, guillaume.thouvenin@bull.net, greg@kroah.com, linux-kernel@vger.kernel.org, akpm@osdl.org, netdev In-Reply-To: <20050411104550.GK26731@postel.suug.ch> References: <1112942924.28858.234.camel@uganda> <20050410143205.18bff80d@zanzibar.2ka.mipt.ru> <1113131325.6994.66.camel@localhost.localdomain> <20050410153757.104fe611@zanzibar.2ka.mipt.ru> <20050410121005.GF26731@postel.suug.ch> <20050410161549.3abe4778@zanzibar.2ka.mipt.ru> <1113143959.1089.316.camel@jzny.localdomain> <20050410192727.GI26731@postel.suug.ch> <20050411092228.A32699@2ka.mipt.ru> <20050411104550.GK26731@postel.suug.ch> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vzWhPJXCUTTEheqMzsZW" Organization: MIPT Date: Mon, 11 Apr 2005 15:19:53 +0400 Message-Id: <1113218393.16303.13.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/762/Mon Mar 14 02:35:33 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Mon, 11 Apr 2005 15:13:05 +0400 (MSD) X-archive-position: 1661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2444 Lines: 73 --=-vzWhPJXCUTTEheqMzsZW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote: > * Evgeniy Polyakov <20050411092228.A32699@2ka.mipt.ru> 2005-04-11 09:22 > > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf (tgraf@suug.ch) w= rote: > > > + size =3D NLMSG_SPACE(sizeof(*msg) + msg->len); > > > + > > > + skb =3D alloc_skb(size, GFP_ATOMIC); > > > + if (!skb) { > > > + printk(KERN_ERR "Failed to allocate new skb with size= =3D%u.\n", size); > > > + return; > > > + } > > > + > > > + nlh =3D NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof= (*nlh)); > > >=20 > > > This is not correct, what happens is: > > > size =3D NLMSG_SPACE(sizeof(*msg) + msg->len); > > > --> align(hdr)+align(data) > > > size - sizeof(*nlh) > > > --> (align(hdr)-hdr)+align(data) > > > NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGT= H) > > > --> align(hdr)+(align(hdr)-hdr)+align(data) > > >=20 > > > At the moment align(hdr) =3D=3D hdr since nlmsghdr is already aligned > > > but this might change and your code will break. > >=20 > > As far as I remember, header is always supposed to be aligned properly > > "by design", so it even could be nonaligned here. >=20 > No, have a look at the macros: >=20 > #define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr))) > #define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len)) >=20 > NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE > represents the total size aligned properly for a possible next multipart > message. >=20 > It is unlikely that nlmsghdr will ever be unaligned but there can be no > reason to introduce code that can break with perfectly legal changes just > because of that. But NLMSG_ALIGN(sizeof(hdr)) is always equal to sizeof(hdr), that size was select not accidentally. I will change it, no problem, it is good from aesthetic point of view. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-vzWhPJXCUTTEheqMzsZW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCWl1ZIKTPhE+8wY0RAktFAJwOb5Pr2YO1WXRGX0k0MmT22wij2QCfboNE FqAh2pJaYdFCilvLbPwvVhc= =8sSt -----END PGP SIGNATURE----- --=-vzWhPJXCUTTEheqMzsZW-- From hadi@cyberus.ca Mon Apr 11 04:20:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 04:20:48 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BBKUou028809 for ; Mon, 11 Apr 2005 04:20:31 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DKwxv-0003H6-UU for netdev@oss.sgi.com; Mon, 11 Apr 2005 07:20:27 -0400 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 1DKwxs-0006L7-3h; Mon, 11 Apr 2005 07:20:24 -0400 Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050410212707.GA30337@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> <1113142244.1088.287.camel@jzny.localdomain> <20050410212707.GA30337@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113218420.1090.351.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2005 07:20:20 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1662 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: 694 Lines: 26 Herbert, On Sun, 2005-04-10 at 17:27, Herbert Xu wrote: > > What I am saying is that this is impossible. If it really bothers you > we can turn the WARN_ON into a BUG. > We started this discussion by asserting that an expire may be issued on a policy (or state) despite a delete event notification already having happened. Thats what we were/are trying to stop, no? What i am saying is you are not stopping that with this: --- if (!xfrm_policy_delete(xp, dir)) km_policy_expired(xp, dir, 1); --- xfrm_policy_delete will return 0 whether the policy is dead or not. OTOH, if it returns <0 for the case where it is dead, then an expire event will not be issued. cheers, jamal From hadi@cyberus.ca Mon Apr 11 04:26:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 04:26:58 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BBQqq0030138 for ; Mon, 11 Apr 2005 04:26:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DKx45-0001DX-Ij for netdev@oss.sgi.com; Mon, 11 Apr 2005 07:26:49 -0400 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 1DKx44-0006r9-FG; Mon, 11 Apr 2005 07:26:48 -0400 Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* From: jamal Reply-To: hadi@cyberus.ca To: Masahide NAKAMURA Cc: Herbert Xu , "David S. Miller" , Patrick McHardy , netdev In-Reply-To: <425A0F00.8070509@linux-ipv6.org> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> <425A0F00.8070509@linux-ipv6.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113218805.1089.357.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2005 07:26:46 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1663 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: 365 Lines: 13 On Mon, 2005-04-11 at 01:45, Masahide NAKAMURA wrote: > > Do you have anymore patches? If not i can give these a quick test; > > Masahide has a better test setup and if he has time he should as well. > > I can, but about 24 hours later. I'll test it there is no update and > if it isn't too late then. > I will on my part test in about 12 hours. cheers, jamal From herbert@gondor.apana.org.au Mon Apr 11 04:32:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 04:32:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BBW3TB030863 for ; Mon, 11 Apr 2005 04:32:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKx8a-0001yl-00; Mon, 11 Apr 2005 21:31:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKx7o-0006hd-00; Mon, 11 Apr 2005 21:30:40 +1000 Date: Mon, 11 Apr 2005 21:30:40 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050411113040.GA25718@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> <1113142244.1088.287.camel@jzny.localdomain> <20050410212707.GA30337@gondor.apana.org.au> <1113218420.1090.351.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113218420.1090.351.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1748 Lines: 51 Hi Jamal: On Mon, Apr 11, 2005 at 07:20:20AM -0400, jamal wrote: > > We started this discussion by asserting that an expire may be issued on > a policy (or state) despite a delete event notification already having > happened. Thats what we were/are trying to stop, no? Yes. > What i am saying is you are not stopping that with this: > --- > if (!xfrm_policy_delete(xp, dir)) > km_policy_expired(xp, dir, 1); > --- > > xfrm_policy_delete will return 0 whether the policy is dead or not. xfrm_policy_delete returns 0 if and only if the policy was removed from xfrm_policy_list. A user-initiated delete policy action can only succeed if the policy was removed from xfrm_policy_list. The locking in xfrm_policy ensures that a given policy can only be removed from the xfrm_policy_list once. Therefore knowing that xfrm_policy_delete returned 0 implies that no user-initiated delete action can succeed either before or after the expire event. Whether a policy is dead or not is equivalent to whether it's on xfrm_policy_list. That is, while it's on xfrm_policy_list it must be alive. As soon as it is removed from xfrm_policy_list it is killed by the entity that performed the removal. As a corollary, xfrm_policy_delete returns 0 if and only if the policy was on xfrm_policy_list prior to the call and was successfully removed by the call and subsequently killed. > OTOH, if it returns <0 for the case where it is dead, then an expire > event will not be issued. I'm not sure what you're trying to say here. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Apr 11 04:57:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 04:57:45 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BBvdiQ005122 for ; Mon, 11 Apr 2005 04:57:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DKxXr-0004KH-Bk for netdev@oss.sgi.com; Mon, 11 Apr 2005 07:57:35 -0400 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 1DKxXo-0001Rq-DH; Mon, 11 Apr 2005 07:57:32 -0400 Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev In-Reply-To: <20050411113040.GA25718@gondor.apana.org.au> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> <1113142244.1088.287.camel@jzny.localdomain> <20050410212707.GA30337@gondor.apana.org.au> <1113218420.1090.351.camel@jzny.localdomain> <20050411113040.GA25718@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113220648.1090.364.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2005 07:57:29 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1665 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: 418 Lines: 17 Herbert, On Mon, 2005-04-11 at 07:30, Herbert Xu wrote: > Hi Jamal: > Therefore knowing that xfrm_policy_delete returned 0 implies that > no user-initiated delete action can succeed either before or after > the expire event. > Ok, what you are saying is sensible, but: does this mean there was never an issue then there was never a possibility of delete and expire intefering with each other then? cheers, jamal From herbert@gondor.apana.org.au Mon Apr 11 05:09:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 05:09:19 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BC9Aq1006190 for ; Mon, 11 Apr 2005 05:09:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DKxiZ-0002CF-00; Mon, 11 Apr 2005 22:08:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DKxhx-0006mh-00; Mon, 11 Apr 2005 22:08:01 +1000 Date: Mon, 11 Apr 2005 22:08:01 +1000 To: jamal Cc: "David S. Miller" , Masahide NAKAMURA , Patrick McHardy , netdev Subject: Re: [2/4] [IPSEC] Kill spurious hard expire messages Message-ID: <20050411120801.GA26029@gondor.apana.org.au> References: <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <1113049844.1090.23.camel@jzny.localdomain> <20050409192926.GA9423@gondor.apana.org.au> <20050409200306.GA9660@gondor.apana.org.au> <1113142244.1088.287.camel@jzny.localdomain> <20050410212707.GA30337@gondor.apana.org.au> <1113218420.1090.351.camel@jzny.localdomain> <20050411113040.GA25718@gondor.apana.org.au> <1113220648.1090.364.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113220648.1090.364.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1165 Lines: 34 On Mon, Apr 11, 2005 at 07:57:29AM -0400, jamal wrote: > Herbert, > > Ok, what you are saying is sensible, but: does this mean there was never > an issue then there was never a possibility of delete and expire > intefering with each other then? The problem before was that the timer didn't check the return value of xfrm_policy_delete (in fact the latter didn't return anything). xfrm_policy_delete tself always checked whether it succeeded in deleting the entry from xfrm_policy_list. This is used to determine whether it should call xfrm_policy_kill. Not checking the return value in the timer allows the following situation to occur: CPU 0 CPU 1 xfrm_policy_timer goto expired xfrm_get_policy(delete == 1) xfrm_policy_byid() succeeds notification is sent xfrm_policy_delete km_policy_expired <--- BUG So as long as xfrm_policy_delete returns the correct value and it's checked by the xfrm_policy_timer then we're OK. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Mon Apr 11 05:50:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 05:51:05 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BCowws008073 for ; Mon, 11 Apr 2005 05:50:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id AACD81C0EB; Mon, 11 Apr 2005 14:51:13 +0200 (CEST) Date: Mon, 11 Apr 2005 14:51:13 +0200 From: Thomas Graf To: Felix Palmen Cc: netdev@oss.sgi.com Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050411125113.GL26731@postel.suug.ch> References: <20050410034446.39e3025e.akpm@osdl.org> <20050410212727.GA13829@palmen.homeip.net> <20050410215050.GJ26731@postel.suug.ch> <20050411023038.GB13829@palmen.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411023038.GB13829@palmen.homeip.net> X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3BCowws008073 X-archive-position: 1667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1071 Lines: 27 * Felix Palmen <20050411023038.GB13829@palmen.homeip.net> 2005-04-11 04:30 > * Thomas Graf [20050410 23:50]: > > Is it always 256? Do you have any appletalk routes configured? > > If so, is the 256 dependand on the number of routes? > > That could really be the case: > > - In my test with vanilla 2.6.11.7, there was no other appletalk > station on the net -> refcnt was -256 How long was the interface up before you removed it again? That 256 might be due to probes still floating around expiring very slowly because there is no other station around. > - On my working system, I use a single route and get refcnt = -1 This one I can explain quite easly, I did not found a dev_hold() for the dev_put() that is done upon deletion of the routes when the interface is removed. > - When I first tried appletalk without configuring anything but the > interface and PearPC with Mac OS X runnning on the other side, refcnt > was -2 OK, I think the problem is a few missing dev_hold() when the net_device handle is assigned to routes, probes, etc. From johnpol@2ka.mipt.ru Mon Apr 11 05:54:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 05:55:01 -0700 (PDT) Received: from localhost.localdomain (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BCsdqd008718 for ; Mon, 11 Apr 2005 05:54:42 -0700 Received: from localhost.localdomain (uganda [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j3BCxe0i019583; Mon, 11 Apr 2005 16:59:40 +0400 Received: (from s0mbre@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j3BCxWMp019582; Mon, 11 Apr 2005 16:59:32 +0400 X-Authentication-Warning: localhost.localdomain: s0mbre set sender to johnpol@2ka.mipt.ru using -f Date: Mon, 11 Apr 2005 16:59:32 +0400 From: Evgeniy Polyakov To: netdev@oss.sgi.com Cc: Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050411125932.GA19538@uganda.factory.vocord.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 48642 Lines: 1795 /*****************************************/ Kernel Connector. /*****************************************/ Kernel connector - new netlink based userspace <-> kernel space easy to use communication module. Connector driver adds possibility to connect various agents using netlink based network. One must register callback and identifier. When driver receives special netlink message with appropriate identifier, appropriate callback will be called. From the userspace point of view it's quite straightforward: socket(); bind(); send(); recv(); But if kernelspace want to use full power of such connections, driver writer must create special sockets, must know about struct sk_buff handling... Connector allows any kernelspace agents to use netlink based networking for inter-process communication in a significantly easier way: int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); struct cb_id { __u32 idx; __u32 val; }; idx and val are unique identifiers which must be registered in connector.h for in-kernel usage. void (*callback) (void *) - is a callback function which will be called when message with above idx.val will be received by connector core. Argument for that function must be dereferenced to struct cn_msg *. struct cn_msg { struct cb_id id; __u32 seq; __u32 ack; __u32 len; /* Length of the following data */ __u8 data[0]; }; /*****************************************/ Connector interfaces. /*****************************************/ int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); Registers new callback with connector core. struct cb_id *id - unique connector's user identifier. It must be registered in connector.h for legal in-kernel users. char *name - connector's callback symbolic name. void (*callback) (void *) - connector's callback. Argument must be dereferenced to struct cn_msg *. void cn_del_callback(struct cb_id *id); Unregisters new callback with connector core. struct cb_id *id - unique connector's user identifier. void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); Sends message to the specified groups. It can be safely called from any context, but may silently fail under strong memory pressure. struct cn_msg * - message header(with attached data). u32 __groups - destination groups. If __groups is zero, then appropriate group will be searched through all registered connector users, and message will be delivered to the group which was created for user with the same ID as in msg. If __groups is not zero, then message will be delivered to the specified group. int gfp_mask - GFP mask. Note: When registering new callback user, connector core assigns netlink group to the user which is equal to it's id.idx. /*****************************************/ Protocol description. /*****************************************/ Current offers transport layer with fixed header. Recommended protocol which uses such header is following: msg->seq and msg->ack are used to determine message genealogy. When someone sends message it puts there locally unique sequence and random acknowledge numbers. Sequence number may be copied into nlmsghdr->nlmsg_seq too. Sequence number is incremented with each message to be sent. If we expect reply to our message, then sequence number in received message MUST be the same as in original message, and acknowledge number MUST be the same + 1. If we receive message and it's sequence number is not equal to one we are expecting, then it is new message. If we receive message and it's sequence number is the same as one we are expecting, but it's acknowledge is not equal acknowledge number in original message + 1, then it is new message. Obviously, protocol header contains above id. connector allows event notification in the following form: kernel driver or userspace process can ask connector to notify it when selected id's will be turned on or off(registered or unregistered it's callback). It is done by sending special command to connector driver(it also registers itself with id={-1, -1}). As example of usage Documentation/connector now contains cn_test.c - testing module which uses connector to request notification and to send messages. /*****************************************/ CBUS. /*****************************************/ This message bus allows message passing between different agents using connector's infrastructure. It is extremely fast for insert operations so it can be used in performance critical paths in any context instead of direct connector's methods calls. CBUS uses per CPU variables and thus allows message reordering, caller must be prepared (and use CPU id in it's messages). Usage is very simple - just call cbus_insert(struct cn_msg *msg, int gfp_mask); It can fail, so caller must check return value - zero on success and negative error code otherwise. Benchmark with modified fork connector and fork bomb on 2-way system did not show any differences between vanilla 2.6.11 and CBUS. /*****************************************/ Reliability. /*****************************************/ Netlink itself is not reliable protocol, that means that messages can be lost due to memory pressure or process' receiving queue overflowed, so caller is warned must be prepared. That is why struct cn_msg [main connector's message header] contains u32 seq and u32 ack fields. P.S. As far as I can see, all previous comments are successfully resolved. Thank you. Signed-off-by: Evgeniy Polyakov diff -Nru /tmp/empty/cbus.c ./drivers/connector/cbus.c --- /tmp/empty/cbus.c 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/cbus.c 2005-04-11 16:15:29.535285712 +0400 @@ -0,0 +1,272 @@ +/* + * cbus.c + * + * 2005 Copyright (c) Evgeniy Polyakov + * 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Ultrafast message bus based on kernel connector."); + +static DEFINE_PER_CPU(struct cbus_event_container, cbus_event_list); +static int cbus_pid, cbus_need_exit; +static struct completion cbus_thread_exited; +static DECLARE_WAIT_QUEUE_HEAD(cbus_wait_queue); +static int cbus_max_queue_len = 1024; +module_param(cbus_max_queue_len, int, 0); +MODULE_PARM_DESC(cbus_max_queue_len, "Maximum CBUS queue length, " + "if it is overflowed events will be delivered using direct connector's methods."); + +static char cbus_name[] = "cbus"; + +struct cbus_event_container +{ + struct list_head event_list; + spinlock_t event_lock; + int qlen; +}; + +struct cbus_event +{ + struct list_head event_entry; + u32 cpu; + struct cn_msg msg; +}; + +static inline struct cbus_event *__cbus_dequeue(struct cbus_event_container *c) +{ + struct list_head *next = c->event_list.next; + + list_del(next); + c->qlen--; + + if (c->qlen < 0) { + printk(KERN_ERR "%s: qlen=%d after dequeue on CPU%u.\n", + cbus_name, c->qlen, smp_processor_id()); + c->qlen = 0; + } + + return list_entry(next, struct cbus_event, event_entry); +} + +static inline struct cbus_event *cbus_dequeue(struct cbus_event_container *c) +{ + struct cbus_event *event; + unsigned long flags; + + if (list_empty(&c->event_list)) + return NULL; + + spin_lock_irqsave(&c->event_lock, flags); + event = __cbus_dequeue(c); + spin_unlock_irqrestore(&c->event_lock, flags); + + return event; +} + +static inline void __cbus_enqueue(struct cbus_event_container *c, struct cbus_event *event) +{ + list_add_tail(&event->event_entry, &c->event_list); + c->qlen++; +} + +static int cbus_enqueue(struct cbus_event_container *c, struct cn_msg *msg, int gfp_mask) +{ + int err, enq = 0; + struct cbus_event *event; + unsigned long flags; + + event = kmalloc(sizeof(*event) + msg->len, gfp_mask); + if (!event) { + err = -ENOMEM; + goto err_out_exit; + } + + memcpy(&event->msg, msg, sizeof(event->msg)); + + if (msg->len) + memcpy(event+1, msg->data, msg->len); + + spin_lock_irqsave(&c->event_lock, flags); + if (c->qlen <= cbus_max_queue_len) { + __cbus_enqueue(c, event); + enq = 1; + } + spin_unlock_irqrestore(&c->event_lock, flags); + + if (!enq) { + kfree(event); + cn_netlink_send(msg, 0, gfp_mask); + } + + //wake_up_interruptible(&cbus_wait_queue); + + return 0; + +err_out_exit: + return err; +} + +int cbus_insert(struct cn_msg *msg, int gfp_flags) +{ + struct cbus_event_container *c; + int err; + + /* + * If CBUS is being removed, + * do not allow to add new events, + * it still has a race, when + * event may be added after + * all queues are processed, + * but we do not care if one + * message in each queue will not + * be delivered and CBUS is removed. + */ + if (cbus_need_exit) + return -ENODEV; + + preempt_disable(); + c = &__get_cpu_var(cbus_event_list); + + err = cbus_enqueue(c, msg, gfp_flags); + + preempt_enable(); + + return err; +} + +static int cbus_process(struct cbus_event_container *c, int all) +{ + struct cbus_event *event; + int len, i, num; + + if (list_empty(&c->event_list)) + return 0; + + if (all) + len = c->qlen; + else + len = 1; + + num = 0; + for (i=0; imsg, 0, GFP_KERNEL); + num++; + + kfree(event); + } + + return num; +} + +static int cbus_event_thread(void *data) +{ + int i, non_empty = 0, empty = 0; + struct cbus_event_container *c; + + daemonize(cbus_name); + allow_signal(SIGTERM); + set_user_nice(current, 19); + + while (!cbus_need_exit) { + if (empty || non_empty == 0 || non_empty > 10) { + wait_event_interruptible_timeout(cbus_wait_queue, 0, HZ/100); + non_empty = 0; + empty = 0; + } + + for_each_cpu(i) { + c = &per_cpu(cbus_event_list, i); + + if (cbus_process(c, 0)) + non_empty++; + else + empty = 1; + } + } + + complete_and_exit(&cbus_thread_exited, 0); +} + +static int cbus_init_event_container(struct cbus_event_container *c) +{ + INIT_LIST_HEAD(&c->event_list); + spin_lock_init(&c->event_lock); + c->qlen = 0; + + return 0; +} + +static void cbus_fini_event_container(struct cbus_event_container *c) +{ + cbus_process(c, 1); +} + +int __devinit cbus_init(void) +{ + int i, err = 0; + struct cbus_event_container *c; + + for_each_cpu(i) { + c = &per_cpu(cbus_event_list, i); + cbus_init_event_container(c); + } + + init_completion(&cbus_thread_exited); + + cbus_pid = kernel_thread(cbus_event_thread, NULL, CLONE_FS | CLONE_FILES); + if (cbus_pid < 0) { + printk(KERN_ERR "%s: Failed to create cbus event thread: err=%d.\n", + cbus_name, cbus_pid); + err = cbus_pid; + goto err_out_exit; + } + +err_out_exit: + return err; +} + +void __devexit cbus_fini(void) +{ + int i; + struct cbus_event_container *c; + + cbus_need_exit = 1; + kill_proc(cbus_pid, SIGTERM, 0); + wait_for_completion(&cbus_thread_exited); + + for_each_cpu(i) { + c = &per_cpu(cbus_event_list, i); + cbus_fini_event_container(c); + } +} + +module_init(cbus_init); +module_exit(cbus_fini); + +EXPORT_SYMBOL_GPL(cbus_insert); diff -Nru /tmp/empty/cn_queue.c ./drivers/connector/cn_queue.c --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/cn_queue.c 2005-04-11 16:12:22.511717616 +0400 @@ -0,0 +1,207 @@ +/* + * cn_queue.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static void cn_queue_wrapper(void *data) +{ + struct cn_callback_entry *cbq = (struct cn_callback_entry *)data; + + atomic_inc_and_test(&cbq->cb->refcnt); + cbq->cb->callback(cbq->cb->priv); + atomic_dec_and_test(&cbq->cb->refcnt); + + cbq->destruct_data(cbq->ddata); +} + +static struct cn_callback_entry *cn_queue_alloc_callback_entry(struct cn_callback *cb) +{ + struct cn_callback_entry *cbq; + + cbq = kmalloc(sizeof(*cbq), GFP_KERNEL); + if (!cbq) { + printk(KERN_ERR "Failed to create new callback queue.\n"); + return NULL; + } + + memset(cbq, 0, sizeof(*cbq)); + + cbq->cb = cb; + + INIT_WORK(&cbq->work, &cn_queue_wrapper, cbq); + + return cbq; +} + +static void cn_queue_free_callback(struct cn_callback_entry *cbq) +{ + cancel_delayed_work(&cbq->work); + flush_workqueue(cbq->pdev->cn_queue); + + while (atomic_read(&cbq->cb->refcnt)) { + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n", + cbq->pdev->name, atomic_read(&cbq->cb->refcnt)); + + msleep(1000); + } + + kfree(cbq); +} + +int cn_cb_equal(struct cb_id *i1, struct cb_id *i2) +{ +#if 0 + printk(KERN_INFO "%s: comparing %04x.%04x and %04x.%04x\n", + __func__, + i1->idx, i1->val, + i2->idx, i2->val); +#endif + return ((i1->idx == i2->idx) && (i1->val == i2->val)); +} + +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb) +{ + struct cn_callback_entry *cbq, *__cbq; + int found = 0; + + cbq = cn_queue_alloc_callback_entry(cb); + if (!cbq) + return -ENOMEM; + + atomic_inc(&dev->refcnt); + cbq->pdev = dev; + + spin_lock_bh(&dev->queue_lock); + list_for_each_entry(__cbq, &dev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &cb->id)) { + found = 1; + break; + } + } + if (!found) { + atomic_set(&cbq->cb->refcnt, 1); + list_add_tail(&cbq->callback_entry, &dev->queue_list); + } + spin_unlock_bh(&dev->queue_lock); + + if (found) { + atomic_dec(&dev->refcnt); + atomic_set(&cbq->cb->refcnt, 0); + cn_queue_free_callback(cbq); + return -EINVAL; + } + + cbq->nls = dev->nls; + cbq->seq = 0; + cbq->group = cbq->cb->id.idx; + + return 0; +} + +void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id) +{ + struct cn_callback_entry *cbq = NULL, *n; + int found = 0; + + spin_lock_bh(&dev->queue_lock); + list_for_each_entry_safe(cbq, n, &dev->queue_list, callback_entry) { + if (cn_cb_equal(&cbq->cb->id, id)) { + list_del(&cbq->callback_entry); + found = 1; + break; + } + } + spin_unlock_bh(&dev->queue_lock); + + if (found) { + atomic_dec(&cbq->cb->refcnt); + cn_queue_free_callback(cbq); + atomic_dec_and_test(&dev->refcnt); + } +} + +struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct sock *nls) +{ + struct cn_queue_dev *dev; + + dev = kmalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + printk(KERN_ERR "%s: Failed to allocte new struct cn_queue_dev.\n", + name); + return NULL; + } + + memset(dev, 0, sizeof(*dev)); + + snprintf(dev->name, sizeof(dev->name), "%s", name); + + atomic_set(&dev->refcnt, 0); + INIT_LIST_HEAD(&dev->queue_list); + spin_lock_init(&dev->queue_lock); + + dev->nls = nls; + dev->netlink_groups = 0; + + dev->cn_queue = create_workqueue(dev->name); + if (!dev->cn_queue) { + printk(KERN_ERR "Failed to create %s queue.\n", dev->name); + kfree(dev); + return NULL; + } + + return dev; +} + +void cn_queue_free_dev(struct cn_queue_dev *dev) +{ + struct cn_callback_entry *cbq, *n; + + flush_workqueue(dev->cn_queue); + destroy_workqueue(dev->cn_queue); + + spin_lock_bh(&dev->queue_lock); + list_for_each_entry_safe(cbq, n, &dev->queue_list, callback_entry) { + list_del(&cbq->callback_entry); + atomic_dec_and_test(&cbq->cb->refcnt); + } + spin_unlock_bh(&dev->queue_lock); + + while (atomic_read(&dev->refcnt)) { + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n", + dev->name, atomic_read(&dev->refcnt)); + + msleep(1000); + } + + memset(dev, 0, sizeof(*dev)); + kfree(dev); + dev = NULL; +} diff -Nru /tmp/empty/connector.c ./drivers/connector/connector.c --- /tmp/empty/connector.c 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/connector.c 2005-04-11 16:10:03.327876776 +0400 @@ -0,0 +1,529 @@ +/* + * connector.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); + +static int unit = NETLINK_NFLOG; +static u32 cn_idx = CN_IDX_CONNECTOR; +static u32 cn_val = CN_VAL_CONNECTOR; + +module_param(unit, int, 0); +MODULE_PARM_DESC(unit, "Netlink socket to use."); +module_param(cn_idx, uint, 0); +module_param(cn_val, uint, 0); +MODULE_PARM_DESC(cn_idx, "Connector's main device idx."); +MODULE_PARM_DESC(cn_val, "Connector's main device val."); + +static DEFINE_SPINLOCK(notify_lock); +static LIST_HEAD(notify_list); + +static struct cn_dev cdev; + +int cn_already_initialized = 0; + +/* + * msg->seq and msg->ack are used to determine message genealogy. + * When someone sends message it puts there locally unique sequence + * and random acknowledge numbers. + * Sequence number may be copied into nlmsghdr->nlmsg_seq too. + * + * Sequence number is incremented with each message to be sent. + * + * If we expect reply to our message, + * then sequence number in received message MUST be the same as in original message, + * and acknowledge number MUST be the same + 1. + * + * If we receive message and it's sequence number is not equal to one we are expecting, + * then it is new message. + * If we receive message and it's sequence number is the same as one we are expecting, + * but it's acknowledge is not equal acknowledge number in original message + 1, + * then it is new message. + * + */ +int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask) +{ + struct cn_callback_entry *__cbq; + unsigned int size; + struct sk_buff *skb; + struct nlmsghdr *nlh; + struct cn_msg *data; + struct cn_dev *dev = &cdev; + u32 groups = 0; + int found = 0; + + if (!__groups) { + spin_lock_bh(&dev->cbdev->queue_lock); + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + found = 1; + groups = __cbq->group; + } + } + spin_unlock_bh(&dev->cbdev->queue_lock); + + if (!found) { + printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", + msg->id.idx, msg->id.val, msg->seq); + return -ENODEV; + } + } + else + groups = __groups; + + size = NLMSG_SPACE(sizeof(*msg) + msg->len); + + skb = alloc_skb(size, gfp_mask); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + return -ENOMEM; + } + + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); + + data = (struct cn_msg *)NLMSG_DATA(nlh); + + memcpy(data, msg, sizeof(*data) + msg->len); +#if 0 + printk("%s: len=%u, seq=%u, ack=%u, group=%u.\n", + __func__, msg->len, msg->seq, msg->ack, groups); +#endif + + NETLINK_CB(skb).dst_groups = groups; + + netlink_broadcast(dev->nls, skb, 0, groups, gfp_mask); + + return 0; + +nlmsg_failure: + kfree_skb(skb); + return -EINVAL; +} + +/* + * Callback helper - queues work and setup destructor for given data. + */ +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) +{ + struct cn_callback_entry *__cbq; + struct cn_dev *dev = &cdev; + int found = 0; + + spin_lock_bh(&dev->cbdev->queue_lock); + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + __cbq->cb->priv = msg; + + __cbq->ddata = data; + __cbq->destruct_data = destruct_data; + + queue_work(dev->cbdev->cn_queue, &__cbq->work); + found = 1; + break; + } + } + spin_unlock_bh(&dev->cbdev->queue_lock); + + return (found)?0:-ENODEV; +} + +/* + * Skb receive helper - checks skb and msg size + * and calls callback helper. + */ +static int __cn_rx_skb(struct sk_buff *skb, struct nlmsghdr *nlh) +{ + u32 pid, uid, seq, group; + struct cn_msg *msg; + + pid = NETLINK_CREDS(skb)->pid; + uid = NETLINK_CREDS(skb)->uid; + seq = nlh->nlmsg_seq; + group = NETLINK_CB((skb)).groups; + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) { + printk(KERN_ERR "skb does not have enough length: " + "requested msg->len=%u[%u], nlh->nlmsg_len=%u, skb->len=%u.\n", + msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)), + nlh->nlmsg_len, skb->len); + return -EINVAL; + } +#if 0 + printk(KERN_INFO "pid=%u, uid=%u, seq=%u, group=%u.\n", + pid, uid, seq, group); +#endif + return cn_call_callback(msg, (void (*)(void *))kfree_skb, skb); +} + +/* + * Main netlink receiving function - + * it checks skb and netlink header sizes + * and calls skb receive helper with shared skb. + */ +static void cn_rx_skb(struct sk_buff *__skb) +{ + struct nlmsghdr *nlh; + u32 len; + int err; + struct sk_buff *skb; + + skb = skb_get(__skb); + if (!skb) { + printk(KERN_ERR "Failed to reference an skb.\n"); + kfree_skb(__skb); + return; + } +#if 0 + printk(KERN_INFO + "skb: len=%u, data_len=%u, truesize=%u, proto=%u, cloned=%d, shared=%d.\n", + skb->len, skb->data_len, skb->truesize, skb->protocol, + skb_cloned(skb), skb_shared(skb)); +#endif + if (skb->len >= NLMSG_SPACE(0)) { + nlh = (struct nlmsghdr *)skb->data; + + if (nlh->nlmsg_len < sizeof(struct cn_msg) || + skb->len < nlh->nlmsg_len || + nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) { +#if 1 + printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n", + nlh->nlmsg_len, sizeof(*nlh)); +#endif + kfree_skb(skb); + goto out; + } + + len = NLMSG_ALIGN(nlh->nlmsg_len); + if (len > skb->len) + len = skb->len; + + err = __cn_rx_skb(skb, nlh); + if (err < 0) + kfree_skb(skb); + } + +out: + kfree_skb(__skb); +} + +/* + * Netlink socket input callback - dequeues skb and + * calls main netlink receiving function. + */ +static void cn_input(struct sock *sk, int len) +{ + struct sk_buff *skb; + + while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) + cn_rx_skb(skb); +} + +/* + * Notification routing. + * Gets id and checks if + * there are notification request for it's idx and val. + * If there are such requests notify it's listeners + * with given notify event. + */ +static void cn_notify(struct cb_id *id, u32 notify_event) +{ + struct cn_ctl_entry *ent; + + spin_lock_bh(¬ify_lock); + list_for_each_entry(ent, ¬ify_list, notify_entry) { + int i; + struct cn_notify_req *req; + struct cn_ctl_msg *ctl = ent->msg; + int idx_found, val_found; + + idx_found = val_found = 0; + + req = (struct cn_notify_req *)ctl->data; + for (i=0; iidx_notify_num; ++i, ++req) { + if (id->idx >= req->first && id->idx < req->first + req->range) { + idx_found = 1; + break; + } + } + + for (i=0; ival_notify_num; ++i, ++req) { + if (id->val >= req->first && id->val < req->first + req->range) { + val_found = 1; + break; + } + } + + if (idx_found && val_found) { + struct cn_msg m; + + printk(KERN_INFO "Notifying group %x with event %u about %x.%x.\n", + ctl->group, notify_event, + id->idx, id->val); + + memset(&m, 0, sizeof(m)); + m.ack = notify_event; + + memcpy(&m.id, id, sizeof(m.id)); + cn_netlink_send(&m, ctl->group, GFP_ATOMIC); + } + } + spin_unlock_bh(¬ify_lock); +} + +/* + * Callback add routing - adds callback + * with given ID and name. + * If there is registered callback with the same + * ID it will not be added. + * + * May sleep. + */ +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)) +{ + int err; + struct cn_dev *dev = &cdev; + struct cn_callback *cb; + + cb = kmalloc(sizeof(*cb), GFP_KERNEL); + if (!cb) { + printk(KERN_INFO "%s: Failed to allocate new struct cn_callback.\n", + dev->cbdev->name); + return -ENOMEM; + } + + memset(cb, 0, sizeof(*cb)); + + scnprintf(cb->name, sizeof(cb->name), "%s", name); + + memcpy(&cb->id, id, sizeof(cb->id)); + cb->callback = callback; + + atomic_set(&cb->refcnt, 0); + + err = cn_queue_add_callback(dev->cbdev, cb); + if (err) { + kfree(cb); + return err; + } + + cn_notify(id, 0); + + return 0; +} + +/* + * Callback remove routing - removes callback + * with given ID. + * If there is no registered callback with given + * ID nothing happens. + * + * May sleep while waiting for reference counter to become zero. + */ +void cn_del_callback(struct cb_id *id) +{ + struct cn_dev *dev = &cdev; + + cn_queue_del_callback(dev->cbdev, id); + cn_notify(id, 1); +} + +/* + * Checks two connector's control messages to be the same. + * Returns 1 if they are the same or firts one is broken. + */ +static int cn_ctl_msg_equals(struct cn_ctl_msg *m1, struct cn_ctl_msg *m2) +{ + int i; + struct cn_notify_req *req1, *req2; + + if (m1->idx_notify_num != m2->idx_notify_num) + return 0; + + if (m1->val_notify_num != m2->val_notify_num) + return 0; + + if (m1->len != m2->len) + return 0; + + if ((m1->idx_notify_num + m1->val_notify_num)*sizeof(*req1) != m1->len) { + printk(KERN_ERR "Notify entry[idx_num=%x, val_num=%x, len=%u] contains garbage. Removing.\n", + m1->idx_notify_num, m1->val_notify_num, m1->len); + return 1; + } + + req1 = (struct cn_notify_req *)m1->data; + req2 = (struct cn_notify_req *)m2->data; + + for (i=0; iidx_notify_num; ++i) { + if (memcmp(req1, req2, sizeof(*req1))) + return 0; + + req1++; + req2++; + } + + for (i=0; ival_notify_num; ++i) { + if (memcmp(req1, req2, sizeof(*req1))) + return 0; + + req1++; + req2++; + } + + return 1; +} + +/* + * Main connector device's callback. + * Is used for notification requests processing. + */ +static void cn_callback(void * data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + struct cn_ctl_msg *ctl; + struct cn_ctl_entry *ent; + u32 size; + + if (msg->len < sizeof(*ctl)) { + printk(KERN_ERR "Wrong connector request size %u, must be >= %u.\n", + msg->len, sizeof(*ctl)); + return; + } + + ctl = (struct cn_ctl_msg *)msg->data; + + size = sizeof(*ctl) + (ctl->idx_notify_num + ctl->val_notify_num)*sizeof(struct cn_notify_req); + + if (msg->len != size) { + printk(KERN_ERR "Wrong connector request size %u, must be == %u.\n", + msg->len, size); + return; + } + + if (ctl->len + sizeof(*ctl) != msg->len) { + printk(KERN_ERR "Wrong message: msg->len=%u must be equal to inner_len=%u [+%u].\n", + msg->len, ctl->len, sizeof(*ctl)); + return; + } + + /* + * Remove notification. + */ + if (ctl->group == 0) { + struct cn_ctl_entry *n; + + spin_lock_bh(¬ify_lock); + list_for_each_entry_safe(ent, n, ¬ify_list, notify_entry) { + if (cn_ctl_msg_equals(ent->msg, ctl)) { + list_del(&ent->notify_entry); + kfree(ent); + } + } + spin_unlock_bh(¬ify_lock); + + return; + } + + size += sizeof(*ent); + + ent = kmalloc(size, GFP_ATOMIC); + if (!ent) { + printk(KERN_ERR "Failed to allocate %d bytes for new notify entry.\n", size); + return; + } + + memset(ent, 0, size); + + ent->msg = (struct cn_ctl_msg *)(ent + 1); + + memcpy(ent->msg, ctl, size - sizeof(*ent)); + + spin_lock_bh(¬ify_lock); + list_add(&ent->notify_entry, ¬ify_list); + spin_unlock_bh(¬ify_lock); +} + +static int cn_init(void) +{ + struct cn_dev *dev = &cdev; + int err; + + dev->input = cn_input; + dev->id.idx = cn_idx; + dev->id.val = cn_val; + + dev->nls = netlink_kernel_create(unit, dev->input); + if (!dev->nls) { + printk(KERN_ERR "Failed to create new netlink socket(%u).\n", + unit); + return -EIO; + } + + dev->cbdev = cn_queue_alloc_dev("cqueue", dev->nls); + if (!dev->cbdev) { + if (dev->nls->sk_socket) + sock_release(dev->nls->sk_socket); + return -EINVAL; + } + + err = cn_add_callback(&dev->id, "connector", &cn_callback); + if (err) { + cn_queue_free_dev(dev->cbdev); + if (dev->nls->sk_socket) + sock_release(dev->nls->sk_socket); + return -EINVAL; + } + + cn_already_initialized = 1; + + return 0; +} + +static void cn_fini(void) +{ + struct cn_dev *dev = &cdev; + + cn_already_initialized = 0; + + cn_del_callback(&dev->id); + cn_queue_free_dev(dev->cbdev); + if (dev->nls->sk_socket) + sock_release(dev->nls->sk_socket); +} + +module_init(cn_init); +module_exit(cn_fini); + +EXPORT_SYMBOL_GPL(cn_add_callback); +EXPORT_SYMBOL_GPL(cn_del_callback); +EXPORT_SYMBOL_GPL(cn_netlink_send); diff -Nru /tmp/empty/Kconfig ./drivers/connector/Kconfig --- /tmp/empty/Kconfig 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/Kconfig 2005-04-11 16:16:27.176522912 +0400 @@ -0,0 +1,27 @@ +menu "Connector - unified userspace <-> kernelspace linker" + +config CONNECTOR + tristate "Connector - unified userspace <-> kernelspace linker" + depends on NET + ---help--- + This is unified userspace <-> kernelspace connector working on top + of the netlink socket protocol. + + Connector support can also be built as a module. If so, the module + will be called cn.ko. +config CBUS + tristate "CBUS - ultra fast (for insert operations) message bus based on connector" + depends on CONNECTOR + ---help--- + This message bus allows message passing between different agents + using connector's infrastructure. + It is extremly fast for insert operations so it can be used in performance + critical pathes instead of direct connector's methods calls. + + CBUS uses per CPU variables and thus allows message reordering, + caller must be prepared (and use CPU id in it's messages). + + CBUS support can also be built as a module. If so, the module + will be called cbus. + +endmenu diff -Nru /tmp/empty/Makefile ./drivers/connector/Makefile --- /tmp/empty/Makefile 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/Makefile 2005-04-11 16:17:04.440857872 +0400 @@ -0,0 +1,3 @@ +obj-$(CONFIG_CONNECTOR) += cn.o +obj-$(CONFIG_CBUS) += cbus.o +cn-objs := cn_queue.o connector.o Binary files /tmp/empty/.tmp_cbus.o and ./drivers/connector/.tmp_cbus.o differ diff -Nru /tmp/empty/.tmp_cbus.ver ./drivers/connector/.tmp_cbus.ver --- /tmp/empty/.tmp_cbus.ver 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/.tmp_cbus.ver 2005-04-11 16:17:06.579532744 +0400 @@ -0,0 +1 @@ +__crc_cbus_insert = 0x2fcab901 ; Binary files /tmp/empty/.tmp_connector.o and ./drivers/connector/.tmp_connector.o differ diff -Nru /tmp/empty/.tmp_connector.ver ./drivers/connector/.tmp_connector.ver --- /tmp/empty/.tmp_connector.ver 1970-01-01 03:00:00.000000000 +0300 +++ ./drivers/connector/.tmp_connector.ver 2005-04-11 16:16:39.753610904 +0400 @@ -0,0 +1,3 @@ +__crc_cn_add_callback = 0xdf3c19ec ; +__crc_cn_del_callback = 0xff5a8cfe ; +__crc_cn_netlink_send = 0xa53caf8b ; --- /dev/null 2005-03-30 21:16:41.358774272 +0400 +++ ./include/linux/connector.h 2005-04-11 16:10:39.698347624 +0400 @@ -0,0 +1,166 @@ +/* + * connector.h + * + * 2004 Copyright (c) Evgeniy Polyakov + * 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __CONNECTOR_H +#define __CONNECTOR_H + +#include + +#define CN_IDX_CONNECTOR 0xffffffff +#define CN_VAL_CONNECTOR 0xffffffff + + +/* + * Maximum connector's message size. + */ +#define CONNECTOR_MAX_MSG_SIZE 1024 + +/* + * idx and val are unique identifiers which + * are used for message routing and + * must be registered in connector.h for in-kernel usage. + */ + +struct cb_id +{ + __u32 idx; + __u32 val; +}; + +struct cn_msg +{ + struct cb_id id; + + __u32 seq; + __u32 ack; + + __u32 len; /* Length of the following data */ + __u8 data[0]; +}; + +/* + * Notify structure - requests notification about + * registering/unregistering idx/val in range [first, first+range]. + */ +struct cn_notify_req +{ + __u32 first; + __u32 range; +}; + +/* + * Main notification control message + * *_notify_num - number of appropriate cn_notify_req structures after + * this struct. + * group - notification receiver's idx. + * len - total length of the attached data. + */ +struct cn_ctl_msg +{ + __u32 idx_notify_num; + __u32 val_notify_num; + __u32 group; + __u32 len; + __u8 data[0]; +}; + + +#ifdef __KERNEL__ + +#include + +#include +#include + +#include + +#define CN_CBQ_NAMELEN 32 + +struct cn_queue_dev +{ + atomic_t refcnt; + unsigned char name[CN_CBQ_NAMELEN]; + + struct workqueue_struct *cn_queue; + + struct list_head queue_list; + spinlock_t queue_lock; + + int netlink_groups; + struct sock *nls; +}; + +struct cn_callback +{ + unsigned char name[CN_CBQ_NAMELEN]; + + struct cb_id id; + void (* callback)(void *); + void *priv; + + atomic_t refcnt; +}; + +struct cn_callback_entry +{ + struct list_head callback_entry; + struct cn_callback *cb; + struct work_struct work; + struct cn_queue_dev *pdev; + + void (* destruct_data)(void *); + void *ddata; + + int seq, group; + struct sock *nls; +}; + +struct cn_ctl_entry +{ + struct list_head notify_entry; + struct cn_ctl_msg *msg; +}; + +struct cn_dev +{ + struct cb_id id; + + u32 seq, groups; + struct sock *nls; + void (*input)(struct sock *sk, int len); + + struct cn_queue_dev *cbdev; +}; + +int cn_add_callback(struct cb_id *, char *, void (* callback)(void *)); +void cn_del_callback(struct cb_id *); +int cn_netlink_send(struct cn_msg *, u32, int); + +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb); +void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id); + +struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct sock *); +void cn_queue_free_dev(struct cn_queue_dev *dev); + +int cn_cb_equal(struct cb_id *, struct cb_id *); + +#endif /* __KERNEL__ */ +#endif /* __CONNECTOR_H */ --- ./drivers/Kconfig.orig 2005-04-11 16:31:04.202194744 +0400 +++ ./drivers/Kconfig 2005-02-28 12:58:35.000000000 +0300 @@ -4,6 +4,8 @@ source "drivers/base/Kconfig" +source "drivers/connector/Kconfig" + source "drivers/mtd/Kconfig" source "drivers/parport/Kconfig" --- ./drivers/Makefile.orig 2005-04-11 16:30:48.521578560 +0400 +++ ./drivers/Makefile 2005-02-28 12:58:35.000000000 +0300 @@ -17,6 +17,8 @@ # default. obj-y += char/ +obj-$(CONFIG_CONNECTOR) += connector/ + # i810fb and intelfb depend on char/agp/ obj-$(CONFIG_FB_I810) += video/i810/ obj-$(CONFIG_FB_INTEL) += video/intelfb/ diff -Nru /tmp/empty/cn_test.c ./Documentation/connector/cn_test.c --- /tmp/empty/cn_test.c 1970-01-01 03:00:00.000000000 +0300 +++ ./Documentation/connector/cn_test.c 2005-04-11 16:11:11.967441976 +0400 @@ -0,0 +1,203 @@ +/* + * cn_test.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * 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 Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include + +#include "connector.h" + +static struct cb_id cn_test_id = { 0x123, 0x456 }; +static char cn_test_name[] = "cn_test"; +static struct sock *nls; +static struct timer_list cn_test_timer; + +void cn_test_callback(void *data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + + printk("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n", + __func__, jiffies, msg->id.idx, msg->id.val, + msg->seq, msg->ack, msg->len, (char *)msg->data); +} + +static int cn_test_want_notify(void) +{ + struct cn_ctl_msg *ctl; + struct cn_notify_req *req; + struct cn_msg *msg = NULL; + int size, size0; + struct sk_buff *skb; + struct nlmsghdr *nlh; + u32 group = 1; + + size0 = sizeof(*msg) + sizeof(*ctl) + 3*sizeof(*req); + + size = NLMSG_SPACE(size0); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + + return -ENOMEM; + } + + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - NLMSG_ALIGN(sizeof(*nlh))); + + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + memset(msg, 0, size0); + + msg->id.idx = -1; + msg->id.val = -1; + msg->seq = 0x123; + msg->ack = 0x345; + msg->len = size0 - sizeof(*msg); + + ctl = (struct cn_ctl_msg *)(msg + 1); + + ctl->idx_notify_num = 1; + ctl->val_notify_num = 2; + ctl->group = group; + ctl->len = msg->len - sizeof(*ctl); + + req = (struct cn_notify_req *)(ctl + 1); + + /* + * Idx. + */ + req->first = cn_test_id.idx; + req->range = 10; + + /* + * Val 0. + */ + req++; + req->first = cn_test_id.val; + req->range = 10; + + /* + * Val 1. + */ + req++; + req->first = cn_test_id.val + 20; + req->range = 10; + + NETLINK_CB(skb).dst_groups = ctl->group; + //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); + netlink_unicast(nls, skb, 0, 0); + + printk(KERN_INFO "Request was sent. Group=0x%x.\n", ctl->group); + + return 0; + +nlmsg_failure: + printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + kfree_skb(skb); + return -EINVAL; +} + +static u32 cn_test_timer_counter; +static void cn_test_timer_func(unsigned long __data) +{ + struct cn_msg *m; + char data[32]; + + m = kmalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC); + if (m) + { + memset(m, 0, sizeof(*m) + sizeof(data)); + + memcpy(&m->id, &cn_test_id, sizeof(m->id)); + m->seq = cn_test_timer_counter; + m->len = sizeof(data); + + m->len = scnprintf(data, sizeof(data), "counter = %u", cn_test_timer_counter) + 1; + + memcpy(m+1, data, m->len); + + cbus_insert(m, gfp_any()); + //cn_netlink_send(m, gfp_any()); + kfree(m); + } + + cn_test_timer_counter++; + + mod_timer(&cn_test_timer, jiffies + HZ); +} + +static int cn_test_init(void) +{ + int err; +#if 0 + nls = netlink_kernel_create(NETLINK_TAPBASE + 1, NULL); + if (!nls) { + printk(KERN_ERR "Failed to create new netlink socket(%u).\n", NETLINK_NFLOG); + return -EIO; + } + + err = cn_test_want_notify(); + if (err) + goto err_out; +#endif + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) + goto err_out; + cn_test_id.val++; + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) { + cn_del_callback(&cn_test_id); + goto err_out; + } + + init_timer(&cn_test_timer); + cn_test_timer.function = cn_test_timer_func; + cn_test_timer.expires = jiffies + HZ; + cn_test_timer.data = 0; + add_timer(&cn_test_timer); + + return 0; + +err_out: + if (nls && nls->sk_socket) + sock_release(nls->sk_socket); + + return err; +} + +static void cn_test_fini(void) +{ + del_timer_sync(&cn_test_timer); + cn_del_callback(&cn_test_id); + cn_test_id.val--; + cn_del_callback(&cn_test_id); + if (nls && nls->sk_socket) + sock_release(nls->sk_socket); +} + +module_init(cn_test_init); +module_exit(cn_test_fini); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Connector's test module"); diff -Nru /tmp/empty/connector.txt ./Documentation/connector/connector.txt --- /tmp/empty/connector.txt 1970-01-01 03:00:00.000000000 +0300 +++ ./Documentation/connector/connector.txt 2005-04-11 16:12:01.804865536 +0400 @@ -0,0 +1,155 @@ +/*****************************************/ +Kernel Connector. +/*****************************************/ + +Kernel connector - new netlink based userspace <-> kernel space easy to use communication module. + +Connector driver adds possibility to connect various agents using +netlink based network. +One must register callback and identifier. When driver receives +special netlink message with appropriate identifier, appropriate +callback will be called. + +From the userspace point of view it's quite straightforward: +socket(); +bind(); +send(); +recv(); + +But if kernelspace want to use full power of such connections, driver +writer must create special sockets, must know about struct sk_buff +handling... +Connector allows any kernelspace agents to use netlink based +networking for inter-process communication in a significantly easier +way: + +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); +void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); + +struct cb_id +{ + __u32 idx; + __u32 val; +}; + +idx and val are unique identifiers which must be registered in connector.h +for in-kernel usage. +void (*callback) (void *) - is a callback function which will be called +when message with above idx.val will be received by connector core. +Argument for that function must be dereferenced to struct cn_msg *. + +struct cn_msg +{ + struct cb_id id; + + __u32 seq; + __u32 ack; + + __u32 len; /* Length of the following data */ + __u8 data[0]; +}; + +/*****************************************/ +Connector interfaces. +/*****************************************/ + +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); +Registers new callback with connector core. + +struct cb_id *id - unique connector's user identifier. + It must be registered in connector.h for legal in-kernel users. +char *name - connector's callback symbolic name. +void (*callback) (void *) - connector's callback. + Argument must be dereferenced to struct cn_msg *. + +void cn_del_callback(struct cb_id *id); +Unregisters new callback with connector core. + +struct cb_id *id - unique connector's user identifier. + +void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); +Sends message to the specified groups. +It can be safely called from any context, but may silently +fail under strong memory pressure. + +struct cn_msg * - message header(with attached data). +u32 __groups - destination groups. + If __groups is zero, then appropriate group will + be searched through all registered connector users, + and message will be delivered to the group which was + created for user with the same ID as in msg. + If __groups is not zero, then message will be delivered + to the specified group. +int gfp_mask - GFP mask. + +Note: When registering new callback user, connector core assigns netlink group +to the user which is equal to it's id.idx. + +/*****************************************/ +Protocol description. +/*****************************************/ + +Current offers transport layer with fixed header. +Recommended protocol which uses such header is following: + +msg->seq and msg->ack are used to determine message genealogy. +When someone sends message it puts there locally unique sequence +and random acknowledge numbers. +Sequence number may be copied into nlmsghdr->nlmsg_seq too. + +Sequence number is incremented with each message to be sent. + +If we expect reply to our message, then sequence number in received +message MUST be the same as in original message, and acknowledge +number MUST be the same + 1. + +If we receive message and it's sequence number is not equal to one +we are expecting, then it is new message. +If we receive message and it's sequence number is the same as one we +are expecting, but it's acknowledge is not equal acknowledge number +in original message + 1, then it is new message. + +Obviously, protocol header contains above id. + +connector allows event notification in the following form: +kernel driver or userspace process can ask connector to notify it +when selected id's will be turned on or off(registered or unregistered +it's callback). It is done by sending special command to connector +driver(it also registers itself with id={-1, -1}). + +As example of usage Documentation/connector now contains cn_test.c - +testing module which uses connector to request notification +and to send messages. + + +/*****************************************/ +CBUS. +/*****************************************/ + +This message bus allows message passing between different agents +using connector's infrastructure. +It is extremely fast for insert operations so it can be used in performance +critical paths in any context instead of direct connector's methods calls. + +CBUS uses per CPU variables and thus allows message reordering, +caller must be prepared (and use CPU id in it's messages). + +Usage is very simple - just call cbus_insert(struct cn_msg *msg, int gfp_mask); +It can fail, so caller must check return value - zero on success +and negative error code otherwise. + +Benchmark with modified fork connector and fork bomb on 2-way system +did not show any differences between vanilla 2.6.11 and CBUS. + + + +/*****************************************/ +Reliability. +/*****************************************/ +Netlink itself is not reliable protocol, +that means that messages can be lost +due to memory pressure or process' receiving +queue overflowed, so caller is warned +must be prepared. That is why struct cn_msg +[main connector's message header] contains +u32 seq and u32 ack fields. -- Evgeniy Polyakov Crash is better than data corruption. -- Artur Grabowski From tgraf@suug.ch Mon Apr 11 06:32:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 06:32:30 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BDWNNg010371 for ; Mon, 11 Apr 2005 06:32:23 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 58EA91C0EB; Mon, 11 Apr 2005 15:32:39 +0200 (CEST) Date: Mon, 11 Apr 2005 15:32:39 +0200 From: Thomas Graf To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050411133239.GM26731@postel.suug.ch> References: <20050411125932.GA19538@uganda.factory.vocord.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411125932.GA19538@uganda.factory.vocord.ru> X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 786 Lines: 27 * Evgeniy Polyakov <20050411125932.GA19538@uganda.factory.vocord.ru> 2005-04-11 16:59 > + size = NLMSG_SPACE(sizeof(*msg) + msg->len); > + > + skb = alloc_skb(size, gfp_mask); > + if (!skb) { > + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); > + return -ENOMEM; > + } > + > + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); Needs same fix. > + size0 = sizeof(*msg) + sizeof(*ctl) + 3*sizeof(*req); > + > + size = NLMSG_SPACE(size0); > + > + skb = alloc_skb(size, GFP_ATOMIC); > + if (!skb) { > + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); > + > + return -ENOMEM; > + } > + > + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - NLMSG_ALIGN(sizeof(*nlh))); Just pass size0 instead of reverting the calculation. From rddunlap@osdl.org Mon Apr 11 07:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 07:07:38 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BE7XE1011976 for ; Mon, 11 Apr 2005 07:07:33 -0700 Received: from gargoyle.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3BE7Ns3011668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 07:07:24 -0700 Date: Mon, 11 Apr 2005 07:07:23 -0700 From: "Randy.Dunlap" To: linux lover Cc: netdev@oss.sgi.com Subject: Re: Function to read IP address in dot format Message-Id: <20050411070723.5de5e286.rddunlap@osdl.org> In-Reply-To: <20050411060510.12208.qmail@web52201.mail.yahoo.com> References: <20050411060510.12208.qmail@web52201.mail.yahoo.com> Organization: OSDL X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: SvC&!/v_Hr`MvpQ*|}uez16KH[#EmO2Tn~(r-y+&Jb}?Zhn}c:Eee&zq`cMb_[5`tT(22ms (.P84,bq_GBdk@Kgplnrbj;Y`9IF`Q4;Iys|#3\?*[:ixU(UR.7qJT665DxUP%K}kC0j5,UI+"y-Sw mn?l6JGvyI^f~2sSJ8vd7s[/CDY]apD`a;s1Wf)K[,.|-yOLmBl0saddr=rt->rt_src; | iph->daddr=rt->rt_dst; | Now if i want to know to which ip current | packet is being sent i am using printks but it prints | iph->saddr in int format not in user readable format. | how to do that? Look at the NIPQUAD() macro in include/linux/kernel.h and at some example uses of it. --- ~Randy From arnaldo.melo@gmail.com Mon Apr 11 07:07:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 07:08:02 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BE7vqd012001 for ; Mon, 11 Apr 2005 07:07:57 -0700 Received: by wproxy.gmail.com with SMTP id 68so1545894wri for ; Mon, 11 Apr 2005 07:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gJzs8WcU7smRlsl1zP5PtyPTsKG37EY5GL88gshXrdrCMZMYd/ZDHYPxS1K8geFUL9V7fIeOi6R7VrKHHWvk9p+IKViU3Rtgbbsph5ztdF9nRj38Dm/shKR6QHam+0vzVSXOl7Q+yuY52N7+beSKP4wkjMo9Gvi5fEn09KR1/vY= Received: by 10.54.24.9 with SMTP id 9mr977227wrx; Mon, 11 Apr 2005 07:07:47 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Mon, 11 Apr 2005 07:07:46 -0700 (PDT) Message-ID: <39e6f6c7050411070779ddcb07@mail.gmail.com> Date: Mon, 11 Apr 2005 11:07:46 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: linux lover Subject: Re: Function to read IP address in dot format Cc: netdev@oss.sgi.com In-Reply-To: <20050411060510.12208.qmail@web52201.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050411060510.12208.qmail@web52201.mail.yahoo.com> X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 30 On Apr 11, 2005 3:05 AM, linux lover wrote: > > Hello, > what is the function to read IP address in > kernel code as human readable dot quad format? IP > address are unsigned int's in ip.h file as > __u32 saddr; > __u32 daddr; > In ip_build_xmit ip header gets IP addresses > from rtable struct as > iph->saddr=rt->rt_src; > iph->daddr=rt->rt_dst; > Now if i want to know to which ip current > packet is being sent i am using printks but it prints > iph->saddr in int format not in user readable format. > how to do that? > regards, Use NIPQUAD, as in the example below: printk(KERN_DEBUG "dccp rx: packet=%s, " "source=%u.%u.%u.%u@%d, " "dest=%u.%u.%u.%u@%d\n", dccp_packet_name(dh->dccph_type), NIPQUAD(skb->nh.iph->saddr), ntohs(dh->dccph_sport), NIPQUAD(skb->nh.iph->daddr), ntohs(dh->dccph_dport)); - Arnaldo From johnpol@2ka.mipt.ru Mon Apr 11 07:51:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 07:51:13 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BEp6MN016803 for ; Mon, 11 Apr 2005 07:51:06 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3BEo1Rg005260; Mon, 11 Apr 2005 18:50:01 +0400 Date: Mon, 11 Apr 2005 18:49:52 +0400 From: Evgeniy Polyakov To: Thomas Graf Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Jay Lan Subject: [2/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050411184952.259ec639@zanzibar.2ka.mipt.ru> In-Reply-To: <20050411133239.GM26731@postel.suug.ch> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050411133239.GM26731@postel.suug.ch> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Mon, 11 Apr 2005 18:50:06 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2230 Lines: 93 Some nlmsg alignment cleanups. Documentation module cleanups. Thanks, Thomas. Signed-off-by: Evgeniy Polyakov * looking for johnpol@2ka.mipt.ru-2004/connector--main--0--patch-47 to compare with * comparing to johnpol@2ka.mipt.ru-2004/connector--main--0--patch-47 M cn_test.c M connector.c * modified files --- orig/Documentation/connector/cn_test.c +++ mod/Documentation/connector/cn_test.c @@ -55,14 +55,14 @@ size = NLMSG_SPACE(size0); - skb = alloc_skb(size, GFP_ATOMIC); + skb = alloc_skb(size, GFP_KERNEL); if (!skb) { printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); return -ENOMEM; } - nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh)); + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size0); msg = (struct cn_msg *)NLMSG_DATA(nlh); @@ -104,7 +104,6 @@ req->range = 10; NETLINK_CB(skb).dst_groups = ctl->group; - //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); netlink_unicast(nls, skb, 0, 0); printk(KERN_INFO "Request was sent. Group=0x%x.\n", ctl->group); @@ -124,8 +123,7 @@ char data[32]; m = kmalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC); - if (m) - { + if (m) { memset(m, 0, sizeof(*m) + sizeof(data)); memcpy(&m->id, &cn_test_id, sizeof(m->id)); @@ -136,8 +134,8 @@ memcpy(m+1, data, m->len); - cbus_insert(m); - //cn_netlink_send(m, 0); + cbus_insert(m, GFP_ATOMIC); + //cn_netlink_send(m, 0, GFP_ATOMIC); kfree(m); } --- orig/drivers/connector/connector.c +++ mod/drivers/connector/connector.c @@ -100,15 +100,15 @@ else groups = __groups; - size = NLMSG_SPACE(sizeof(*msg) + msg->len); + size = sizeof(*msg) + msg->len; - skb = alloc_skb(size, gfp_mask); + skb = alloc_skb(NLMSG_SPACE(size), gfp_mask); if (!skb) { - printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", NLMSG_SPACE(size)); return -ENOMEM; } - nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - NLMSG_ALIGN(sizeof(*nlh))); + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size); data = (struct cn_msg *)NLMSG_DATA(nlh); Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From linux_lover2004@yahoo.com Mon Apr 11 09:38:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 09:38:06 -0700 (PDT) Received: from web52210.mail.yahoo.com (web52210.mail.yahoo.com [206.190.39.92]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3BGbwWM025867 for ; Mon, 11 Apr 2005 09:37:59 -0700 Received: (qmail 20151 invoked by uid 60001); 11 Apr 2005 16:37:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Feyprh1uwGUzXp6f3HFTMMnu+UjHlOmpxMhhAod0s5i0T/1eQjNV5YK+NOcJ4E2xWjHwYjR2Fpf1hOmmRxjM0zN+ElxEz7H6pB7hJeqnjfe5D5Cdm0SdH1m8cQbWP4Yx3WzY+hXsme+pOqjVtn5aqBkFOOS5zYa4e+deFHtNO78= ; Message-ID: <20050411163753.20149.qmail@web52210.mail.yahoo.com> Received: from [202.56.231.117] by web52210.mail.yahoo.com via HTTP; Mon, 11 Apr 2005 09:37:52 PDT Date: Mon, 11 Apr 2005 09:37:52 -0700 (PDT) From: linux lover Subject: Why skbuff.h different for 2.4 and 2.6 kernels? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1404 Lines: 71 hello, 1) In 2.4 kernel series skbuff.h has following unions for each TCP/IP layer. /*Transport Layer*/ union { struct tcphdr *th; struct udphdr *uh; struct icmphdr *icmph; struct igmphdr *igmph; struct iphdr *ipiph; struct spxhdr *spxh; unsigned char *raw; } h; /* Network layer header */ union { struct iphdr *iph; struct ipv6hdr *ipv6h; struct arphdr *arph; struct ipxhdr *ipxh; unsigned char *raw; } nh; /* Link layer header */ union { struct ethhdr *ethernet; unsigned char *raw; } mac; AND In 2.6 kernel series skbuff.h has following unions for each TCP/IP layer. union { struct tcphdr *th; struct udphdr *uh; struct icmphdr *icmph; struct igmphdr *igmph; struct iphdr *ipiph; struct ipv6hdr *ipv6h; unsigned char *raw; } h; union { struct iphdr *iph; struct ipv6hdr *ipv6h; struct arphdr *arph; unsigned char *raw; } nh; union { unsigned char *raw; } mac; why mac union in 2.6 not have ethernet header? Also spxhdr and ipxhdr structures are removed from nh and h unions. 2) Why header structures for ipcomp,eh,esp(IPSEC) not included in skbuff.h? Then how can skbuff adds/removes those headers in skbuff? regards, linux_lover __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From arnaldo.melo@gmail.com Mon Apr 11 14:01:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 14:01:15 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BL1AjN007069 for ; Mon, 11 Apr 2005 14:01:10 -0700 Received: by wproxy.gmail.com with SMTP id 68so1679631wri for ; Mon, 11 Apr 2005 14:01:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=OCdCTtIfPGxDtrK7a8tgjzcOOlSvYdmGvSui8aMokmjOo2IIMW4KYjETClZ9UjOQ3rbC48qibeBVNGoePmZXQwNhd4zLZ5PJSuY8AyyZ0zkLrQaaU57JASttpEs8nSLvnIzoa46FMjtx0/eY+kHMhZ35B2jwrawrMT4fTt3W/04= Received: by 10.54.10.67 with SMTP id 67mr105491wrj; Mon, 11 Apr 2005 14:01:04 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Mon, 11 Apr 2005 14:01:04 -0700 (PDT) Message-ID: <39e6f6c705041114012e5a9ebe@mail.gmail.com> Date: Mon, 11 Apr 2005 18:01:04 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: linux lover Subject: Re: Why skbuff.h different for 2.4 and 2.6 kernels? Cc: netdev@oss.sgi.com In-Reply-To: <20050411163753.20149.qmail@web52210.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050411163753.20149.qmail@web52210.mail.yahoo.com> X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 617 Lines: 24 On Apr 11, 2005 1:37 PM, linux lover wrote: > hello, > 1) In 2.4 kernel series skbuff.h has following unions > for each TCP/IP layer. > union { > unsigned char *raw; > } mac; > > why mac union in 2.6 not have ethernet header? Also > spxhdr and ipxhdr structures are removed from nh and h > unions. Work in progress, the ultimate goal is to get rid of all of these unions and have just: void *transport_header; void *network_header; void *link_header; So just set mac.raw directly and cast it to the desired type. - Arnaldo From juhl-lkml@dif.dk Mon Apr 11 14:13:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 14:13:16 -0700 (PDT) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BLD7Kf008686 for ; Mon, 11 Apr 2005 14:13:08 -0700 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 6639DFFC5E for ; Mon, 11 Apr 2005 23:23:18 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10013-07 for ; Mon, 11 Apr 2005 23:23:18 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id AFD0FFFCA9 for ; Mon, 11 Apr 2005 23:23:16 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Mon, 11 Apr 2005 23:11:48 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HNMVS08M; Mon, 11 Apr 2005 23:12:55 +0200 Date: Mon, 11 Apr 2005 23:15:40 +0200 (CEST) From: Jesper Juhl To: linux-kernel@vger.kernel.org Cc: Laurence Culhane , "Fred N. van Kempen" , netdev@oss.sgi.com Subject: [PATCH] net: remove redundant NULL pointer checks prior to kfree in drivers/net/slip.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 1675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 1552 Lines: 69 kfree() checks for NULL. Checking prior to calling it is redundant. This patch removes these redundant checks from drivers/net/slip.c Signed-off-by: Jesper Juhl --- slip.c | 30 ++++++++++++------------------ 1 files changed, 12 insertions(+), 18 deletions(-) --- linux-2.6.12-rc2-mm3-orig/drivers/net/slip.c 2005-03-02 08:38:33.000000000 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/slip.c 2005-04-11 23:10:06.000000000 +0200 @@ -185,15 +185,12 @@ sl_alloc_bufs(struct slip *sl, int mtu) /* Cleanup */ err_exit: #ifdef SL_INCLUDE_CSLIP - if (cbuff) - kfree(cbuff); + kfree(cbuff); if (slcomp) slhc_free(slcomp); #endif - if (xbuff) - kfree(xbuff); - if (rbuff) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); return err; } @@ -204,13 +201,13 @@ sl_free_bufs(struct slip *sl) void * tmp; /* Free all SLIP frame buffers. */ - if ((tmp = xchg(&sl->rbuff, NULL)) != NULL) - kfree(tmp); - if ((tmp = xchg(&sl->xbuff, NULL)) != NULL) - kfree(tmp); + tmp = xchg(&sl->rbuff, NULL); + kfree(tmp); + tmp = xchg(&sl->xbuff, NULL); + kfree(tmp); #ifdef SL_INCLUDE_CSLIP - if ((tmp = xchg(&sl->cbuff, NULL)) != NULL) - kfree(tmp); + tmp = xchg(&sl->cbuff, NULL); + kfree(tmp); if ((tmp = xchg(&sl->slcomp, NULL)) != NULL) slhc_free(tmp); #endif @@ -297,13 +294,10 @@ done_on_bh: spin_unlock_bh(&sl->lock); done: - if (xbuff) - kfree(xbuff); - if (rbuff) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); #ifdef SL_INCLUDE_CSLIP - if (cbuff) - kfree(cbuff); + kfree(cbuff); #endif return err; } From shemminger@osdl.org Mon Apr 11 14:37:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 14:37:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BLbDTk010077 for ; Mon, 11 Apr 2005 14:37:13 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3BLa2s4019627 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Apr 2005 14:36:03 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j3BLa0AE004663; Mon, 11 Apr 2005 14:36:00 -0700 Date: Mon, 11 Apr 2005 14:35:59 -0700 From: Stephen Hemminger To: Baruch Even Cc: Andrew Morton , "David S. Miller" , netdev@oss.sgi.com, Injong Rhee Subject: Re: [PATCH 2/5] TCP BIC 1.1 support Message-ID: <20050411143559.32a0b764@dxpl.pdx.osdl.net> In-Reply-To: <423B9415.2010906@ev-en.org> References: <20050318162211.366ca490@dxpl.pdx.osdl.net> <423B9415.2010906@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1676 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: 863 Lines: 20 On Sat, 19 Mar 2005 02:53:09 +0000 Baruch Even wrote: > Stephen Hemminger wrote: > > This patch adds TCP BIC back in as a pluggable TCP congestion mechanism. > > This version is closer to the TCP BIC 1.1 released for Web100. > > The changes from 2.6.11 are: > > * congestion window undo fix > > * delayed ack compensation > > This can cause overshooting if the other side doesn't do delayed acking, > did anyone consider the ABC (Appropriate Byte Counting) patch from > Yee-Ting Li? > http://marc.theaimsgroup.com/?l=linux-netdev&m=110917262615630&w=2 > > FreeBSD has an option to disable delayed acking so it's not that hard to > work against a host with no delayed acks at all. I tested with FreeBSD today and see no overshoot, but I do see the undershoot (with Reno as well), because of the extra cwnd/2 that you already observed. From romieu@fr.zoreil.com Mon Apr 11 14:58:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 14:58:07 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BLw0DR011974 for ; Mon, 11 Apr 2005 14:58:01 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j3BLtHeF006698; Mon, 11 Apr 2005 23:55:17 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j3BLtBcp006697; Mon, 11 Apr 2005 23:55:11 +0200 Date: Mon, 11 Apr 2005 23:55:11 +0200 From: Francois Romieu To: akpm@osdl.org Cc: jgarzik@pobox.com, TommyDrum , netdev@oss.sgi.com Subject: [patch 2.6.12-rc2-mm3 1/1] r8169: new PCI id Message-ID: <20050411215511.GA2819@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1677 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: 718 Lines: 21 The USR 997902 is based on the 8169 chipset. The value has been extracted from the sources of the driver which comes with the manufacturer's cdrom. Heads-up and test by TommyDrum . Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-610 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-610 2005-04-11 23:00:42.732205462 +0200 +++ b/drivers/net/r8169.c 2005-04-11 23:01:11.372565356 +0200 @@ -176,6 +176,7 @@ const static struct { static struct pci_device_id rtl8169_pci_tbl[] = { {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0x16ec, 0x0116, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0,}, }; _ From linux_lover2004@yahoo.com Mon Apr 11 18:26:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 18:26:25 -0700 (PDT) Received: from web52209.mail.yahoo.com (web52209.mail.yahoo.com [206.190.39.91]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3C1QJ5q024150 for ; Mon, 11 Apr 2005 18:26:19 -0700 Received: (qmail 69497 invoked by uid 60001); 12 Apr 2005 01:26:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=RbM4Onsq1kzEFhhgYtckTrZ6zY4Md033alU0iD/Onkjmhc1TnMoL+y3cYHNRrA9sTs9eZl304xb1shEJ0PtIrpgvZCQukZ+tsqlY8Be4mmbTtP8+dXbnqsuVTnkwMvDzyZcj07TXpkzmRCoaVA2yJn0jAwPCg5g1KP55HLnG+lI= ; Message-ID: <20050412012614.69495.qmail@web52209.mail.yahoo.com> Received: from [202.56.231.117] by web52209.mail.yahoo.com via HTTP; Mon, 11 Apr 2005 18:26:13 PDT Date: Mon, 11 Apr 2005 18:26:13 -0700 (PDT) From: linux lover Subject: Re: Why skbuff.h different for 2.4 and 2.6 kernels? To: acme@conectiva.com.br Cc: netdev@oss.sgi.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 49 Hello, Thanks for reply. Can you please tell me about my second question? 2)But Why header structures for ipcomp, eh, esp(IPSEC) not included in skbuff.h? regards, linux_lover. --- Arnaldo Carvalho de Melo wrote: > On Apr 11, 2005 1:37 PM, linux lover > wrote: > > hello, > > 1) In 2.4 kernel series skbuff.h has following > unions > > for each TCP/IP layer. > > > > union { > > unsigned char *raw; > > } mac; > > > > why mac union in 2.6 not have ethernet header? > Also > > spxhdr and ipxhdr structures are removed from nh > and h > > unions. > > Work in progress, the ultimate goal is to get rid of > all of these unions and > have just: > > void *transport_header; > void *network_header; > void *link_header; > > So just set mac.raw directly and cast it to the > desired type. > > - Arnaldo > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From arnaldo.melo@gmail.com Mon Apr 11 18:56:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 18:56:45 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C1ue2K025790 for ; Mon, 11 Apr 2005 18:56:40 -0700 Received: by wproxy.gmail.com with SMTP id 71so3666516wra for ; Mon, 11 Apr 2005 18:56:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=jTfgUOXBfv2iTH5LRFl9ty+zHWVysRQGpkUo3vxYR3U06y6/N7w6rUU5EiNXMpnpmJwTdLOiUcKWLGdIfCHJ5KrFiU4X0DJrua7f6HdCfSx8VyL9IGuM5QtuSWAlhW0fHkyVp/FVMt/qD3I7f03FsqhqFnPMkIbe8//gAMk9JoM= Received: by 10.54.50.33 with SMTP id x33mr2616216wrx; Mon, 11 Apr 2005 18:56:35 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Mon, 11 Apr 2005 18:56:35 -0700 (PDT) Message-ID: <39e6f6c705041118561348e2d9@mail.gmail.com> Date: Mon, 11 Apr 2005 22:56:35 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: linux lover Subject: Re: Why skbuff.h different for 2.4 and 2.6 kernels? Cc: netdev@oss.sgi.com In-Reply-To: <20050412012614.69495.qmail@web52209.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050412012614.69495.qmail@web52209.mail.yahoo.com> X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 472 Lines: 12 On Apr 11, 2005 10:26 PM, linux lover wrote: > Hello, > Thanks for reply. Can you please tell me about > my second question? > 2)But Why header structures for ipcomp, eh, > esp(IPSEC) not included in skbuff.h? I thought I have answered this, the reason to have the layer pointers in skb be void is that skb is core/generic infrastructure, it should not have any kind of protocol specific structures/information in it. - Arnaldo From linux_lover2004@yahoo.com Mon Apr 11 19:14:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 19:14:10 -0700 (PDT) Received: from web52210.mail.yahoo.com (web52210.mail.yahoo.com [206.190.39.92]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3C2E2QV026793 for ; Mon, 11 Apr 2005 19:14:05 -0700 Received: (qmail 11196 invoked by uid 60001); 12 Apr 2005 02:13:57 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=lpzyKY0yH9QlkUKNvAKFe4uzH0lOgqXF31CCrIb+4mxpMhXvm+OfvD4DAAiEZD1VmyIOfp7pYBe8LJnPxAPJiTGvZmJQpFvHt8WktwzxdmuWgLyoXATVsvYg0QPYaDiP8UI/7dQuxVfVv/+kHrM7irlZJaJCYcCKuX63jDPr864= ; Message-ID: <20050412021357.11194.qmail@web52210.mail.yahoo.com> Received: from [202.56.231.117] by web52210.mail.yahoo.com via HTTP; Mon, 11 Apr 2005 19:13:57 PDT Date: Mon, 11 Apr 2005 19:13:57 -0700 (PDT) From: linux lover Subject: Re: Why skbuff.h different for 2.4 and 2.6 kernels? To: acme@conectiva.com.br Cc: netdev@oss.sgi.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 46 --- Arnaldo Carvalho de Melo wrote: > On Apr 11, 2005 10:26 PM, linux lover Hello, Sorry if my questions are stupid but again have one question when skbuff.h is implemeted as void *transport_header; void *network_header; void *link_header; Then how say ESP packet can be constructed in network stack. ESP has structure as New IP header + ESP header + IP header + TCP/UDP header + ESP trailer + ESP auth. header Does it then remains only with playing skbuff by using skb_push and skb_pull in ESP packet processing once skbuff.h will change? Please kindly correct me to understand this. regards, linux_lover. wrote: > > Hello, > > Thanks for reply. Can you please tell me > about > > my second question? > > 2)But Why header structures for ipcomp, eh, > > esp(IPSEC) not included in skbuff.h? > > I thought I have answered this, the reason to have > the layer pointers in skb > be void is that skb is core/generic infrastructure, > it should not have any kind > of protocol specific structures/information in it. > > - Arnaldo > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From temp02@bluereef.com.au Mon Apr 11 22:08:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 22:08:07 -0700 (PDT) Received: from bluereef.com.au (203-213-71-50-vic.tpgi.com.au [203.213.71.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C57uRG003838 for ; Mon, 11 Apr 2005 22:08:02 -0700 Received: from tunafish (10.1.1.80:3583) by bluereef.com.au with [XMail 1.17 (Linux/Ix86) ESMTP Server] id for from ; Tue, 12 Apr 2005 15:23:54 +1000 Message-ID: <08f801c53f1c$3cf105f0$5001010a@bluereef.local> From: "Andrew Hall" To: Subject: Dead loop on Virtual device br0 Date: Tue, 12 Apr 2005 14:58:16 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08F5_01C53F70.0E8B89C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: temp02@bluereef.com.au Precedence: bulk X-list: netdev Content-Length: 2110 Lines: 62 This is a multi-part message in MIME format. ------=_NextPart_000_08F5_01C53F70.0E8B89C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Not sure if this is a possible bug, but we are seeing this message a = lot. We are using 2.6.10 and have now tried 2.6.11.5 with native ipsec, = brouting, netfilter and HTB queuing enabled. If I shut down the ipsec = tunnel, this message goes away. Can someone please explain what it means and whether it's a bug? Please let me know if there is any more information you need. thanks, Andrew. ------=_NextPart_000_08F5_01C53F70.0E8B89C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Not sure if this is a possible bug, but = we are=20 seeing this message a lot.
 
We are using 2.6.10 and have now=20 tried 2.6.11.5 with native ipsec, brouting, netfilter and HTB = queuing=20 enabled. If I shut down the ipsec tunnel, this message goes = away.
 
Can someone please explain what it = means and=20 whether it's a bug?
 
Please let me know if there is any more = information=20 you need.
 
thanks,
 
Andrew.
------=_NextPart_000_08F5_01C53F70.0E8B89C0-- From horms@koto.vergenet.net Mon Apr 11 23:34:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Apr 2005 23:34:23 -0700 (PDT) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C6YCCd007160 for ; Mon, 11 Apr 2005 23:34:13 -0700 Received: by koto.vergenet.net (Postfix, from userid 7100) id D98E434031; Tue, 12 Apr 2005 15:09:42 +0900 (JST) Date: Tue, 12 Apr 2005 15:20:27 +0900 From: Horms To: =?iso-8859-1?Q?J=F6rn?= Engel Cc: Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com, Mike Phillips , Philip Blundell , David Dillow , Paul Gortmaker , Mike McLagan , Arnaldo Carvalho de Melo , Jan-Pascal van Best , Andreas Mohr <100.30936@germany.net>, p2@ace.ulyssis.student.kuleuven.ac.be, Thomas Bogendoerfer , George Anzinger , Daniele Venzano , Jay Schulist Subject: [PATCH] Maintainers list update: linux-net -> netdev Message-ID: <20050412062027.GA1614@verge.net.au> Mail-Followup-To: =?iso-8859-1?Q?J=F6rn?= Engel , Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com, Mike Phillips , Philip Blundell , David Dillow , Paul Gortmaker , Mike McLagan , Arnaldo Carvalho de Melo , Jan-Pascal van Best , Andreas Mohr <100.30936@germany.net>, p2@ace.ulyssis.student.kuleuven.ac.be, Thomas Bogendoerfer , George Anzinger , Daniele Venzano , Jay Schulist Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050409135205.GA13305@wohnheim.fh-wedel.de> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev Content-Length: 4362 Lines: 191 On Sat, Apr 09, 2005 at 03:52:05PM +0200, Jörn Engel wrote: > On Fri, 8 April 2005 22:16:07 +0200, Pavel Machek wrote: > > > > More importantly, it is still listed as "the list" for network > > drivers... > > > > NETWORK DEVICE DRIVERS > > P: Andrew Morton > > M: akpm@osdl.org > > P: Jeff Garzik > > M: jgarzik@pobox.com > > L: linux-net@vger.kernel.org > > S: Maintained > > Maybe one of the two maintainers might want to change that? ;) Use netdev as the mailing list contact instead of the mostly dead linux-net list. Signed-off-by: Horms ===== MAINTAINERS 1.295 vs edited ===== --- 1.295/MAINTAINERS 2005-04-04 06:20:11 +09:00 +++ edited/MAINTAINERS 2005-04-12 15:11:38 +09:00 @@ -73,7 +73,7 @@ 3C359 NETWORK DRIVER P: Mike Phillips M: mikep@linuxtr.net -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: linux-tr@linuxtr.net W: http://www.linuxtr.net S: Maintained @@ -81,13 +81,13 @@ 3C505 NETWORK DRIVER P: Philip Blundell M: philb@gnu.org -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained 3CR990 NETWORK DRIVER P: David Dillow M: dave@thedillows.org -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained 3W-XXXX ATA-RAID CONTROLLER DRIVER @@ -143,7 +143,7 @@ 8390 NETWORK DRIVERS [WD80x3/SMC-ELITE, SMC-ULTRA, NE2000, 3C503, etc.] P: Paul Gortmaker M: p_gortmaker@yahoo.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained A2232 SERIAL BOARD DRIVER @@ -334,7 +334,7 @@ ARPD SUPPORT P: Jonathan Layes -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained ASUS ACPI EXTRAS DRIVER @@ -708,7 +708,7 @@ DIGI RIGHTSWITCH NETWORK DRIVER P: Rick Richardson -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com W: http://www.digi.com S: Orphaned @@ -814,7 +814,7 @@ ETHEREXPRESS-16 NETWORK DRIVER P: Philip Blundell M: philb@gnu.org -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained ETHERNET BRIDGE @@ -877,7 +877,7 @@ FRAME RELAY DLCI/FRAD (Sangoma drivers too) P: Mike McLagan M: mike.mclagan@linux.org -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained FREEVXFS FILESYSTEM @@ -1217,7 +1217,7 @@ IPX NETWORK LAYER P: Arnaldo Carvalho de Melo M: acme@conectiva.com.br -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained IRDA SUBSYSTEM @@ -1594,13 +1594,13 @@ M: akpm@osdl.org P: Jeff Garzik M: jgarzik@pobox.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NETWORKING [GENERAL] P: Networking Team M: netdev@oss.sgi.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NETWORKING [IPv4/IPv6] @@ -1636,7 +1636,7 @@ P: Jan-Pascal van Best and Andreas Mohr M: Jan-Pascal van Best M: Andreas Mohr <100.30936@germany.net> -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NINJA SCSI-3 / NINJA SCSI-32Bi (16bit/CardBus) PCMCIA SCSI HOST ADAPTER DRIVER @@ -1678,7 +1678,7 @@ M: p2@ace.ulyssis.student.kuleuven.ac.be P: Mike Phillips M: mikep@linuxtr.net -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: linux-tr@linuxtr.net W: http://www.linuxtr.net S: Maintained @@ -1783,7 +1783,7 @@ PCNET32 NETWORK DRIVER P: Thomas Bogendörfer M: tsbogend@alpha.franken.de -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained PHRAM MTD DRIVER @@ -1795,7 +1795,7 @@ POSIX CLOCKS and TIMERS P: George Anzinger M: george@mvista.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Supported PNP SUPPORT @@ -2042,7 +2042,7 @@ P: Daniele Venzano M: venza@brownhat.org W: http://www.brownhat.org/sis900.html -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained SIS FRAMEBUFFER DRIVER @@ -2101,7 +2101,7 @@ SONIC NETWORK DRIVER P: Thomas Bogendoerfer M: tsbogend@alpha.franken.de -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained SONY VAIO CONTROL DEVICE DRIVER @@ -2151,7 +2151,7 @@ SPX NETWORK LAYER P: Jay Schulist M: jschlst@samba.org -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Supported SRM (Alpha) environment access @@ -2230,7 +2230,7 @@ TOKEN-RING NETWORK DRIVER P: Mike Phillips M: mikep@linuxtr.net -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: linux-tr@linuxtr.net W: http://www.linuxtr.net S: Maintained From nakam@linux-ipv6.org Tue Apr 12 01:17:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 01:17:23 -0700 (PDT) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C8HIsP013918 for ; Tue, 12 Apr 2005 01:17:18 -0700 Received: from [192.168.2.151] (polaris.linux-ipv6.org [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id E2E5D1077; Tue, 12 Apr 2005 17:17:06 +0900 (JST) Message-ID: <425B8401.1010609@linux-ipv6.org> Date: Tue, 12 Apr 2005 17:17:05 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca, Herbert Xu Cc: "David S. Miller" , Patrick McHardy , netdev Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> <425A0F00.8070509@linux-ipv6.org> <1113218805.1089.357.camel@jzny.localdomain> In-Reply-To: <1113218805.1089.357.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 741 Lines: 28 Hello Herbert and Jamal, jamal wrote: > On Mon, 2005-04-11 at 01:45, Masahide NAKAMURA wrote: > >>>Do you have anymore patches? If not i can give these a quick test; >>>Masahide has a better test setup and if he has time he should as well. >> >>I can, but about 24 hours later. I'll test it there is no update and >>if it isn't too late then. >> short report: My testing is not completed but, I've tested below and it is fine: add/del/flush SP and their notifications through netlink (using modified iproute2/ip). new "xfrm_userpolicy_delete" works fine on this case; used byid=1 when deleting SP with specifying SP index. I'll test the rest case (17 hours later): - using pfkey - using both sockets Thanks, -- Masahide NAKAMURA From dale@farnsworth.org Tue Apr 12 02:55:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 02:55:30 -0700 (PDT) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3C9tNhp021684 for ; Tue, 12 Apr 2005 02:55:23 -0700 Received: (qmail 21253 invoked by uid 1000); 12 Apr 2005 09:55:22 -0000 From: "Dale Farnsworth" Date: Tue, 12 Apr 2005 02:55:22 -0700 To: Benjamin Herrenschmidt Cc: Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos Message-ID: <20050412095522.GA20129@xyzzy> References: <1113289985.21548.66.camel@gaston> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113289985.21548.66.camel@gaston> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 2309 Lines: 48 On Tue, Apr 12, 2005 at 07:13:04AM +0000, Benjamin Herrenschmidt wrote: > This patch allows Kconfig to build the MV643xx ethernet driver on > Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing > fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in > there as the interrupt is shared if I understand things correctly. > > Signed-off-by: Benjamin Herrenschmidt > Signed-off-by: Fabio Massimo Di Nitto This looks identical to the patch I posted to netdev two weeks ago as the first of 20 patches for the MV643xx ethernet driver. See and . Thanks, -Dale > #! /bin/sh -e > > . $(dirname $0)/DPATCH > > @DPATCH@ > diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig > --- linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig 2005-04-11 16:13:06.000000000 +0200 > +++ /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig 2005-04-12 08:05:33.535955920 +0200 > @@ -2044,7 +2044,7 @@ > > config MV643XX_ETH > tristate "MV-643XX Ethernet support" > - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 > + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 || PPC_MULTIPLATFORM > help > This driver supports the gigabit Ethernet on the Marvell MV643XX > chipset which is used in the Momenco Ocelot C and Jaguar ATX and > diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c > --- linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c 2005-04-07 14:57:16.000000000 +0200 > +++ /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c 2005-04-12 08:07:36.246301112 +0200 > @@ -668,7 +668,7 @@ > spin_lock_irq(&mp->lock); > > err = request_irq(dev->irq, mv643xx_eth_int_handler, > - SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev); > + SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev); > > if (err) { > printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n", > From linux_lover2004@yahoo.com Tue Apr 12 03:08:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 03:08:51 -0700 (PDT) Received: from web52207.mail.yahoo.com (web52207.mail.yahoo.com [206.190.39.89]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3CA8kkM023189 for ; Tue, 12 Apr 2005 03:08:46 -0700 Received: (qmail 53542 invoked by uid 60001); 12 Apr 2005 10:08:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=qrLVYTaVUxGklhzF4FGSpWrb4hg6kGFESGiBERFaFELY96MtTj2L/4k0kAgnmwXJL7YX4vGOXNEnRTNAtpD4t1bea4nDu2ojYPapS/TTm+cQemRxU/RrNMBMH90TDBsACkbLSG00CVBvAeXV81ztIdmn0YHsn+YI/gN4jFKRGCI= ; Message-ID: <20050412100841.53540.qmail@web52207.mail.yahoo.com> Received: from [202.56.231.117] by web52207.mail.yahoo.com via HTTP; Tue, 12 Apr 2005 03:08:41 PDT Date: Tue, 12 Apr 2005 03:08:41 -0700 (PDT) From: linux lover Subject: tcp packet building problem To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 547 Lines: 18 hello, I am studying kernel 2.4.20-8 kernel on RH9 and found that for UDP and ICMP packets skb_reserve is used for EThernet header but why TCP packet routines ip_queue_xmit & ip_queue_xmit2 are not using skb_reserve for Ethernet header? Where is header room is allocated for ethernet? If i am missing something please point out me. Thanks in advance. regards, linux_lover. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From fabbione@ubuntu.com Tue Apr 12 03:44:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 03:44:32 -0700 (PDT) Received: from trider-g7.fabbione.net (port49.ds1-van.adsl.cybercity.dk [212.242.141.114]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CAiQpi030137 for ; Tue, 12 Apr 2005 03:44:27 -0700 Received: from localhost (localhost [127.0.0.1]) by trider-g7.fabbione.net (Postfix) with ESMTP id D64F5292A; Tue, 12 Apr 2005 12:44:24 +0200 (CEST) Received: from trider-g7.fabbione.net ([127.0.0.1]) by localhost (trider-g7 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23439-03-3; Tue, 12 Apr 2005 12:44:18 +0200 (CEST) Received: from [192.168.1.6] (gordian.int.fabbione.net [192.168.1.6]) by trider-g7.fabbione.net (Postfix) with ESMTP id 2B0A42922; Tue, 12 Apr 2005 12:44:17 +0200 (CEST) Message-ID: <425BA688.9010607@ubuntu.com> Date: Tue, 12 Apr 2005 12:44:24 +0200 From: Fabio Massimo Di Nitto User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Farnsworth Cc: Benjamin Herrenschmidt , Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos References: <1113289985.21548.66.camel@gaston> <20050412095522.GA20129@xyzzy> In-Reply-To: <20050412095522.GA20129@xyzzy> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fabbione.net X-Virus-Status: Clean X-archive-position: 1686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fabbione@ubuntu.com Precedence: bulk X-list: netdev Content-Length: 2112 Lines: 52 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dale Farnsworth wrote: > On Tue, Apr 12, 2005 at 07:13:04AM +0000, Benjamin Herrenschmidt wrote: > >>This patch allows Kconfig to build the MV643xx ethernet driver on >>Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing >>fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in >>there as the interrupt is shared if I understand things correctly. >> >>Signed-off-by: Benjamin Herrenschmidt >>Signed-off-by: Fabio Massimo Di Nitto > > > This looks identical to the patch I posted to netdev two weeks ago > as the first of 20 patches for the MV643xx ethernet driver. > > See and > . It is possible. I received an old patch from Sven Luther and bounced to Benjamin rediffed against 2.6.12rc2, but the bits ended to be exactly the same. Fabio PS feel free to claim credits on it. I don't want for sure take over your work :) - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQlumhlA6oBJjVJ+OAQK/NQ/9FLAIyMR+8fnpOygf7PVFSC0bEMZ9GVuk apCzX79QOjKAOOEaI/oSZEaH6K4/93lnUS1CjUiRYCv43mQ9RIw5cSs+if6TqSUF UOzRiFIg269BTIvIJVklsGUN+lC0C3Z66VQzWYkS84UJ3gQoHs55IRhccWqVMO2p L/VrcypZV5yD7OmqfsE7JJ4EYWtg/K3xigz+y7ZkyOfhuKWJdFbtRM+jjm67gMGq J+IqXgLpN4dMp/C0woVjfE2/mebqiBN2ft6qPCYlgwXKXN7wPKcSodMpK6D64x6T juvaSn6wgvQWmuRJh9bRBkHBM78eYiGFfBa4Mh8Il2aNrLmxjn8I52/wfq/wXd8j 4sDCnIC6YtNf5dbhK2jY6M9YCBs3SxzJu9O6yCjGGVfp0dpnPLFpbiZnWMAXQGz4 sVA7YCejkUJYMiJY9mlIh7960+V+g+PIBCk7myaOML24bsUp7AfAJtzdqQZqFSau ZpD0e77prl16F4gOb+pMt+JGVeOWeZqVuhg8GlklFaAHGVBujE9Zb+uKh4ZTeag9 ksxWDZACe/kxNc9rFvBpabNLzK5oi4Tn4LWVRr105c6nLSXwladckUnT3MCSTwHU yRD5YOerF0Rerh6OyWYw8FoG+vHSfIm6w87QxNSgQMjv6wOhZRVTyukF/A2V42tw nq3U4qR66hM= =uGjK -----END PGP SIGNATURE----- From laforge@gnumonks.org Tue Apr 12 03:54:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 03:55:03 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CAst9L030996 for ; Tue, 12 Apr 2005 03:54:55 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DLJ2g-0004uO-Jc; Tue, 12 Apr 2005 12:54:50 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DLJ2Y-0003vc-Rx; Tue, 12 Apr 2005 12:54:42 +0200 Date: Tue, 12 Apr 2005 12:54:42 +0200 From: Harald Welte To: jamal Cc: Thomas Graf , Henrik Nordstrom , "David S. Miller" , Andrea G Forte , hasso@estpak.ee, nhorman@redhat.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: primary and secondary ip addresses Message-ID: <20050412105442.GV7510@sunbeam.de.gnumonks.org> References: <41C30212.6000906@cs.columbia.edu> <20041217112025.27688eb6.davem@davemloft.net> <1103487517.1047.181.camel@jzny.localdomain> <20041219214120.GX17302@sunbeam.de.gnumonks.org> <20041219220211.GQ17998@postel.suug.ch> <1103497168.1046.218.camel@jzny.localdomain> <1103500587.1048.269.camel@jzny.localdomain> <1103550901.1050.292.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="apg+fY3UKMMABzWO" Content-Disposition: inline In-Reply-To: <1103550901.1050.292.camel@jzny.localdomain> User-Agent: mutt-ng 1.5.8-r168i (Debian) X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 5428 Lines: 171 --apg+fY3UKMMABzWO Content-Type: multipart/mixed; boundary="abYdCjSRCBwcb+dP" Content-Disposition: inline --abYdCjSRCBwcb+dP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 20, 2004 at 08:55:02AM -0500, jamal wrote: > Didnt boot ;-> > A small silly magic number i missed. Now boots - but doesnt mean it > works. And i dont have much time to spare chasing it. Due to a customer having again trouble with this issue, I was forced to actually spend some time testing it (and merging it to a current kernel). At least in my simple tests, it worked like a charm :) I've changed your wording 'ALIAS' to the (as I think) more apropriate 'SECONDARY', and did some minor cosmetic changes to make it apply against 2.6.12-rc2. Dave, would you consider adding this patch to your tree? Signed-off-by: Harald Welte --=20 - Harald Welte http://gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --abYdCjSRCBwcb+dP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-2.6.12-rc2-promote_secondaries.patch" Content-Transfer-Encoding: quoted-printable diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/include/linux/inetdevice.h linux-2.6.12-rc2-propag/include/linux/= inetdevice.h --- linux-2.6.12-rc2/include/linux/inetdevice.h 2005-03-02 08:38:13.0000000= 00 +0100 +++ linux-2.6.12-rc2-propag/include/linux/inetdevice.h 2005-04-12 10:21:45.= 000000000 +0200 @@ -29,6 +29,7 @@ int no_xfrm; int no_policy; int force_igmp_version; + int promote_secondaries; void *sysctl; }; =20 @@ -71,6 +72,7 @@ #define IN_DEV_SEC_REDIRECTS(in_dev) (ipv4_devconf.secure_redirects || (in= _dev)->cnf.secure_redirects) #define IN_DEV_IDTAG(in_dev) ((in_dev)->cnf.tag) #define IN_DEV_MEDIUM_ID(in_dev) ((in_dev)->cnf.medium_id) +#define IN_DEV_PROMOTE_SECONDARIES(in_dev) (ipv4_devconf.promote_secondari= es || (in_dev)->cnf.promote_secondaries) =20 #define IN_DEV_RX_REDIRECTS(in_dev) \ ((IN_DEV_FORWARD(in_dev) && \ diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/include/linux/sysctl.h linux-2.6.12-rc2-propag/include/linux/sysc= tl.h --- linux-2.6.12-rc2/include/linux/sysctl.h 2005-04-09 12:59:20.000000000 += 0200 +++ linux-2.6.12-rc2-propag/include/linux/sysctl.h 2005-04-12 10:18:38.0000= 00000 +0200 @@ -399,6 +399,7 @@ NET_IPV4_CONF_FORCE_IGMP_VERSION=3D17, NET_IPV4_CONF_ARP_ANNOUNCE=3D18, NET_IPV4_CONF_ARP_IGNORE=3D19, + NET_IPV4_CONF_PROMOTE_SECONDARIES=3D20, __NET_IPV4_CONF_MAX }; =20 diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E12-rc2/net/ipv4/devinet.c linux-2.6.12-rc2-propag/net/ipv4/devinet.c --- linux-2.6.12-rc2/net/ipv4/devinet.c 2005-04-09 12:59:21.000000000 +0200 +++ linux-2.6.12-rc2-propag/net/ipv4/devinet.c 2005-04-12 10:19:53.00000000= 0 +0200 @@ -233,11 +233,14 @@ static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, int destroy) { + struct in_ifaddr *promote =3D NULL; struct in_ifaddr *ifa1 =3D *ifap; =20 ASSERT_RTNL(); =20 - /* 1. Deleting primary ifaddr forces deletion all secondaries */ + /* 1. Deleting primary ifaddr forces deletion all secondaries=20 + * unless alias promotion is set + **/ =20 if (!(ifa1->ifa_flags & IFA_F_SECONDARY)) { struct in_ifaddr *ifa; @@ -251,11 +254,16 @@ continue; } =20 - *ifap1 =3D ifa->ifa_next; + if (!IN_DEV_PROMOTE_SECONDARIES(in_dev)) { + *ifap1 =3D ifa->ifa_next; =20 - rtmsg_ifa(RTM_DELADDR, ifa); - notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa); - inet_free_ifa(ifa); + rtmsg_ifa(RTM_DELADDR, ifa); + notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa); + inet_free_ifa(ifa); + } else { + promote =3D ifa; + break; + } } } =20 @@ -281,6 +289,13 @@ if (!in_dev->ifa_list) inetdev_destroy(in_dev); } + + if (promote && IN_DEV_PROMOTE_SECONDARIES(in_dev)) { + /* not sure if we should send a delete notify first? */ + promote->ifa_flags &=3D ~IFA_F_SECONDARY; + rtmsg_ifa(RTM_NEWADDR, promote); + notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote); + } } =20 static int inet_insert_ifa(struct in_ifaddr *ifa) @@ -1383,6 +1398,15 @@ .proc_handler =3D &ipv4_doint_and_flush, .strategy =3D &ipv4_doint_and_flush_strategy, }, + { + .ctl_name =3D NET_IPV4_CONF_PROMOTE_SECONDARIES, + .procname =3D "promote_secondaries", + .data =3D &ipv4_devconf.promote_secondaries, + .maxlen =3D sizeof(int), + .mode =3D 0644, + .proc_handler =3D &ipv4_doint_and_flush, + .strategy =3D &ipv4_doint_and_flush_strategy, + }, }, .devinet_dev =3D { { --abYdCjSRCBwcb+dP-- --apg+fY3UKMMABzWO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCW6jyXaXGVTD0i/8RAiiwAJ9z/9TAQFRjA/rKGhnx9n3cG+mEIgCfbRx/ iaxck97fKIKkBbvm3n3MBUQ= =PHU2 -----END PGP SIGNATURE----- --apg+fY3UKMMABzWO-- From dale@farnsworth.org Tue Apr 12 05:08:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 05:08:19 -0700 (PDT) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3CC8EcY007013 for ; Tue, 12 Apr 2005 05:08:14 -0700 Received: (qmail 23099 invoked by uid 1000); 12 Apr 2005 12:08:13 -0000 From: "Dale Farnsworth" Date: Tue, 12 Apr 2005 05:08:13 -0700 To: Fabio Massimo Di Nitto Cc: Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos Message-ID: <20050412120813.GA22502@xyzzy> References: <1113289985.21548.66.camel@gaston> <20050412095522.GA20129@xyzzy> <425BA688.9010607@ubuntu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425BA688.9010607@ubuntu.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 807 Lines: 20 On Tue, Apr 12, 2005 at 10:44:24AM +0000, Fabio Massimo Di Nitto wrote: > Dale Farnsworth wrote: > > This looks identical to the patch I posted to netdev two weeks ago > > as the first of 20 patches for the MV643xx ethernet driver. > > > > See and > > . > > It is possible. I received an old patch from Sven Luther and bounced to > Benjamin rediffed against 2.6.12rc2, but the bits ended to be exactly > the same. > > PS feel free to claim credits on it. I don't want for sure take over > your work :) No problem. It was Nicolas' and Sven's patch and Like Sven said this one is trivial. Mainly, I wanted to mention the other 19 patches I've sent that I hope get accepted soon. -Dale From itkes@imec.msu.ru Tue Apr 12 05:31:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 05:31:52 -0700 (PDT) Received: from fat.imec.msu.ru (postfix@fat.imec.msu.ru [193.232.114.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CCVjDD008719 for ; Tue, 12 Apr 2005 05:31:46 -0700 Received: from mx (localhost.localdomain [127.0.0.1]) by fat.imec.msu.ru (Postfix) with ESMTP id 193F05B503 for ; Tue, 12 Apr 2005 16:31:41 +0400 (MSD) Received: from 193.232.114.87 (SquirrelMail authenticated user itkes) by mx with HTTP; Tue, 12 Apr 2005 16:31:41 +0400 (MSD) Message-ID: <3558.193.232.114.87.1113309101.squirrel@mx> Date: Tue, 12 Apr 2005 16:31:41 +0400 (MSD) Subject: A bug in the Kernel? From: itkes@imec.msu.ru To: netdev@oss.sgi.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050412163141_77866" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itkes@imec.msu.ru Precedence: bulk X-list: netdev Content-Length: 11411 Lines: 421 ------=_20050412163141_77866 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello. I think, I have found a bug in the Linux Kernel. It is caused by working with lists by indexes in such operstions as routing tables dump and routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump functions in fib_hash.c). If some elements are removed form the list, the index may identify not the element it identified earlier. As a result, there may happen that an application that requested the routes or rules dump, will not receive the entire table. There is how to make an application to lose some rules. 1. Add 150 rules to kernel table. 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The kernel puts first 107 rules to the buffer. 3. Application B deletes first 20 rules. 4. Application A receives the first couple of data from kernel. The kernel puts next couple of rules to the buffer, begining from 108-th rule, that was 128-th earlier. As a result, 20 rules had not been sent to the application, without being deleted or modified during the dump operation. Routes can be lost, too, if you add certain 5000 routes, request their dump and remove 1000 from them during the dump. In the patch (against kernel 2.6.11) attached, I have corrected these bugs. In the modified kernel, both dumps of routes and routing rules seems to work properly. But, I think, there can be other bugs similar to this in other dump operations. Alex Itkes (Moscow State University). P.S. I am awfully sorry if you got this message more then once. There were some problems with my mailbox so my previous message or your answer might be lost. ------=_20050412163141_77866 Content-Type: text/plain; name="patch-2.6.11-nl01" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="patch-2.6.11-nl01" diff -urN linux-2.6.11/include/linux/netlink.h linux-2.6.11-nl01/include/linux/netlink.h --- linux-2.6.11/include/linux/netlink.h 2005-03-02 23:04:19.000000000 +0300 +++ linux-2.6.11-nl01/include/linux/netlink.h 2005-03-08 15:03:11.000000000 +0300 @@ -145,9 +145,11 @@ int (*dump)(struct sk_buff * skb, struct netlink_callback *cb); int (*done)(struct netlink_callback *cb); int family; - long args[4]; + long args[5]; }; +#define NLCB_ZERO(cb_,k_) memset((cb_)->args+(k_),0,sizeof((cb_)->args)-(k_)*sizeof((cb_)->args[0])) + struct netlink_notify { int pid; diff -urN linux-2.6.11/net/core/rtnetlink.c linux-2.6.11-nl01/net/core/rtnetlink.c --- linux-2.6.11/net/core/rtnetlink.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/core/rtnetlink.c 2005-03-08 17:27:28.000000000 +0300 @@ -425,7 +425,7 @@ rtnetlink_links[idx][type].dumpit == NULL) continue; if (idx > s_idx) - memset(&cb->args[0], 0, sizeof(cb->args)); + NLCB_ZERO(cb,0); if (rtnetlink_links[idx][type].dumpit(skb, cb)) break; } diff -urN linux-2.6.11/net/ipv4/fib_frontend.c linux-2.6.11-nl01/net/ipv4/fib_frontend.c --- linux-2.6.11/net/ipv4/fib_frontend.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_frontend.c 2005-03-08 17:33:40.000000000 +0300 @@ -347,7 +347,7 @@ for (t=s_t; t<=RT_TABLE_MAX; t++) { if (t < s_t) continue; if (t > s_t) - memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); + NLCB_ZERO(cb,1); if ((tb = fib_get_table(t))==NULL) continue; if (tb->tb_dump(tb, skb, cb) < 0) diff -urN linux-2.6.11/net/ipv4/fib_hash.c linux-2.6.11-nl01/net/ipv4/fib_hash.c --- linux-2.6.11/net/ipv4/fib_hash.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_hash.c 2005-03-08 17:37:28.000000000 +0300 @@ -52,6 +52,9 @@ struct hlist_node fn_hash; struct list_head fn_alias; u32 fn_key; + + u32 fn_nl_links; + u8 fn_nl_dead; }; struct fn_zone { @@ -256,7 +259,7 @@ head = &fz->fz_hash[fn_hash(k, fz)]; hlist_for_each_entry(f, node, head, fn_hash) { - if (f->fn_key != k) + if (f->fn_key != k || f->fn_nl_dead) continue; err = fib_semantic_match(&f->fn_alias, @@ -296,8 +299,14 @@ hlist_for_each_entry(f, node, &fz->fz_hash[0], fn_hash) { struct fib_alias *fa; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { struct fib_info *next_fi = fa->fa_info; + if (fa->fa_nl_dead){ + continue; + }; if (fa->fa_scope != res->scope || fa->fa_type != RTN_UNICAST) @@ -497,6 +506,8 @@ INIT_HLIST_NODE(&new_f->fn_hash); INIT_LIST_HEAD(&new_f->fn_alias); new_f->fn_key = key; + new_f->fn_nl_links=0; + new_f->fn_nl_dead=0; f = new_f; } @@ -506,6 +517,8 @@ new_fa->fa_scope = r->rtm_scope; new_fa->fa_state = 0; + new_fa->fa_nl_links=0; + new_fa->fa_nl_dead=0; /* * Insert new entry to the list. */ @@ -591,8 +604,17 @@ int kill_fn; fa = fa_to_delete; + if(fa->fa_nl_dead){ + tb->tb_flush(tb); + return -ESRCH; + }; rtmsg_fib(RTM_DELROUTE, key, fa, z, tb->tb_id, n, req); - + + if(fa->fa_nl_links){ + fa->fa_nl_dead=1; + tb->tb_flush(tb); + return 0; + }; kill_fn = 0; write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); @@ -630,7 +652,7 @@ list_for_each_entry_safe(fa, fa_node, &f->fn_alias, fa_list) { struct fib_info *fi = fa->fa_info; - if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + if ((fi && (fi->fib_flags&RTNH_F_DEAD))||(fa->fa_nl_dead&&(fa->fa_nl_links==0))) { write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); if (list_empty(&f->fn_alias)) { @@ -675,17 +697,42 @@ { struct hlist_node *node; struct fib_node *f; - int i, s_i; - - s_i = cb->args[3]; - i = 0; + int flag1=0; + int flag2=0; + + if(cb->args[3]==0){ + flag1=1; + }; hlist_for_each_entry(f, node, head, fn_hash) { struct fib_alias *fa; + if(flag1==0){ + if((long)(f)==cb->args[3]){ + --(f->fn_nl_links); + flag1=1; + }else{ + continue; + }; + }; + if(cb->args[4]==0){ + flag2=1; + }; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { - if (i < s_i) - goto next; + if(flag2==0){ + if((long)(fa)==cb->args[4]){ + --(fa->fa_nl_links); + flag2=1; + }else{ + continue; + }; + }; + if(fa->fa_nl_dead){ + continue; + }; if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, RTM_NEWROUTE, @@ -696,14 +743,16 @@ fz->fz_order, fa->fa_tos, fa->fa_info) < 0) { - cb->args[3] = i; + ++(fa->fa_nl_links); + ++(f->fn_nl_links); + cb->args[4]=(long)(fa); + cb->args[3]=(long)(f); return -1; } - next: - i++; } } - cb->args[3] = i; + cb->args[4]=0; + cb->args[3]=0; return skb->len; } @@ -718,8 +767,7 @@ for (h=0; h < fz->fz_divisor; h++) { if (h < s_h) continue; if (h > s_h) - memset(&cb->args[3], 0, - sizeof(cb->args) - 3*sizeof(cb->args[0])); + NLCB_ZERO(cb,3); if (fz->fz_hash == NULL || hlist_empty(&fz->fz_hash[h])) continue; @@ -734,25 +782,27 @@ static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) { - int m, s_m; struct fn_zone *fz; struct fn_hash *table = (struct fn_hash*)tb->tb_data; - s_m = cb->args[1]; read_lock(&fib_hash_lock); - for (fz = table->fn_zone_list, m=0; fz; fz = fz->fz_next, m++) { - if (m < s_m) continue; - if (m > s_m) - memset(&cb->args[2], 0, - sizeof(cb->args) - 2*sizeof(cb->args[0])); + if(cb->args[1]){ + fz=(struct fn_zone*)(cb->args[1]); + }else{ + fz=table->fn_zone_list; + }; + for (; fz; fz = fz->fz_next) { + if((long)(fz)!=cb->args[1]){ + NLCB_ZERO(cb,2); + }; if (fn_hash_dump_zone(skb, cb, tb, fz) < 0) { - cb->args[1] = m; + cb->args[1] = (long)(fz); read_unlock(&fib_hash_lock); return -1; } } read_unlock(&fib_hash_lock); - cb->args[1] = m; + cb->args[1] = 0; return skb->len; } diff -urN linux-2.6.11/net/ipv4/fib_lookup.h linux-2.6.11-nl01/net/ipv4/fib_lookup.h --- linux-2.6.11/net/ipv4/fib_lookup.h 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_lookup.h 2005-03-08 12:51:36.000000000 +0300 @@ -12,6 +12,9 @@ u8 fa_type; u8 fa_scope; u8 fa_state; + + u32 fa_nl_links; + u8 fa_nl_dead; }; #define FA_S_ACCESSED 0x01 diff -urN linux-2.6.11/net/ipv4/fib_rules.c linux-2.6.11-nl01/net/ipv4/fib_rules.c --- linux-2.6.11/net/ipv4/fib_rules.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_rules.c 2005-03-08 17:33:25.000000000 +0300 @@ -74,6 +74,9 @@ #endif char r_ifname[IFNAMSIZ]; int r_dead; + + u32 r_nl_links; + u8 r_nl_dead; }; static struct fib_rule default_rule = { @@ -101,6 +104,28 @@ static struct fib_rule *fib_rules = &local_rule; static DEFINE_RWLOCK(fib_rules_lock); +static void nl_rules_flush(void) +{ + struct fib_rule *r, **rp; + + for(rp=&fib_rules;(r=*rp)!=NULL;rp=&r->r_next){ + next:; + if(r->r_nl_dead&&(r->r_nl_links==0)){ + write_lock_bh(&fib_rules_lock); + *rp = r->r_next; + r->r_dead = 1; + write_unlock_bh(&fib_rules_lock); + fib_rule_put(r); + r=*rp; + if(r==0){ + return; + }else{ + goto next; + }; + }; + }; +} + int inet_rtm_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) { struct rtattr **rta = arg; @@ -121,10 +146,18 @@ (!rta[RTA_PRIORITY-1] || memcmp(RTA_DATA(rta[RTA_PRIORITY-1]), &r->r_preference, 4) == 0) && (!rta[RTA_IIF-1] || rtattr_strcmp(rta[RTA_IIF-1], r->r_ifname) == 0) && (!rtm->rtm_table || (r && rtm->rtm_table == r->r_table))) { + if(r->r_nl_dead==1){ + nl_rules_flush(); + break; + }; err = -EPERM; if (r == &local_rule) break; - + if(r->r_nl_links!=0){ + r->r_nl_dead=1; + nl_rules_flush(); + return 0; + }; write_lock_bh(&fib_rules_lock); *rp = r->r_next; r->r_dead = 1; @@ -198,6 +231,8 @@ new_r->r_srcmask = inet_make_mask(rtm->rtm_src_len); new_r->r_dstmask = inet_make_mask(rtm->rtm_dst_len); new_r->r_tos = rtm->rtm_tos; + new_r->r_nl_links=0; + new_r->r_nl_dead=0; #ifdef CONFIG_IP_ROUTE_FWMARK if (rta[RTA_PROTOINFO-1]) memcpy(&new_r->r_fwmark, RTA_DATA(rta[RTA_PROTOINFO-1]), 4); @@ -293,6 +328,9 @@ NIPQUAD(flp->fl4_dst), NIPQUAD(flp->fl4_src)); read_lock(&fib_rules_lock); for (r = fib_rules; r; r=r->r_next) { + if(r->r_nl_dead){ + continue; + }; if (((saddr^r->r_src) & r->r_srcmask) || ((daddr^r->r_dst) & r->r_dstmask) || (r->r_tos && r->r_tos != flp->fl4_tos) || @@ -414,19 +452,30 @@ int inet_dump_rules(struct sk_buff *skb, struct netlink_callback *cb) { - int idx; - int s_idx = cb->args[0]; struct fib_rule *r; - + + if(cb->args[0]==(-1)){ + return 0; + }; read_lock(&fib_rules_lock); - for (r=fib_rules, idx=0; r; r = r->r_next, idx++) { - if (idx < s_idx) - continue; - if (inet_fill_rule(skb, r, cb) < 0) - break; + if(cb->args[0]){ + r=(struct fib_rule*)(cb->args[0]); + --(r->r_nl_links); + }else{ + r=fib_rules; + }; + for (; r; r = r->r_next) { + if(r->r_nl_dead){ + continue; + }; + if (inet_fill_rule(skb, r, cb) < 0){ + ++(r->r_nl_links); + cb->args[0]=(long)(r); + return skb->len; + }; } + cb->args[0]=(-1); read_unlock(&fib_rules_lock); - cb->args[0] = idx; return skb->len; } ------=_20050412163141_77866-- From hadi@cyberus.ca Tue Apr 12 06:18:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 06:18:39 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CDIWPM011667 for ; Tue, 12 Apr 2005 06:18:32 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DLLHd-0008Mm-Ub for netdev@oss.sgi.com; Tue, 12 Apr 2005 07:18:25 -0600 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 1DLLHf-0000be-06; Tue, 12 Apr 2005 09:18:27 -0400 Subject: Re: A bug in the Kernel? From: jamal Reply-To: hadi@cyberus.ca To: itkes@imec.msu.ru Cc: netdev In-Reply-To: <3558.193.232.114.87.1113309101.squirrel@mx> References: <3558.193.232.114.87.1113309101.squirrel@mx> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113311902.1961.59.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Apr 2005 09:18:23 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1690 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: 2633 Lines: 61 Alex, I think i tried to respond to you before but the message may have not made it through. This is expected behavior i.e i wouldnt exactly call it a bug - rather it is a design tradeoff. You are correct, this behavior exists every where with netlink not just with policy routes. The only way you can protect app A from app B is to hold a lock until the operation is complete. Such a lock will protect against delete/add. But since this is expensive - i.e it will also stop traffic from running and will require some protection; it is by design therefore not implemented. In my opinion: In your solution, the dump state MUST reflect whats in the kernel not what was in the kernel when the dump started. Dont mean to discourage you - perhaps you can come up with some more clever ideas now that i explained this. I dont know what the best solution is; however, what you are doing is insuficient in my opinion. cheers, jamal On Tue, 2005-04-12 at 08:31, itkes@imec.msu.ru wrote: > Hello. > > I think, I have found a bug in the Linux Kernel. It is caused by working > with lists by indexes in such operstions as routing tables dump and > routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump > functions in fib_hash.c). If some elements are removed form the list, the > index may identify not the element it identified earlier. As a result, > there may happen that an application that requested the routes or rules > dump, will not receive the entire table. There is how > to make an application to lose some rules. > > 1. Add 150 rules to kernel table. > 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The > kernel puts first 107 rules to the buffer. > 3. Application B deletes first 20 rules. > 4. Application A receives the first couple of data from kernel. The kernel > puts next couple of rules to the buffer, begining from 108-th rule, that > was 128-th earlier. > As a result, 20 rules had not been sent to the application, without being > deleted or modified during the dump operation. > > Routes can be lost, too, if you add certain 5000 routes, request their > dump and remove 1000 from them during the dump. > > In the patch (against kernel 2.6.11) attached, I have corrected these > bugs. In the modified kernel, both dumps of routes and routing rules seems > to work properly. But, I think, there can be other bugs similar to this in > other dump operations. > > Alex Itkes (Moscow State University). > > P.S. I am awfully sorry if you got this message more then once. There were > some problems with my mailbox so my previous message or your answer might > be lost. From hadi@cyberus.ca Tue Apr 12 06:37:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 06:37:20 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CDbFiM014068 for ; Tue, 12 Apr 2005 06:37:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DLLZo-0008OH-Mn for netdev@oss.sgi.com; Tue, 12 Apr 2005 09:37:12 -0400 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 1DLLZk-0003JB-0u; Tue, 12 Apr 2005 09:37:08 -0400 Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* From: jamal Reply-To: hadi@cyberus.ca To: Masahide NAKAMURA Cc: Herbert Xu , "David S. Miller" , Patrick McHardy , netdev In-Reply-To: <425B8401.1010609@linux-ipv6.org> References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> <425A0F00.8070509@linux-ipv6.org> <1113218805.1089.357.camel@jzny.localdomain> <425B8401.1010609@linux-ipv6.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1113313023.1966.79.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Apr 2005 09:37:03 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1691 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: 607 Lines: 21 On Tue, 2005-04-12 at 04:17, Masahide NAKAMURA wrote: > short report: > My testing is not completed but, I've tested below and it is fine: > add/del/flush SP and their notifications through netlink (using modified iproute2/ip). > > new "xfrm_userpolicy_delete" works fine on this case; > used byid=1 when deleting SP with specifying SP index. > > I'll test the rest case (17 hours later): > - using pfkey > - using both sockets > I did basic testing with pfkey generated events (policy/state) showing up in both. The vice-versa also looks good. Herbert, try to push forward to Dave. cheers, jamal From imperishablealbeit@163.com Tue Apr 12 08:23:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 08:23:17 -0700 (PDT) Received: from 163.com (smtp.163.com [202.108.44.206]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3CFN4S3028078 for ; Tue, 12 Apr 2005 08:23:10 -0700 Message-Id: <200504121523.j3CFN4S3028078@oss.sgi.com> Received: from crc-liscs (unknown [219.223.233.156]) by smtp3 (Coremail) with SMTP id LIBfc8HnW0LMMfAE.1 for ; Tue, 12 Apr 2005 23:22:44 +0800 (CST) X-Originating-IP: [219.223.233.156] Date: Wed, 13 Apr 2005 23:22:35 -0800 From: "imperishablealbeit" Reply-To: imperishablealbeit@163.com To: "netdev" Subject: how to control the limited cpu resource for actions of transimiting packets from different interface? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imperishablealbeit@163.com Precedence: bulk X-list: netdev Content-Length: 1252 Lines: 18 hi,everyone, I meet a problem recently , the situation likes this: there are two net card in my laptop, one is wired eth0 and the other is wireless netcard named eth1 . Now I have wroten a script like NAT, that is , the packats from eth0 the forward to eth1, and the packets from eth1 also will be sent to eth0, so my laptop seems like a AP. What's more, there are two kinds of packets in the direction from etho to eth1, packet0 and packe1 alternatively. In order to meet the need of special requirement, packet0 must be sent with precedence over packet1, so at any time, the packet0 should be deal with first. How can I deal with it in kernel? I do not know if I can view the two actions, the one is transmiting packet0 from eth0 to eth1 and the other one is transmiting packet1 in the same direction, as two processes and schedule them with different priority ? if not , what I can arrvie at my aim in kernel? is there any way particular ?? In addition, given that the whole CPU resource is unchangeable, in linux kernel how it can get balance point among actions such as the two presented above and 'who' can control it, a Daemon or 'someone else'? I don't know how kernel works clearly and any help will be appreciated:) thanks !! From rl@hellgate.ch Tue Apr 12 08:28:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 08:28:47 -0700 (PDT) Received: from mail4.bluewin.ch ([195.186.4.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CFSatY028931 for ; Tue, 12 Apr 2005 08:28:37 -0700 Received: from k3.hellgate.ch (81.62.215.171) by mail4.bluewin.ch (Bluewin 7.0.043) id 423AECD700295298; Tue, 12 Apr 2005 15:28:10 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 0CFD996968; Tue, 12 Apr 2005 17:27:22 +0200 (CEST) Date: Tue, 12 Apr 2005 17:27:22 +0200 From: Roger Luethi To: Udo van den Heuvel Cc: netdev@oss.sgi.com Subject: Re: VIA Rhine ethernet driver bug Message-ID: <20050412152721.GB8897@k3.hellgate.ch> References: <000501c53da5$944b05d0$450aa8c0@hierzo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501c53da5$944b05d0$450aa8c0@hierzo> X-Operating-System: Linux 2.6.11 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 527 Lines: 11 On Sun, 10 Apr 2005 10:16:21 +0200, Udo van den Heuvel wrote: > Apr 8 18:51:08 epia kernel: eth1: Oversized Ethernet frame spanned multiple > buffers, entry 0x9 length 0 status 00000600! It's been a while since I looked into this, but here's what I remember: This is not supposed to happen. Because this is so peculiar, I talked it over with VIA, and they want to know whether their own driver makes any difference. I relayed that request to you, but I don't remember ever getting a report back. Did I miss something? Roger From rddunlap@osdl.org Tue Apr 12 11:41:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 11:42:01 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CIfs0g002212 for ; Tue, 12 Apr 2005 11:41:55 -0700 Received: from gargoyle.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3CIfms3023146 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 12 Apr 2005 11:41:48 -0700 Date: Tue, 12 Apr 2005 11:41:48 -0700 From: "Randy.Dunlap" To: netdev Subject: Fw: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) Message-Id: <20050412114148.66283c58.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: SvC&!/v_Hr`MvpQ*|}uez16KH[#EmO2Tn~(r-y+&Jb}?Zhn}c:Eee&zq`cMb_[5`tT(22ms (.P84,bq_GBdk@Kgplnrbj;Y`9IF`Q4;Iys|#3\?*[:ixU(UR.7qJT665DxUP%K}kC0j5,UI+"y-Sw mn?l6JGvyI^f~2sSJ8vd7s[/CDY]apD`a;s1Wf)K[,.|-yOLmBl0 To: linux-kernel@vger.kernel.org Subject: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) Hi, I'm affected by the (in)famous bug: Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) (Kernel of SuSE Linux 9.2, 2.6.8-24.13-default #1 Fri Mar 18 10:19:42 UTC 2005 i686 i686 i386 GNU/Linux) The kernel spits out hundreds to thousand messages per second, making klogd and syslogd quite busy, and my messages file stopped growing at 2GB. I'd suggest to enable throttling for this message, or trigger a panic/reboot, or maybe even fix the bug or message. ;-) Regards, Ulrich - From george@mvista.com Tue Apr 12 12:18:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 12:18:48 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CJIbVL003380 for ; Tue, 12 Apr 2005 12:18:43 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA10502; Tue, 12 Apr 2005 12:16:51 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by data.mvista.com (8.13.1/8.13.1) with ESMTP id j3CJEuUo026869; Tue, 12 Apr 2005 12:14:56 -0700 Message-ID: <425C1E30.5060405@mvista.com> Date: Tue, 12 Apr 2005 12:14:56 -0700 From: George Anzinger Reply-To: george@mvista.com Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Horms CC: =?ISO-8859-1?Q?J=F6rn_Engel?= , Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com, Mike Phillips , Philip Blundell , David Dillow , Paul Gortmaker , Mike McLagan , Arnaldo Carvalho de Melo , Jan-Pascal van Best , Andreas Mohr <100.30936@germany.net>, p2@ace.ulyssis.student.kuleuven.ac.be, Thomas Bogendoerfer , Daniele Venzano , Jay Schulist Subject: Re: [PATCH] Maintainers list update: linux-net -> netdev References: <20050412062027.GA1614@verge.net.au> In-Reply-To: <20050412062027.GA1614@verge.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: george@mvista.com Precedence: bulk X-list: netdev Content-Length: 1019 Lines: 40 Horms wrote: > On Sat, Apr 09, 2005 at 03:52:05PM +0200, Jörn Engel wrote: > >>On Fri, 8 April 2005 22:16:07 +0200, Pavel Machek wrote: >> >>>More importantly, it is still listed as "the list" for network >>>drivers... >>> >>>NETWORK DEVICE DRIVERS >>>P: Andrew Morton >>>M: akpm@osdl.org >>>P: Jeff Garzik >>>M: jgarzik@pobox.com >>>L: linux-net@vger.kernel.org >>>S: Maintained >> >>Maybe one of the two maintainers might want to change that? ;) > > > Use netdev as the mailing list contact instead of the mostly dead > linux-net list. > ~ > PHRAM MTD DRIVER > @@ -1795,7 +1795,7 @@ > POSIX CLOCKS and TIMERS > P: George Anzinger > M: george@mvista.com > -L: linux-net@vger.kernel.org > +L: netdev@oss.sgi.com > S: Supported > I don't really know about the rest of them, but I think this should be: L: linux-kernel@vger.kernel.org Least wise that is where I look... ~ -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ From mailinglists@unix-scripts.com Tue Apr 12 12:27:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 12:27:58 -0700 (PDT) Received: from jade.ndcservers.net (jade.ndcservers.net [204.10.37.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CJRp43007729 for ; Tue, 12 Apr 2005 12:27:52 -0700 Received: from ip68-111-70-41.oc.oc.cox.net ([68.111.70.41] helo=ndciwkst01) by jade.ndcservers.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.50) id 1DLR38-0005xQ-28 for netdev@oss.sgi.com; Tue, 12 Apr 2005 12:27:50 -0700 Message-ID: <027301c53f95$b72bdfb0$0201a8c0@ndciwkst01> From: "Shaun Reitan" To: X-Mailer: Microsoft Outlook Express 6.00.2741.2600 Subject: Kernel Panic - not syncing: Fatal Exception in interupt. Date: Tue, 12 Apr 2005 12:27:47 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jade.ndcservers.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - unix-scripts.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mailinglists@unix-scripts.com Precedence: bulk X-list: netdev Content-Length: 2148 Lines: 61 Here is my original post to the linux.kernel mailing lists regarding this problem.... -------------------------------[ORIGINAL POST]----------------- +Hardware Specs Dual Xeon 800FSB Intel Server Board 4GB ECC DDR 3ware 9500 Sata Raid Card 5x200 GB sata drives in a raid 10 Config (1 hot spare) Dual Nic +OS Specs CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch eth0 is 0.0.0.0 promisc and assigned to a bridge (br0) tuntap devices up ebtables is enabled and loaded with rules My problem is that every other week or so the machine crashes. It never dumps the error to the logs so all i have is a screen shot of the console. I have put some serious stress on this machine and have been unable to duplicate the problem (running 20 guest UML's half running va-ctcs and the other half compiling a 2.6 kernel). Below is a link to 2 screen shots i have (about 2 weeks apart). I started off using a 2.6.10 kernel when the problem started. Last time the machine crashed i built a 2.6.11.5 kernel and disabled APM and ACPI in the kernel config. Any body know whats going on here. http://www.unix-scripts.com/shaun/host-screenshot-1.png http://www.unix-scripts.com/shaun/host-screenshot-2.png Kernel Config... http://www.unix-scripts.com/shaun/2.6.11.5-hr1_.config ---------------------------------------------------------------------------- -------- Since then the machine has crashed 2 more times but this time the crashes where only a few hours appart. I changed the resolution on the console to 791 so i was able to catch alittle more of the dump. I enabled console serial redirection in the BIOS so i'm hopping i'm going to be able to catch a full dump the next time this happens. Here are a few more screen shots and the link to the kernel post i have going. The first screen shot is with the old resolution so didnt catch much more here... http://www.unix-scripts.com/shaun/host1-2005-04-12-01.png But this screen shot got a nice chunk and looks a bit diffrent. http://www.unix-scripts.com/shaun/host1-2005-04-12-02.png http://thread.gmane.org/gmane.linux.kernel/293810 Thanks in advance! Shaun Reitan From davem@davemloft.net Tue Apr 12 12:39:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 12:39:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CJd4XJ008474 for ; Tue, 12 Apr 2005 12:39:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DLRAQ-0004a6-00; Tue, 12 Apr 2005 12:35:22 -0700 Date: Tue, 12 Apr 2005 12:35:22 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com Subject: Re: Fw: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) Message-Id: <20050412123522.34bf4d14.davem@davemloft.net> In-Reply-To: <20050412114148.66283c58.rddunlap@osdl.org> References: <20050412114148.66283c58.rddunlap@osdl.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 120 Lines: 7 On Tue, 12 Apr 2005 11:41:48 -0700 "Randy.Dunlap" wrote: > > FYI. 2.6.8, he needs to upgrade :-) From bguo@bluesocket.com Tue Apr 12 12:45:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 12:45:45 -0700 (PDT) Received: from psmtp.com (exprod8og3.obsmtp.com [64.18.3.204]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3CJjcBq009190 for ; Tue, 12 Apr 2005 12:45:40 -0700 Received: from source ([66.10.55.2]) by exprod8ob3.obsmtp.com ([64.18.7.12]) with SMTP; Tue, 12 Apr 2005 12:42:18 PDT Received: from mail01.bluesocket.com ([192.168.168.97]) by mailfe.bluesocket.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Apr 2005 15:45:28 -0400 Received: from [9.9.9.238] ([9.9.9.238]) by mail01.bluesocket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Apr 2005 15:45:28 -0400 Subject: Question about connect and ipsec From: Bin Guo To: netdev@oss.sgi.com Content-Type: text/plain Organization: Bluesocket, Inc. Date: Tue, 12 Apr 2005 10:09:52 -0400 Message-Id: <1113314992.9028.18.camel@bguo.bluesocket.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 19:45:28.0412 (UTC) FILETIME=[2DB199C0:01C53F98] X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bguo@bluesocket.com Precedence: bulk X-list: netdev Content-Length: 1270 Lines: 37 Hi, I'm running 2.6.11 IPSec where the esp tunnel endpoint is the default gateway. During debugging, I found when there is no SA, plain arping would fail (my policy is require for any<->my-adress): setkey -F arping -I eth1 9.9.9.1 # default-gateway=9.9.9.1 connect: Resource temporarily unavailable #(racoon is trying to re-establish the tunnel here...) but if you give arping source address, it's ok: setkey -F arping -I eth1 -s 9.9.9.238 9.9.9.1 # my-address=9.9.9.238 ARPING 9.9.9.1 from 9.9.9.238 eth1 Unicast reply from 9.9.9.1 [00:02:B3:5E:9E:13] 47.350ms >From the source code of iputils/arping.c (and strace), when no source address is provided, arping will do something like the following to find proper local source address: int probe_fd = socket(AF_INET, SOCK_DGRAM); setsockopt(probe_fd, SOL_SOCKET, SO_BINDTODEVICE, ...); setsockopt(probe_fd, SOL_SOCKET, SO_DONTROUTE, &1, ...); connect(probe_fd, &dst, ...); getsockname(probe_fd, &src, ...); The connect call seems to map directly to net/ipv4/datagram.c: ip4_datagram_connect. Is it true that connect call on udp sockets result in SA creation and temporary failure? Is it by design just checking route to a destination protected ipsec will trigger SA creation? -- Bin From hidden@balabit.hu Tue Apr 12 13:19:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 13:19:08 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [213.46.255.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CKJ21F015164 for ; Tue, 12 Apr 2005 13:19:03 -0700 Received: from [192.168.1.99] (really [80.99.5.32]) by viefep15-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050412201853.SUEY4809.viefep15-int.chello.at@[192.168.1.99]>; Tue, 12 Apr 2005 22:18:53 +0200 Subject: Re: Fw: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) From: KOVACS Krisztian To: "Randy.Dunlap" Cc: netdev In-Reply-To: <20050412114148.66283c58.rddunlap@osdl.org> References: <20050412114148.66283c58.rddunlap@osdl.org> Content-Type: text/plain Date: Tue, 12 Apr 2005 22:18:50 +0200 Message-Id: <1113337130.3004.14.camel@krak.odu> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hidden@balabit.hu Precedence: bulk X-list: netdev Content-Length: 1221 Lines: 32 Hi, On Tue, 2005-04-12 at 11:41 -0700, Randy.Dunlap wrote: > I'm affected by the (in)famous bug: > Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 > Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags & MSG_PEEK) failed at > net/ipv4/tcp.c (1282) > Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 > Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags & MSG_PEEK) failed at > net/ipv4/tcp.c (1282) > > (Kernel of SuSE Linux 9.2, 2.6.8-24.13-default #1 Fri Mar 18 10:19:42 UTC 2005 > i686 i686 i386 GNU/Linux) > > The kernel spits out hundreds to thousand messages per second, making klogd and > syslogd quite busy, and my messages file stopped growing at 2GB. > > I'd suggest to enable throttling for this message, or trigger a panic/reboot, or > maybe even fix the bug or message. ;-) I also hit these assertions today. In my case it was probably because of a slab corruption problem caused by the e100 driver. (I had CONFIG_DEBUG_SLAB enabled, so a lot of slab corruption messages appeared right before these assertion errors.) After applying e100-napi-fixes.patch from 2.6.11-mm4 the problem semms to be gone. -- Krisztian Kovacs From okir@suse.de Tue Apr 12 13:40:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 13:40:06 -0700 (PDT) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CKdxuP016038 for ; Tue, 12 Apr 2005 13:39:59 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 531AA160635A; Tue, 12 Apr 2005 22:39:53 +0200 (CEST) Date: Tue, 12 Apr 2005 22:39:50 +0200 From: Olaf Kirch To: KOVACS Krisztian Cc: "Randy.Dunlap" , netdev Subject: Re: Fw: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) Message-ID: <20050412203950.GA9964@suse.de> References: <20050412114148.66283c58.rddunlap@osdl.org> <1113337130.3004.14.camel@krak.odu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113337130.3004.14.camel@krak.odu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 789 Lines: 19 On Tue, Apr 12, 2005 at 10:18:50PM +0200, KOVACS Krisztian wrote: > I also hit these assertions today. In my case it was probably because > of a slab corruption problem caused by the e100 driver. (I had > CONFIG_DEBUG_SLAB enabled, so a lot of slab corruption messages appeared > right before these assertion errors.) Yes, we've seen these symptoms in various bug reports in various 2.6 versions, and after some debugging narrowed it down to an e100 driver issue. It went away with 2.6.11 final. > After applying e100-napi-fixes.patch from 2.6.11-mm4 the problem semms > to be gone. Ah, I'll look into that one. Thanks for the pointer! Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From shemminger@osdl.org Tue Apr 12 14:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 14:35:55 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CLZn8J017390 for ; Tue, 12 Apr 2005 14:35:49 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3CLZgs4006198 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Apr 2005 14:35:42 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j3CLZftq011479; Tue, 12 Apr 2005 14:35:42 -0700 Date: Tue, 12 Apr 2005 14:35:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, netem@lists.osdl.org Subject: [PATCH] netem: change packet scheduling Message-ID: <20050412143541.260fdff4@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1701 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: 5365 Lines: 200 Netem was dumping packets into the child qdisc when timer expires. This creates problems if netem is not the root qdisc and can even cause a livelock situation. This patch changes it to only transfer packets during the enqueue/dequeue routines. This alternative makes netem be self clocking as well, so if using the CPU counter for the timing source it is possible to get smoother (non bursty) throughput. It also corrects the bug where a delay of 0 would always cause a delay of 1 tick. Signed-off-by: Stephen Hemminger --- linux-2.6.12-rc2/net/sched/sch_netem.c 2005-04-04 09:39:41.000000000 -0700 +++ netem/net/sched/sch_netem.c 2005-04-06 15:54:09.514780384 -0700 @@ -138,38 +138,78 @@ } /* Put skb in the private delayed queue. */ -static int delay_skb(struct Qdisc *sch, struct sk_buff *skb) +static int netem_delay(struct Qdisc *sch, struct sk_buff *skb) { struct netem_sched_data *q = qdisc_priv(sch); - struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; psched_tdiff_t td; psched_time_t now; PSCHED_GET_TIME(now); td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - PSCHED_TADD2(now, td, cb->time_to_send); /* Always queue at tail to keep packets in order */ if (likely(q->delayed.qlen < q->limit)) { + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + PSCHED_TADD2(now, td, cb->time_to_send); + + pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, + now, cb->time_to_send); + __skb_queue_tail(&q->delayed, skb); - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); - add_timer(&q->timer); - } return NET_XMIT_SUCCESS; } + pr_debug("netem_delay: queue over limit %d\n", q->limit); + sch->qstats.overlimits++; kfree_skb(skb); return NET_XMIT_DROP; } +/* + * Move a packet that is ready to send from the delay holding + * list to the underlying qdisc. + */ +static int netem_run(struct Qdisc *sch) +{ + struct netem_sched_data *q = qdisc_priv(sch); + struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + + skb = skb_peek(&q->delayed); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + return 1; + } + + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) { + sch->q.qlen--; + sch->qstats.drops++; + } + } + + return 0; +} + static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb2; int ret; - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + pr_debug("netem_enqueue skb=%p\n", skb); /* Random packet drop 0 => none, ~0 => all */ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { @@ -184,7 +224,7 @@ && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { pr_debug("netem_enqueue: dup %p\n", skb2); - if (delay_skb(sch, skb2)) { + if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -202,7 +242,8 @@ ret = q->qdisc->enqueue(skb, q->qdisc); } else { q->counter = 0; - ret = delay_skb(sch, skb); + ret = netem_delay(sch, skb); + netem_run(sch); } if (likely(ret == NET_XMIT_SUCCESS)) { @@ -241,56 +282,35 @@ return len; } -/* Dequeue packet. - * Move all packets that are ready to send from the delay holding - * list to the underlying qdisc, then just call dequeue - */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; + int pending; + + pending = netem_run(sch); skb = q->qdisc->dequeue(q->qdisc); - if (skb) + if (skb) { + pr_debug("netem_dequeue: return skb=%p\n", skb); sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + } + else if (pending) { + pr_debug("netem_dequeue: throttling\n"); + sch->flags |= TCQ_F_THROTTLED; + } + return skb; } static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - struct netem_sched_data *q = qdisc_priv(sch); - struct net_device *dev = sch->dev; - struct sk_buff *skb; - psched_time_t now; - pr_debug("netem_watchdog: fired @%lu\n", jiffies); - - spin_lock_bh(&dev->queue_lock); - PSCHED_GET_TIME(now); - - while ((skb = skb_peek(&q->delayed)) != NULL) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_watchdog: skb %p@%lu %ld\n", - skb, jiffies, delay); - - /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - break; - } - __skb_unlink(skb, &q->delayed); - - if (q->qdisc->enqueue(skb, q->qdisc)) { - sch->q.qlen--; - sch->qstats.drops++; - } - } - qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); } static void netem_reset(struct Qdisc *sch) @@ -301,6 +321,7 @@ skb_queue_purge(&q->delayed); sch->q.qlen = 0; + sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); } From baruch@ev-en.org Tue Apr 12 15:18:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 15:18:53 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CMIkH0018838 for ; Tue, 12 Apr 2005 15:18:48 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 1FC1711A5D1; Wed, 13 Apr 2005 01:18:40 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 70AE511A5CE; Wed, 13 Apr 2005 01:18:36 +0300 (IDT) Message-ID: <425C493B.5040206@ev-en.org> Date: Tue, 12 Apr 2005 23:18:35 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: "David S. Miller" , Stephen Hemminger Subject: TCP performance drop 2.6.6->2.6.7 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 659 Lines: 19 Hello, I'm trying to port my H-TCP and SACK improvements to 2.6.11, but I seem to hit performance problems that are unrelated to what I worked on so far. My tests show that between 2.6.6 and 2.6.7 the TCP performance dropped considerably. The setup for the tests, vanilla kernels, dummynet with 100 Mbit/s and 40ms rtt using the BIC protocol. No patches applied whatsoever. iperf tests for 2.6.6 get about 90Mbit/s while 2.6.7 gets 30Mbit/s. I was wondering if someone can think of a reason why this happens? Is there a way to get the different network related patches between these two versions? I don't have access to bk to get it myself. Baruch From davem@davemloft.net Tue Apr 12 15:51:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 15:51:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CMpF9G019774 for ; Tue, 12 Apr 2005 15:51:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DLUAL-0005gI-00; Tue, 12 Apr 2005 15:47:29 -0700 Date: Tue, 12 Apr 2005 15:47:28 -0700 From: "David S. Miller" To: Baruch Even Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: TCP performance drop 2.6.6->2.6.7 Message-Id: <20050412154728.463e3d10.davem@davemloft.net> In-Reply-To: <425C493B.5040206@ev-en.org> References: <425C493B.5040206@ev-en.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 449 Lines: 13 On Tue, 12 Apr 2005 23:18:35 +0100 Baruch Even wrote: > I was wondering if someone can think of a reason why this happens? Probably some bug we fixed in 2.6.8 or later... > Is there a way to get the different network related patches between > these two versions? I don't have access to bk to get it myself. Get patch-2.6.7.bz2 or whatever from kernel.org, then scan around for changes to include/*/tcp.h and net/ipv4/tcp*.c From shemminger@osdl.org Tue Apr 12 16:08:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 16:08:10 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CN82QD020832 for ; Tue, 12 Apr 2005 16:08:03 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3CN7rs4014284 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Apr 2005 16:07:53 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j3CN7qXR017834; Tue, 12 Apr 2005 16:07:52 -0700 Date: Tue, 12 Apr 2005 16:07:52 -0700 From: Stephen Hemminger To: Baruch Even Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: TCP performance drop 2.6.6->2.6.7 Message-ID: <20050412160752.46c82f0c@dxpl.pdx.osdl.net> In-Reply-To: <425C493B.5040206@ev-en.org> References: <425C493B.5040206@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1704 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: 1099 Lines: 36 On Tue, 12 Apr 2005 23:18:35 +0100 Baruch Even wrote: > Hello, > > I'm trying to port my H-TCP and SACK improvements to 2.6.11, but I seem > to hit performance problems that are unrelated to what I worked on so far. > > My tests show that between 2.6.6 and 2.6.7 the TCP performance dropped > considerably. Remember 2.6.6 had the old hyper aggressive and over correcting version of BIC. > The setup for the tests, vanilla kernels, dummynet with 100 Mbit/s and > 40ms rtt using the BIC protocol. No patches applied whatsoever. > > iperf tests for 2.6.6 get about 90Mbit/s while 2.6.7 gets 30Mbit/s. Haven't measured old kernels recently. But haven't seen that with the newest stuff I tested last night. At 40ms delay with netem over 1G to 100M bridge. Reno 99.6 Vegas 61.6 BIC 97.8 Hstcp 99.4 Westwood 99.4 What are your sysctl settings. > I was wondering if someone can think of a reason why this happens? > > Is there a way to get the different network related patches between > these two versions? I don't have access to bk to get it myself. > > Baruch From benh@kernel.crashing.org Tue Apr 12 16:17:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 16:17:52 -0700 (PDT) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CNHmQ2021492 for ; Tue, 12 Apr 2005 16:17:48 -0700 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id j3CND9gJ005876; Tue, 12 Apr 2005 18:13:11 -0500 Subject: Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos From: Benjamin Herrenschmidt To: Dale Farnsworth Cc: Fabio Massimo Di Nitto , Andrew Morton , Jeff Garzik , netdev@oss.sgi.com, Linux Kernel list In-Reply-To: <20050412120813.GA22502@xyzzy> References: <1113289985.21548.66.camel@gaston> <20050412095522.GA20129@xyzzy> <425BA688.9010607@ubuntu.com> <20050412120813.GA22502@xyzzy> Content-Type: text/plain Date: Wed, 13 Apr 2005 09:16:12 +1000 Message-Id: <1113347772.21548.127.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: benh@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 475 Lines: 17 > > It is possible. I received an old patch from Sven Luther and bounced to > > Benjamin rediffed against 2.6.12rc2, but the bits ended to be exactly > > the same. > > > > PS feel free to claim credits on it. I don't want for sure take over > > your work :) > > No problem. It was Nicolas' and Sven's patch and Like Sven said > this one is trivial. Mainly, I wanted to mention the other 19 patches > I've sent that I hope get accepted soon. We hope that too :) Ben. From dlstevens@us.ibm.com Tue Apr 12 16:41:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 16:41:47 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CNfa88025890 for ; Tue, 12 Apr 2005 16:41:42 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CNfRLg142580 for ; Tue, 12 Apr 2005 19:41:27 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CNfRAF357236 for ; Tue, 12 Apr 2005 17:41:27 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CNfQiH025624 for ; Tue, 12 Apr 2005 17:41:26 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CNfQLK025614; Tue, 12 Apr 2005 17:41:26 -0600 To: davem@davemloft.com Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 12 Apr 2005 17:41:25 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/12/2005 17:41:26 Content-Type: multipart/mixed; boundary="=_mixed 0082220788256FE1_=" X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1706 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: 5258 Lines: 119 --=_mixed 0082220788256FE1_= Content-Type: text/plain; charset="US-ASCII" I was doing some testing with IPV6_CHECKSUM and started getting memory corruption (panic when the socket was closed). The bug originally manifested itself as a the "csum" pointer in rawv6_push_pending_frames() pointing beyond the end of the skb data and trashing skb_shinfo(skb) because it didn't handle the case where nr_frags was 1 (and it was being called with an skb like that...). After fixing that, I found that the reason nr_frags was nonzero was because a prior sendto(), which had an invalid offset (for testing) had returned an error but left the packet data in the socket buffer. Subsequent calls wouldn't fit in the existing skb, so they resulted in frag buffers and an invalid csum pointer. I don't know if it is possible, after the fix for the second problem, to get an skb with nonzero nr_frags in rawv6_push_pending_frames() (maybe with corking? or maybe via MSG_MORE?), but this patch includes support for non-linear skbs as well as the missing flush on error that caused the problem to begin with. in-line with mangled whitespace, and attached for applying. +-DLS --- linux-2.6.11.7/net/ipv6/raw.c 2005-04-07 11:57:32.000000000 -0700 +++ linux-2.6.11.7T1/net/ipv6/raw.c 2005-04-12 15:05:00.000000000 -0700 @@ -465,9 +465,28 @@ static int rawv6_push_pending_frames(str if ((skb = skb_peek(&sk->sk_write_queue)) == NULL) goto out; - if (rp->offset + 1 < len) - csum = (u16 *)(skb->h.raw + rp->offset); - else { + if (rp->offset + 1 < len) { + if (rp->offset < skb->tail - skb->h.raw - 1) { + csum = (u16 *)(skb->h.raw + rp->offset); + } else if (skb_shinfo(skb)->nr_frags) { + int offset = rp->offset; + int i; + + offset -= skb->tail - skb->h.raw -1; + for (i=0; inr_frags; ++i) { + if (offset < skb_shinfo(skb)->frags[i].size) + break; + offset -= skb_shinfo(skb)->frags[i].size; + } + csum = (u16 *) + (page_address(skb_shinfo(skb)->frags[i].page) + + skb_shinfo(skb)->frags[i].page_offset + offset); + } else { + /* "can't happen"; len already checked, but.. */ + err = -EINVAL; + goto out; + } + } else { err = -EINVAL; goto out; } @@ -771,8 +790,11 @@ back_from_confirm: if (err) ip6_flush_pending_frames(sk); - else if (!(msg->msg_flags & MSG_MORE)) + else if (!(msg->msg_flags & MSG_MORE)) { err = rawv6_push_pending_frames(sk, &fl, rp, len); + if (err) + ip6_flush_pending_frames(sk); + } } done: ip6_dst_store(sk, dst, --=_mixed 0082220788256FE1_= Content-Type: application/octet-stream; name="rawv6.patch" Content-Disposition: attachment; filename="rawv6.patch" Content-Transfer-Encoding: base64 LS0tIGxpbnV4LTIuNi4xMS43L25ldC9pcHY2L3Jhdy5jCTIwMDUtMDQtMDcgMTE6NTc6MzIuMDAw MDAwMDAwIC0wNzAwCisrKyBsaW51eC0yLjYuMTEuN1QxL25ldC9pcHY2L3Jhdy5jCTIwMDUtMDQt MTIgMTU6MDU6MDAuMDAwMDAwMDAwIC0wNzAwCkBAIC00NjUsOSArNDY1LDI4IEBAIHN0YXRpYyBp bnQgcmF3djZfcHVzaF9wZW5kaW5nX2ZyYW1lcyhzdHIKIAlpZiAoKHNrYiA9IHNrYl9wZWVrKCZz ay0+c2tfd3JpdGVfcXVldWUpKSA9PSBOVUxMKQogCQlnb3RvIG91dDsKIAotCWlmIChycC0+b2Zm c2V0ICsgMSA8IGxlbikKLQkJY3N1bSA9ICh1MTYgKikoc2tiLT5oLnJhdyArIHJwLT5vZmZzZXQp OwotCWVsc2UgeworCWlmIChycC0+b2Zmc2V0ICsgMSA8IGxlbikgeworCQlpZiAocnAtPm9mZnNl dCA8IHNrYi0+dGFpbCAtIHNrYi0+aC5yYXcgLSAxKSB7CisJCQljc3VtID0gKHUxNiAqKShza2It PmgucmF3ICsgcnAtPm9mZnNldCk7CisJCX0gZWxzZSBpZiAoc2tiX3NoaW5mbyhza2IpLT5ucl9m cmFncykgeworCQkJaW50IG9mZnNldCA9IHJwLT5vZmZzZXQ7CisJCQlpbnQgaTsKKworCQkJb2Zm c2V0IC09IHNrYi0+dGFpbCAtIHNrYi0+aC5yYXcgLTE7CisJCQlmb3IgKGk9MDsgaTxza2Jfc2hp bmZvKHNrYiktPm5yX2ZyYWdzOyArK2kpIHsKKwkJCQlpZiAob2Zmc2V0IDwgc2tiX3NoaW5mbyhz a2IpLT5mcmFnc1tpXS5zaXplKQorCQkJCQlicmVhazsKKwkJCQlvZmZzZXQgLT0gc2tiX3NoaW5m byhza2IpLT5mcmFnc1tpXS5zaXplOworCQkJfQorCQkJY3N1bSA9ICh1MTYgKikKKwkJCQkocGFn ZV9hZGRyZXNzKHNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV0ucGFnZSkgKworCQkJCXNrYl9zaGlu Zm8oc2tiKS0+ZnJhZ3NbaV0ucGFnZV9vZmZzZXQgKyBvZmZzZXQpOworCQl9IGVsc2UgeworCQkJ LyogImNhbid0IGhhcHBlbiI7IGxlbiBhbHJlYWR5IGNoZWNrZWQsIGJ1dC4uICovCisJCQllcnIg PSAtRUlOVkFMOworCQkJZ290byBvdXQ7CisJCX0KKwl9IGVsc2UgewogCQllcnIgPSAtRUlOVkFM OwogCQlnb3RvIG91dDsKIAl9CkBAIC03NzEsOCArNzkwLDExIEBAIGJhY2tfZnJvbV9jb25maXJt OgogCiAJCWlmIChlcnIpCiAJCQlpcDZfZmx1c2hfcGVuZGluZ19mcmFtZXMoc2spOwotCQllbHNl IGlmICghKG1zZy0+bXNnX2ZsYWdzICYgTVNHX01PUkUpKQorCQllbHNlIGlmICghKG1zZy0+bXNn X2ZsYWdzICYgTVNHX01PUkUpKSB7CiAJCQllcnIgPSByYXd2Nl9wdXNoX3BlbmRpbmdfZnJhbWVz KHNrLCAmZmwsIHJwLCBsZW4pOworCQkJaWYgKGVycikKKwkJCQlpcDZfZmx1c2hfcGVuZGluZ19m cmFtZXMoc2spOworCQl9CiAJfQogZG9uZToKIAlpcDZfZHN0X3N0b3JlKHNrLCBkc3QsCg== --=_mixed 0082220788256FE1_=-- From baruch@ev-en.org Tue Apr 12 16:59:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 16:59:44 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CNxcqB026940 for ; Tue, 12 Apr 2005 16:59:39 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 2F9C611A5D1; Wed, 13 Apr 2005 02:59:33 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 125F911A5CE; Wed, 13 Apr 2005 02:59:27 +0300 (IDT) Message-ID: <425C60DD.5090007@ev-en.org> Date: Wed, 13 Apr 2005 00:59:25 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: TCP performance drop 2.6.6->2.6.7 References: <425C493B.5040206@ev-en.org> <20050412160752.46c82f0c@dxpl.pdx.osdl.net> In-Reply-To: <20050412160752.46c82f0c@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------090709020305080106070102" X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2504 Lines: 109 This is a multi-part message in MIME format. --------------090709020305080106070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Hemminger wrote: > On Tue, 12 Apr 2005 23:18:35 +0100 > Baruch Even wrote: >>The setup for the tests, vanilla kernels, dummynet with 100 Mbit/s and >>40ms rtt using the BIC protocol. No patches applied whatsoever. >> >>iperf tests for 2.6.6 get about 90Mbit/s while 2.6.7 gets 30Mbit/s. > > > Haven't measured old kernels recently. But haven't seen that with the > newest stuff I tested last night. At 40ms delay with netem > over 1G to 100M bridge. > Reno 99.6 > Vegas 61.6 > BIC 97.8 > Hstcp 99.4 > Westwood 99.4 I've now tested 2.6.11.7 and I get about 50Mbit/s, it starts at about 100 and drops to about 45. Tested for about a minute but it didn't show signs of recovery. > What are your sysctl settings. Attached. Baruch --------------090709020305080106070102 Content-Type: text/plain; name="sysctls" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sysctls" icmp_echo_ignore_all 0 icmp_echo_ignore_broadcasts 0 icmp_ignore_bogus_error_responses 0 icmp_ratelimit 1000 icmp_ratemask 6168 igmp_max_memberships 20 igmp_max_msf 10 inet_peer_gc_maxtime 120 inet_peer_gc_mintime 10 inet_peer_maxttl 600 inet_peer_minttl 120 inet_peer_threshold 65664 ip_autoconfig 0 ip_default_ttl 64 ip_dynaddr 0 ip_forward 0 ip_local_port_range 32768 61000 ip_no_pmtu_disc 0 ip_nonlocal_bind 0 ipfrag_high_thresh 262144 ipfrag_low_thresh 196608 ipfrag_secret_interval 600 ipfrag_time 30 tcp_abort_on_overflow 0 tcp_adv_win_scale 2 tcp_app_win 31 tcp_bic 1 tcp_bic_beta 819 tcp_bic_fast_convergence 1 tcp_bic_low_window 14 tcp_dsack 1 tcp_ecn 0 tcp_fack 1 tcp_fin_timeout 60 tcp_frto 0 tcp_keepalive_intvl 75 tcp_keepalive_probes 9 tcp_keepalive_time 7200 tcp_low_latency 0 tcp_max_orphans 8192 tcp_max_syn_backlog 1024 tcp_max_tw_buckets 180000 tcp_mem 8388608 8388608 8388608 tcp_moderate_rcvbuf 1 tcp_no_metrics_save 0 tcp_orphan_retries 0 tcp_reordering 3 tcp_retrans_collapse 1 tcp_retries1 3 tcp_retries2 15 tcp_rfc1337 0 tcp_rmem 4096 87380 8388608 tcp_sack 1 tcp_stdurg 0 tcp_syn_retries 5 tcp_synack_retries 5 tcp_timestamps 1 tcp_tso_win_divisor 8 tcp_tw_recycle 0 tcp_tw_reuse 0 tcp_vegas_alpha 2 tcp_vegas_beta 6 tcp_vegas_cong_avoid 0 tcp_vegas_gamma 2 tcp_westwood 0 tcp_window_scaling 1 tcp_wmem 4096 87380 8388608 --------------090709020305080106070102-- From yoshfuji@linux-ipv6.org Tue Apr 12 17:50:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 17:51:08 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D0otQk029798 for ; Tue, 12 Apr 2005 17:50:56 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 2610733CC2; Wed, 13 Apr 2005 09:53:10 +0900 (JST) Date: Wed, 13 Apr 2005 09:53:08 +0900 (JST) Message-Id: <20050413.095308.124546011.yoshfuji@linux-ipv6.org> To: dlstevens@us.ibm.com, davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel 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: 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-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1708 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: 1545 Lines: 51 In article (at Tue, 12 Apr 2005 17:41:25 -0600), David Stevens says: > I don't know if it is possible, after the fix for the second problem, to > get an > skb with nonzero nr_frags in rawv6_push_pending_frames() (maybe with > corking? or maybe via MSG_MORE?), but this patch includes support for > non-linear skbs as well as the missing flush on error that caused the > problem > to begin with. Please geive up the "singed-off" line. Anyway, how about this? Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/raw.c 1.80 vs edited ===== --- 1.80/net/ipv6/raw.c 2005-03-27 08:04:35 +09:00 +++ edited/net/ipv6/raw.c 2005-04-13 09:49:37 +09:00 @@ -456,7 +456,7 @@ { struct sk_buff *skb; int err = 0; - u16 *csum; + u16 csum_buff, *csum; u32 tmp_csum; if (!rp->checksum) @@ -465,12 +465,13 @@ if ((skb = skb_peek(&sk->sk_write_queue)) == NULL) goto out; - if (rp->offset + 1 < len) - csum = (u16 *)(skb->h.raw + rp->offset); - else { - err = -EINVAL; + err = -EINVAL; + if (rp->offset + 1 >= len) + goto out; + + csum = skb_header_pointer(skb, skb->h.raw - skb->data + rp->offset, sizeof(csum_buff), &csum_buff); + if (!csum) goto out; - } /* should be check HW csum miyazawa */ if (skb_queue_len(&sk->sk_write_queue) == 1) { -- Hideaki YOSHIFUJI @ USAGI Project Homepage: http://www.yoshifuji.org/~hideaki/ GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From horms@koto.vergenet.net Tue Apr 12 19:27:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 19:27:30 -0700 (PDT) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D2RKh0000468 for ; Tue, 12 Apr 2005 19:27:22 -0700 Received: by koto.vergenet.net (Postfix, from userid 7100) id D28E534028; Wed, 13 Apr 2005 11:02:47 +0900 (JST) Date: Wed, 13 Apr 2005 11:14:02 +0900 From: Horms To: George Anzinger Cc: =?iso-8859-1?Q?J=F6rn?= Engel , Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Maintainers list update: linux-net -> netdev Message-ID: <20050413021400.GA1835@verge.net.au> Mail-Followup-To: George Anzinger , =?iso-8859-1?Q?J=F6rn?= Engel , Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com References: <20050412062027.GA1614@verge.net.au> <425C1E30.5060405@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425C1E30.5060405@mvista.com> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev Content-Length: 1184 Lines: 45 On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote: > Horms wrote: > > > >Use netdev as the mailing list contact instead of the mostly dead > >linux-net list. > > > ~ > > PHRAM MTD DRIVER > >@@ -1795,7 +1795,7 @@ > > POSIX CLOCKS and TIMERS > > P: George Anzinger > > M: george@mvista.com > >-L: linux-net@vger.kernel.org > >+L: netdev@oss.sgi.com > > S: Supported > > > I don't really know about the rest of them, but I think this should be: > L: linux-kernel@vger.kernel.org > > Least wise that is where I look... Yes, I was wondering about that one. Here is a patch that adds to my previous patch. Trivial to say the least. I can re-diff the whole thing if that is more convenient. -- Horms POSIX CLOCKS and TIMERS disscussion is more appropriate on linux-kernel than linux-net. As suggested by the maintainer, George Anzinger. Signed-off-by: Horms --- a/MAINTAINERS 2005-04-13 11:06:39.000000000 +0900 +++ b/MAINTAINERS 2005-04-13 11:07:04.000000000 +0900 @@ -1795,7 +1795,7 @@ POSIX CLOCKS and TIMERS P: George Anzinger M: george@mvista.com -L: linux-net@vger.kernel.org +L: linux-kernel@vger.kernel.org S: Supported PNP SUPPORT From dlstevens@us.ibm.com Tue Apr 12 19:45:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 19:46:00 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D2jhls001258 for ; Tue, 12 Apr 2005 19:45:50 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3D2jcua260096 for ; Tue, 12 Apr 2005 22:45:38 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3D2jb7V253554 for ; Tue, 12 Apr 2005 20:45:37 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3D2jbHf023638 for ; Tue, 12 Apr 2005 20:45:37 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3D2jboo023633; Tue, 12 Apr 2005 20:45:37 -0600 In-Reply-To: <20050413.095308.124546011.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 12 Apr 2005 19:45:34 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/12/2005 20:45:36, Serialize complete at 04/12/2005 20:45:36 Content-Type: text/plain; charset="ISO-2022-JP" X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1710 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: 2114 Lines: 68 YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote on 04/12/2005 05:53:08 PM: > Please geive up the "singed-off" line. > Signed-off-by: Hideaki YOSHIFUJI Signed-off-by: David L Stevens :-) > Anyway, how about this? csum has to be a pointer into the packet data, so it can store the checksum it computes for the outgoing packet at that (user-provided) offset. It looks like skb_header_pointer gives a copy of the existing value, pointing to csum_buff, which wouldn't modify the packet value, right? So, I don't think that'll work. Something that would follow the skbuffs to that offset would be good, rather than doing it in-line, but I don't know of an existing function that does that (looked briefly, without success). If there is one, or it'd be used more than once, then "skb_offset_pointer" or some such that does the skb & nr_frags loop could be used here, as long as the end result is a pointer to the packet data and not, unless I'm wrong, a pointer to a copy of the packet data in a different buffer. +-DLS > ===== net/ipv6/raw.c 1.80 vs edited ===== > --- 1.80/net/ipv6/raw.c 2005-03-27 08:04:35 +09:00 > +++ edited/net/ipv6/raw.c 2005-04-13 09:49:37 +09:00 > @@ -456,7 +456,7 @@ > { > struct sk_buff *skb; > int err = 0; > - u16 *csum; > + u16 csum_buff, *csum; > u32 tmp_csum; > if (!rp->checksum) > @@ -465,12 +465,13 @@ > if ((skb = skb_peek(&sk->sk_write_queue)) == NULL) > goto out; > > - if (rp->offset + 1 < len) > - csum = (u16 *)(skb->h.raw + rp->offset); > - else { > - err = -EINVAL; > + err = -EINVAL; > + if (rp->offset + 1 >= len) > + goto out; > + > + csum = skb_header_pointer(skb, skb->h.raw - skb->data + rp->offset, > sizeof(csum_buff), &csum_buff); > + if (!csum) > goto out; > - } > /* should be check HW csum miyazawa */ > if (skb_queue_len(&sk->sk_write_queue) == 1) { > > -- > Hideaki YOSHIFUJI @ USAGI Project > Homepage: http://www.yoshifuji.org/~hideaki/ > GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Tue Apr 12 20:52:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 20:52:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D3q742007992 for ; Tue, 12 Apr 2005 20:52:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DLYuq-00028c-00; Wed, 13 Apr 2005 13:51:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DLYtc-0002WL-00; Wed, 13 Apr 2005 13:50:32 +1000 From: Herbert Xu To: bguo@bluesocket.com (Bin Guo) Subject: Re: Question about connect and ipsec Cc: netdev@oss.sgi.com, kaber@trash.net Organization: Core In-Reply-To: <1113314992.9028.18.camel@bguo.bluesocket.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 13 Apr 2005 13:50:32 +1000 X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 701 Lines: 18 Bin Guo wrote: > > The connect call seems to map directly to net/ipv4/datagram.c: > ip4_datagram_connect. Is it true that connect call on udp sockets > result in SA creation and temporary failure? Is it by design just > checking route to a destination protected ipsec will trigger SA > creation? It is a deficiency in the current implementation. This problem will be solved along with others in the xfrm resolution stuff that Patrick McHardy is working on. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Tue Apr 12 21:03:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 21:03:30 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D43KWg008793 for ; Tue, 12 Apr 2005 21:03:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id DB05C33CC2; Wed, 13 Apr 2005 13:05:36 +0900 (JST) Date: Wed, 13 Apr 2005 13:05:35 +0900 (JST) Message-Id: <20050413.130535.121024536.yoshfuji@linux-ipv6.org> To: dlstevens@us.ibm.com, davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20050413.095308.124546011.yoshfuji@linux-ipv6.org> 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-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1712 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: 762 Lines: 17 In article (at Tue, 12 Apr 2005 19:45:34 -0700), David Stevens says: > csum has to be a pointer into the packet data, so it can store > the checksum it computes for the outgoing packet at that (user-provided) > offset. It looks like skb_header_pointer gives a copy of the > existing value, pointing to csum_buff, which wouldn't modify the > packet value, right? So, I don't think that'll work. Ok, understood. BTW, I remember that my first intention was that we restrict "checksum" should be placed within the first fragment. In this sense, rp->offset + 1 < len does not make sense to me, if there's more fragments. Anyway, please allow me some time... --yoshfuji From nakam@linux-ipv6.org Tue Apr 12 22:07:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 22:07:54 -0700 (PDT) Received: from mail206.noc.n-bone.net (mail2.noc.n-bone.net [138.243.50.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D57m2W010342 for ; Tue, 12 Apr 2005 22:07:49 -0700 Received: from [192.168.2.149] (polaris.linux-ipv6.org [203.178.140.10]) by mail206.noc.n-bone.net (NBONE-MTA) with ESMTP id 751C6F37; Wed, 13 Apr 2005 14:07:42 +0900 (JST) Message-ID: <425CA91D.1030506@linux-ipv6.org> Date: Wed, 13 Apr 2005 14:07:41 +0900 From: Masahide NAKAMURA User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca, Herbert Xu Cc: "David S. Miller" , Patrick McHardy , netdev Subject: Re: [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* References: <1112702604.1089.119.camel@jzny.localdomain> <20050409105452.GA7171@gondor.apana.org.au> <20050409111244.GB7171@gondor.apana.org.au> <20050409111551.GA7378@gondor.apana.org.au> <20050410074849.GA13259@gondor.apana.org.au> <20050410090250.GA26022@gondor.apana.org.au> <1113142510.1091.294.camel@jzny.localdomain> <425A0F00.8070509@linux-ipv6.org> <1113218805.1089.357.camel@jzny.localdomain> <425B8401.1010609@linux-ipv6.org> <1113313023.1966.79.camel@jzny.localdomain> In-Reply-To: <1113313023.1966.79.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1223 Lines: 41 Hello Jamal and Herbert, jamal wrote: > On Tue, 2005-04-12 at 04:17, Masahide NAKAMURA wrote: > > >>short report: >>My testing is not completed but, I've tested below and it is fine: >> add/del/flush SP and their notifications through netlink (using modified iproute2/ip). >> >> new "xfrm_userpolicy_delete" works fine on this case; >> used byid=1 when deleting SP with specifying SP index. >> >>I'll test the rest case (17 hours later): >>- using pfkey >>- using both sockets >> > > > I did basic testing with pfkey generated events (policy/state) showing > up in both. The vice-versa also looks good. Thanks, Jamal. I'm sorry to be late, I've also tested pfkey, both sockets, and using racoon (on 2.6.12-rc2 + Jamal's patch + Herbert's 6 patches). # If somebody is interested in, modified iproute2 for the kernel can be found at: # http://www.linux-ipv6.org/~nakam/iproute2-xfrm-event/iproute2-xfrm-event-20050413.tar.gz # a patch against the latest iproute2 bk tree # http://www.linux-ipv6.org/~nakam/iproute2-xfrm-event/iproute2-xfrm-event-20050413.diff # This iproute2 change will be sent to Stephen after the kernel released. > Herbert, try to push forward to Dave. Agreed. Regards, -- Masahide NAKAMURA From dlstevens@us.ibm.com Tue Apr 12 22:07:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 22:07:24 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D57GfL010286; Tue, 12 Apr 2005 22:07:16 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3D57Aua314476; Wed, 13 Apr 2005 01:07:10 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3D57A7V246022; Tue, 12 Apr 2005 23:07:10 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3D579gk017733; Tue, 12 Apr 2005 23:07:09 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3D579Bn017728; Tue, 12 Apr 2005 23:07:09 -0600 In-Reply-To: <20050413.130535.121024536.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@davemloft.net, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Tue, 12 Apr 2005 22:07:06 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/12/2005 23:07:09, Serialize complete at 04/12/2005 23:07:09 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1713 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: 1721 Lines: 35 netdev-bounce@oss.sgi.com wrote on 04/12/2005 09:05:35 PM: > In article com> (at Tue, 12 Apr 2005 19:45:34 -0700), David Stevens says: > BTW, I remember that my first intention was that we restrict "checksum" > should be placed within the first fragment. > In this sense, rp->offset + 1 < len does not make sense to me, > if there's more fragments. These aren't fragments in the packet sense, of course. These are just different buffers. The packet on the wire in my test case was 66 bytes on an Ethernet (and checksum offset of 20). POSIX has no restriction on what the offset is (other than being in the packet), and it's not clear to me you can determine easily what boundaries sendmsg chooses for allocating the kernel buffers, if there is any legitimate case where the nr_frags is nonzero, since it writes as much of the data as it can in the existing skb before allocating the new memory fragments. So, if nr_frags can ever be nonzero, I think IPV6_CHECKSUM has to support it. Flushing the pending packets on error fixes the panic by itself, so the nr_frags==0 case should work with only that portion of the patch. Ordinary sendmsgs will work without corrupting memory with that fix, as long as MSG_MORE, corking, or any other methods cannot result in the checksum offset being in a memory fragment when nr_frags != 0. I don't know if that can happen in other cases or not, but it sendmsg certainly supports allocating new nr_frags. It was easy to fix and nr_frags != 0 can corrupt memory with even small packets, which is why I left that in the patch. +-DLS From lark@linux.net.cn Tue Apr 12 22:45:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Apr 2005 22:45:50 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D5jZIw011979 for ; Tue, 12 Apr 2005 22:45:40 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 0A8DB3F76A; Wed, 13 Apr 2005 13:45:31 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 25025-03; Wed, 13 Apr 2005 13:45:25 +0800 (CST) Received: from [192.168.0.120] (unknown [61.48.105.43]) by mx.linux.net.cn (Postfix) with ESMTP id 7B6273F769; Wed, 13 Apr 2005 13:45:25 +0800 (CST) Date: Wed, 13 Apr 2005 13:45:25 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Cc: netdev In-Reply-To: <1112964208.1088.226.camel@jzny.localdomain> References: <20050407203631.02CF.LARK@linux.net.cn> <1112964208.1088.226.camel@jzny.localdomain> Message-Id: <20050413131916.030F.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3D5jZIw011979 X-archive-position: 1715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 6569 Lines: 186 Hi jamal, Sorry for the late reply. I am occupied by other things and just have time back to this topic. On 08 Apr 2005 08:43:28 -0400, jamal wrote: > On Thu, 2005-04-07 at 09:14, Wang Jian wrote: > > > 1. a flow (in my perflow queue implementation) is a tuple of five > > elements, but, for some reason, if the users misused this queue and send > > non-flow packet, e.g. ICMP packet here; > > > > 2. a queue is configured to handle 100 flows, but the 101st flow comes; > > > > For this two situations, currently, the implementation just drops > > packets. However, a clean way is to reclassify the packet into another > > class (default) and provides no per flow guarantee. > > > > The reclassification or #1 will best be left to the user. This is not > hard to do. I scan through other code and find no easy way to redirect non-handled traffic to another class. Can you give me some hint on that? > > Ok, stop calling it per-flow-queue then ;-> You should call it > per-flow-rate-guarantee. I have renamed it to frg (flow rate guarantee) per your suggestion. After the above reclassification is done, I will post new patch here. I will extend the concept of flow to include GRE, so pptp VPN can be supported. There are other 'flows' to consider. > > As I already said, this approach has drawbacks > > > > 1. when flow count overlimit, no guarantee > > 2. when flow count is underlimit, the guaranteed sum bandwidth can be > > exploited to waste bandwidth. > > > > So, thinking of per flow queue, it is "queue which can provide bandwidth > > assurance and constraint per flow", and with only one queue! > > > > Sharing is not a big challenge - and should be policy driven. > HTB and CBQ both support it. I am not sure about HFSC. > Still, I am not clear if you understand me. How it works for this purpose: guarantee and only guarantee rate * n when there are n flows? When there only 1 flow, guarantee only rate * 1 When there only 2 flows, guarantee only rate * 2 ... and so on If always guarantee rate * limit, then the excessive guaranteed rate can be abused. But if always guarantee only rate * 1, then it is not enough. > > > You only need to create one HTB, one filter and one per flow queue for > > VoIP; and one HTB, one filter and one per flow queue for VPN. > > > > I think the "per flow" name does confuse you ;) My fault. > > The "queue" part is confusing - the "perflow" is fine. Lets stick with > per-flow-rate-guarantee as the description. > > So it seems you want by all means to avoid entering something that > will take forever to list. Did i understand this correctly? Yes. It is special purpose but general enough. I think it's worthy of adding a new qdisc for it to avoid the dirty long listing part. > > We can probably avoid insisting on dynamically creating classes maybe. > You can rate control before you enqueue and we can use fwmark perhaps. > Earlier i also asked whether policing will suffice. Heres an example > (maybe dated syntax, but concept still valid) that shows sharing using > policers: > http://www.cyberus.ca/~hadi/patches/action/README I will look at it later. > look at the example where it says "--cut here --" > > The only difference in this case is instead of creating 1000 classes > you create 1000 policers as a result of the hash. > Something along: > > u32 classify for port 80 prio high \ > action dymfwmark create range min 1 max 1000 \ > action police to some rate if result is drop we stop here \ > else continue \ > fwmark classify prio low\ > select one of two queues (high prio or low prio Q) > > Very small script but still doesnt avoid the "seeing 1000 things". In > this case if you list actions you see 1000. > The lockings in this case are more bearable than having the dynamic > marker creating queues. > Typically the actions in a topology graph are stiched together at policy > init time for efficiency reasons - so we dont have to do lookups at > runtime. In this case it will need to have static lookup instead because > depending on what the hash selects you want to select a different > policer instance. I think i know an easy way of doing this (example > storing per hash policer pointer in the dynmark table and doing the > invoke from within dynmark). > If we can do it with one thing, we should avoid creating 1000 things. The policy way works but is dirty. > > The problem occurs when you delete and add, and so on. It not good idea > > to reuse a used classid when there is stream classified as old. > > > > For example, you give class 1:1000 htb rate 200kbps ceil 200kbps for > > http, and you delete the class 1:1000 and redefine 1:1000 htb rate > > 30kbps ceil 30kbps for ftp. > > > > At this time, the remained http streams carries a CONNMARK and restore > > to MARK and then classified as 1:0000. Then 1:1000 is not what you want. > > > > I would think the number 1000 should be related to hash of flow header, > no? In which case there should be no collision unless the hash of ftp > and http are 1000. > To save netfilter rule matching work, if the CONNMARK is set, then it will be used to set nfmark. If a CONNMARK is already set on this http stream, it will be kept. Then if you redefine 1:1000 as another meaning, then this http carrying 1:1000 will be mis-classified. > > > > > > > > > > I am suprised no one has compared all the rate control schemes. > > > > > > > > > > btw, would policing also suffice for you? The only difference is it will > > > > > drop packets if you exceed your rate. You can also do hierachical > > > > > sharing. > > > > > > > > policy suffices, but doesn't serve the purpose of per flow queue. > > > > > > > > > > Policing will achieve the goal of rate control without worrying about > > > any queueing. I like the idea of someone trying to create dynamic queues > > > though ;-> > > > > > > > You need per flow queue to control something, like VoIP streams, or VPN > > streams. If you just use policy, mixed traffic is send to per flow queue. > > That is definitely not the purpose of per flow queue. > > > > The dynamic queue creating is another way to implement the per flow > > control (yes, one class and queue per flow). I think it is more complex > > and wastes resources. > > > > Look at the above suggestion - what you will waste in that case is > polices. You should actually not use HTB but rather strict prio qdisc > with policers. As I said above, it works, but is dirty anyway ;) > cheers, > jamal -- lark From hidden@balabit.hu Wed Apr 13 00:50:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 00:50:31 -0700 (PDT) Received: from balabit.hu (balabit.hu [195.70.34.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D7oP3v026267 for ; Wed, 13 Apr 2005 00:50:26 -0700 Subject: Re: Fw: throttling kernel messages: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1282) From: KOVACS Krisztian To: Olaf Kirch Cc: "Randy.Dunlap" , netdev In-Reply-To: <20050412203950.GA9964@suse.de> References: <20050412114148.66283c58.rddunlap@osdl.org> <1113337130.3004.14.camel@krak.odu> <20050412203950.GA9964@suse.de> Content-Type: text/plain; charset=ISO-8859-2 Date: Wed, 13 Apr 2005 09:50:19 +0200 Message-Id: <1113378620.3811.3.camel@nienna.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hidden@balabit.hu Precedence: bulk X-list: netdev Content-Length: 762 Lines: 21 Hi, 2005-04-12, k keltezéssel 22.39-kor Olaf Kirch ezt írta: > > I also hit these assertions today. In my case it was probably because > > of a slab corruption problem caused by the e100 driver. (I had > > CONFIG_DEBUG_SLAB enabled, so a lot of slab corruption messages appeared > > right before these assertion errors.) > > Yes, we've seen these symptoms in various bug reports in various 2.6 > versions, and after some debugging narrowed it down to an e100 driver > issue. It went away with 2.6.11 final. For me it definitely did not go away with 2.6.11. However, as soo as I applied e100-napi-fixes.patch the problem magically disappeared. So I suspect this NAPI state machine problem might have been the culprit. -- Regards, Krisztian Kovacs From arun.prabha@wipro.com Wed Apr 13 04:59:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 04:59:38 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DBxXbl009169 for ; Wed, 13 Apr 2005 04:59:34 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 45D0720634 for ; Wed, 13 Apr 2005 17:21:44 +0530 (IST) Received: from blr-ec-bh3.wipro.com (unknown [10.200.50.93]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 124B120631 for ; Wed, 13 Apr 2005 17:21:44 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.166]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 17:29:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Ethernet bridge and PF_PACKET sockets Date: Wed, 13 Apr 2005 17:29:26 +0530 Message-ID: <3D81D46E0E63304FBC9ECEB136B4CF2610A1E8@BLR-EC-MBX04.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ethernet bridge and PF_PACKET sockets Thread-Index: AcVAID02rauvk6i8QZCKRyGIvDqokw== From: To: X-OriginalArrivalTime: 13 Apr 2005 11:59:26.0676 (UTC) FILETIME=[3D9D0940:01C54020] X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3DBxXbl009169 X-archive-position: 1717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arun.prabha@wipro.com Precedence: bulk X-list: netdev Content-Length: 727 Lines: 21 Hi, I am using a PF_PACKET socket to capture packets of a particular type, say ETH_P_X (where ETH_P_X is not ETH_P_ALL) from the ethernet interface, eth0. Everything will work fine. But when I configure a bridge br0, I feel that I will stop receiving the packets (since skb->dev is changed in br_pass_frame_up()). 1. Is my reasoning incorrect? 2. Is this the expected behavior? 3. What can I do to get the packets, bind to br0?? 4. Assuming bridge may/may not be always configured and I want to get packets from the ethernet interface (without really bothering about the bridge), what is the best way to do it? I should be able to transmit packets on the ethernet via the PF_PACKET socket. Thanks in advance, Arun. From nhorman@redhat.com Wed Apr 13 05:35:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 05:35:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DCZDD1011453 for ; Wed, 13 Apr 2005 05:35:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3DCZDvQ004865; Wed, 13 Apr 2005 08:35:13 -0400 Received: from hmsendeavour.rdu.redhat.com (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3DCZCO01444; Wed, 13 Apr 2005 08:35:12 -0400 Received: from hmsendeavour.rdu.redhat.com (localhost.localdomain [127.0.0.1]) by hmsendeavour.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id j3DCZC4b030059; Wed, 13 Apr 2005 08:35:12 -0400 Received: (from nhorman@localhost) by hmsendeavour.rdu.redhat.com (8.13.1/8.13.1/Submit) id j3DCZCLq030058; Wed, 13 Apr 2005 08:35:12 -0400 Date: Wed, 13 Apr 2005 08:35:12 -0400 From: Neil Horman To: arun.prabha@wipro.com Cc: netdev@oss.sgi.com Subject: Re: Ethernet bridge and PF_PACKET sockets Message-ID: <20050413123512.GA29996@hmsendeavour.rdu.redhat.com> References: <3D81D46E0E63304FBC9ECEB136B4CF2610A1E8@BLR-EC-MBX04.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D81D46E0E63304FBC9ECEB136B4CF2610A1E8@BLR-EC-MBX04.wipro.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 1957 Lines: 55 On Wed, Apr 13, 2005 at 05:29:26PM +0530, arun.prabha@wipro.com wrote: > Hi, > > I am using a PF_PACKET socket to capture packets of a particular type, > say ETH_P_X (where ETH_P_X is not ETH_P_ALL) from the ethernet > interface, eth0. Everything will work fine. But when I configure a > bridge br0, I feel that I will stop receiving the packets (since > skb->dev is changed in br_pass_frame_up()). > > 1. Is my reasoning incorrect? More or less, I think, since bridge handling is done prior to the execution of the registered packet_type function that PF_PACKET sockets register to recieve frames in netif_receive_skb. It looks to me as though any frame which the bridge code decides belongs to it will be hidden from any packet socket attached to a physical interface that is a member of a bridge. I'd test that theory out just to be sure, but thats what the code looks like to me. > 2. Is this the expected behavior? It would appear that is expected/correct behavior. > 3. What can I do to get the packets, bind to br0?? Yes, when a packet is claimed by the bridge, it is re-injected into the bottom of the network stack at netif_rx. This will give your PF_PACKET socket another chance to receive the frame. So if you bind it to the bridge interface, you should see it. > 4. Assuming bridge may/may not be always configured and I want to get > packets from the ethernet interface (without really bothering about > the bridge), what is the best way to do it? > I'm not 100% sure, but my guess would be to use an iptables module to intercept the appropriate frames. > I should be able to transmit packets on the ethernet via the PF_PACKET > socket. > Yes. HTH Neil > Thanks in advance, > Arun. > > -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From jesse.brandeburg@intel.com Wed Apr 13 09:08:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 09:08:10 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DG85VS023091 for ; Wed, 13 Apr 2005 09:08:05 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3DG6laX011588; Wed, 13 Apr 2005 16:06:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3DG6HMA008383; Wed, 13 Apr 2005 16:06:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041309064618072 ; Wed, 13 Apr 2005 09:06:46 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 09:06:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fw: throttling kernel messages: KERNEL: assertion (flags &MSG_PEEK) failed at net/ipv4/tcp.c (1282) Date: Wed, 13 Apr 2005 09:06:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: throttling kernel messages: KERNEL: assertion (flags &MSG_PEEK) failed at net/ipv4/tcp.c (1282) Thread-Index: AcU//cD71UWNH0kxSUOK78RwUNqC3wARLubA From: "Brandeburg, Jesse" To: "KOVACS Krisztian" , "Olaf Kirch" Cc: "Randy.Dunlap" , "netdev" X-OriginalArrivalTime: 13 Apr 2005 16:06:46.0845 (UTC) FILETIME=[CB0B1ED0:01C54042] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3DG85VS023091 X-archive-position: 1719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 991 Lines: 22 >From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On >Behalf Of KOVACS Krisztian >2005-04-12, k keltezéssel 22.39-kor Olaf Kirch ezt írta: >> > I also hit these assertions today. In my case it was probably because >> > of a slab corruption problem caused by the e100 driver. (I had >> > CONFIG_DEBUG_SLAB enabled, so a lot of slab corruption messages >appeared >> > right before these assertion errors.) >> >> Yes, we've seen these symptoms in various bug reports in various 2.6 >> versions, and after some debugging narrowed it down to an e100 driver >> issue. It went away with 2.6.11 final. > > For me it definitely did not go away with 2.6.11. However, as soo as I >applied e100-napi-fixes.patch the problem magically disappeared. So I >suspect this NAPI state machine problem might have been the culprit. > This was the exact failure mode of this e100 bug. It would exhibit with slab corruption, only when in NAPI mode. Glad it fixed your issue as well. Jesse From dsd@gentoo.org Wed Apr 13 09:25:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 09:25:21 -0700 (PDT) Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DGPF6W025433 for ; Wed, 13 Apr 2005 09:25:15 -0700 Received: from rp015a.halls.manchester.ac.uk ([130.88.180.15]) by gannet.scg.man.ac.uk with esmtp (Exim 4.20) id 1DLkfx-0001op-TC; Wed, 13 Apr 2005 17:25:13 +0100 Message-ID: <425D483C.4000505@gentoo.org> Date: Wed, 13 Apr 2005 17:26:36 +0100 From: Daniel Drake User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: shemminger@osdl.org CC: netdev@oss.sgi.com Subject: Problem with skge 0.6 X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1DLkfx-0001op-TC*Khj4HAWQbIw* X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsd@gentoo.org Precedence: bulk X-list: netdev Content-Length: 484 Lines: 16 Hi, Gentoo have included the new skge driver in the latest install media due to a few requests. A problem has turned up, which was also experienced in older versions of the sk98lin driver. Any chance you could take a look? http://bugs.gentoo.org/show_bug.cgi?id=87822 This is with Linux 2.6.11 patched with http://dev.gentoo.org/~dsd/gentoo-sources/release-11.09/dist/4100_skge-0.6.patch and dmesg+lspci output is included on the bug: http://bugs.gentoo.org/87822 Thanks, Daniel From akpm@osdl.org Wed Apr 13 10:37:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 10:37:05 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DHb0ht027712 for ; Wed, 13 Apr 2005 10:37:01 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3DHaos4005709 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Apr 2005 10:36:51 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j3DHaoaY005400; Wed, 13 Apr 2005 10:36:50 -0700 Date: Wed, 13 Apr 2005 10:36:42 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: svallet@gmail.com Subject: Fw: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of IPv6 Neighbor-discovery multicast Message-Id: <20050413103642.172d3976.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1721 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: 1542 Lines: 60 Begin forwarded message: Date: Wed, 13 Apr 2005 07:19:38 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of IPv6 Neighbor-discovery multicast http://bugme.osdl.org/show_bug.cgi?id=4482 Summary: natsemi: incorrect initialization of IPv6 Neighbor- discovery multicast Kernel Version: 2.6.11.7 Status: NEW Severity: normal Owner: jgarzik@pobox.com Submitter: svallet@gmail.com Distribution: Debian Sarge (testing) Hardware Environment: Arch is PowerPC/BeigeG3 Problematic NIC has a DP83815 chipset (Netgear FA311) Software Environment: iproute2/ifconfig Problem Description: "ifconfig eth0 up" *apparently* allows multicast on the device : # ifconfig eth0 ... UP BROADCAST RUNNING MULTICAST ... # ip maddr show ... 1: eth0 link 33:33:ff:be:0a:ed link 33:33:00:00:00:01 ... inet6 ff02::1:ffbe:aed inet6 ff02::1 However, the NIC does *not* reply to neighbor-sollicitation multicasts, neither on 33:33:00:00:00:01 (ping6 ff02::1) or on the sollicited-node multicast. It *is* however responding *after* being brought in promiscuous mode (using tcpdump) or an "ifconfig eth0 multicast" has been issued. Shuting down and up brings the problem back again Steps to reproduce: # ifconfig eth0 down # ifconfig eth0 up ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From shemminger@osdl.org Wed Apr 13 11:20:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 11:20:51 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DIKko8029201 for ; Wed, 13 Apr 2005 11:20:46 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3DIKas4011055 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Apr 2005 11:20:37 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j3DIKaJS008281; Wed, 13 Apr 2005 11:20:36 -0700 Date: Wed, 13 Apr 2005 11:20:36 -0700 From: Stephen Hemminger To: Baruch Even Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: TCP performance drop 2.6.6->2.6.7 Message-ID: <20050413112036.752a22f4@dxpl.pdx.osdl.net> In-Reply-To: <425C60DD.5090007@ev-en.org> References: <425C493B.5040206@ev-en.org> <20050412160752.46c82f0c@dxpl.pdx.osdl.net> <425C60DD.5090007@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-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-MIMEDefang-Filter: osdl$Revision: 1.106 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1722 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: 993 Lines: 34 On Wed, 13 Apr 2005 00:59:25 +0100 Baruch Even wrote: > Stephen Hemminger wrote: > > On Tue, 12 Apr 2005 23:18:35 +0100 > > Baruch Even wrote: > >>The setup for the tests, vanilla kernels, dummynet with 100 Mbit/s and > >>40ms rtt using the BIC protocol. No patches applied whatsoever. What is the queue length? Better yet what is the exact commandline used to setup dummynet. > >> > >>iperf tests for 2.6.6 get about 90Mbit/s while 2.6.7 gets 30Mbit/s. > > > > > > Haven't measured old kernels recently. But haven't seen that with the > > newest stuff I tested last night. At 40ms delay with netem > > over 1G to 100M bridge. > > Reno 99.6 > > Vegas 61.6 > > BIC 97.8 > > Hstcp 99.4 > > Westwood 99.4 > > I've now tested 2.6.11.7 and I get about 50Mbit/s, it starts at about > 100 and drops to about 45. Tested for about a minute but it didn't show > signs of recovery. > > > What are your sysctl settings. > > Attached. > > Baruch From ravinandan.arakali@neterion.com Wed Apr 13 14:30:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 14:30:26 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DLUKPu014758 for ; Wed, 13 Apr 2005 14:30:21 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j3DLThOC025876; Wed, 13 Apr 2005 17:29:43 -0400 (EDT) Received: from rarakali ([10.16.16.56]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j3DLTfVG021735; Wed, 13 Apr 2005 17:29:42 -0400 (EDT) From: "Ravinandan Arakali" To: "'Arthur Kepner'" Cc: , , "'Leonid. Grossman \(E-mail\)'" , "'Raghavendra. Koushik \(E-mail\)'" Subject: RE: High CPU utilization with Bonding driver ? Date: Wed, 13 Apr 2005 14:29:35 -0700 Message-ID: <002101c5406f$e469e5a0$3810100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 929 Lines: 35 Arthur, We were able to get the bonding driver working with your patch on 2.6.12. The good news is it does help in our setup since we were left with 25% CPU compared to 1% CPU remaining earlier. Thanks, Ravi -----Original Message----- From: Arthur Kepner [mailto:akepner@sgi.com] Sent: Monday, April 04, 2005 8:03 PM To: Ravinandan Arakali Cc: netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net; 'Leonid. Grossman (E-mail)'; 'Raghavendra. Koushik (E-mail)' Subject: RE: High CPU utilization with Bonding driver ? On Mon, 4 Apr 2005, Ravinandan Arakali wrote: > Arthur, > On what kernel version should your below mentioned patch be applied ? > We tried on one of the older kernels(2.6.5) and got an Oops while > loading the bonding driver. > ..... Hmmm, interesting. I've used it with 2.6.X for at least two values of X (one of them being 5) so I'm surprised. Can you provide details about the oops? -- Arthut From jean-baptiste.note@m4x.org Wed Apr 13 14:57:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 14:57:28 -0700 (PDT) Received: from debian.local.gxaafoot.homelinux.org (postfix@did75-11-82-231-41-149.fbx.proxad.net [82.231.41.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DLvLbQ015567 for ; Wed, 13 Apr 2005 14:57:21 -0700 Received: by debian.local.gxaafoot.homelinux.org (Postfix, from userid 1000) id 02810532E; Wed, 13 Apr 2005 23:56:49 +0200 (CEST) From: Jean-Baptiste Note To: prism54-devel@prism54.org Cc: netdev@oss.sgi.com Subject: Question on prism54 driver Date: Wed, 13 Apr 2005 23:56:48 +0200 Message-ID: <87fyxu5oin.fsf@gxaafoot.homelinux.org> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-baptiste.note@wanadoo.fr Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 31 Dear list, Going through the prism54 code for reuse in the softmac driver, i stumbled accross inconsistencies in the queue management functions for the mgmt rx queue and the data rx queue that i cannot understand. Is there any reason that we have the following call in islpci_mgt_receive (file islpci_mgt.c): /* Ensure the results of device DMA are visible to the CPU. */ pci_dma_sync_single(priv->pdev, buf->pci_addr, frag_len, PCI_DMA_FROMDEVICE); but have nothing of the sort in islpci_eth_receive (file islpci_eth.c) ? In the same spirit, the control block is also written by DMA by the device, I guess ; so how comes we don't have such a syncing call in the interrupt handler before accessing the control block's values (file islpci_dev.c) ? Am i missing something very obvious or very subtle ? -- should shared memory be always sync'd before reading, or should we avoid it in cases where we know it's not necessary, as an optimization ? JB -- Jean-Baptiste Note +33 (0)6 83 03 42 38 jean-baptiste.note@wanadoo.fr From george@mvista.com Wed Apr 13 15:44:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 15:44:23 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DMiHcF016677 for ; Wed, 13 Apr 2005 15:44:18 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA11340; Wed, 13 Apr 2005 15:44:08 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by data.mvista.com (8.13.1/8.13.1) with ESMTP id j3DMgR2g032451; Wed, 13 Apr 2005 15:42:28 -0700 Message-ID: <425DA053.8020607@mvista.com> Date: Wed, 13 Apr 2005 15:42:27 -0700 From: George Anzinger Reply-To: george@mvista.com Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Horms CC: =?ISO-8859-1?Q?J=F6rn_Engel?= , Pavel Machek , Jeff Garzik , Andrew Morton , linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Maintainers list update: linux-net -> netdev References: <20050412062027.GA1614@verge.net.au> <425C1E30.5060405@mvista.com> <20050413021400.GA1835@verge.net.au> In-Reply-To: <20050413021400.GA1835@verge.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: george@mvista.com Precedence: bulk X-list: netdev Content-Length: 863 Lines: 37 Horms wrote: > On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote: > >>Horms wrote: >> >>>Use netdev as the mailing list contact instead of the mostly dead >>>linux-net list. >>> >> >>~ >> >>>PHRAM MTD DRIVER >>>@@ -1795,7 +1795,7 @@ >>>POSIX CLOCKS and TIMERS >>>P: George Anzinger >>>M: george@mvista.com >>>-L: linux-net@vger.kernel.org >>>+L: netdev@oss.sgi.com >>>S: Supported >>> >> >>I don't really know about the rest of them, but I think this should be: >>L: linux-kernel@vger.kernel.org >> >>Least wise that is where I look... > > > Yes, I was wondering about that one. Here is a patch that > adds to my previous patch. Trivial to say the least. > I can re-diff the whole thing if that is more convenient. Looks good to me. > -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:13 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipZB022433 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWRp16317; Wed, 13 Apr 2005 19:32:27 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNcjo8008634; Wed, 13 Apr 2005 19:38:45 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNcjp5008633; Wed, 13 Apr 2005 19:38:45 -0400 Date: Wed, 13 Apr 2005 19:38:45 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 5/10] tg3: define TG3_FLG2_5750_PLUS flag Message-ID: <04132005193845.8597@laptop> In-Reply-To: <04132005193844.8539@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1275 Lines: 33 Define TG3_FLG2_5750_PLUS flag and set it in tg3_get_invariants for ASIC_REV_5750 or ASIC_REV_5752. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 4 ++++ drivers/net/tg3.h | 1 + 2 files changed, 5 insertions(+) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:47:31.186930125 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:47:16.409928291 -0400 @@ -7951,6 +7951,10 @@ static int __devinit tg3_get_invariants( if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + tp->tg3_flags2 |= TG3_FLG2_5750_PLUS; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_HW_TSO; if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0) --- bcm5752-support/drivers/net/tg3.h.orig 2005-04-08 17:47:35.536341972 -0400 +++ bcm5752-support/drivers/net/tg3.h 2005-04-08 17:44:48.578234813 -0400 @@ -2101,6 +2101,7 @@ struct tg3 { #define TG3_FLG2_HW_TSO 0x00010000 #define TG3_FLG2_SERDES_PREEMPHASIS 0x00020000 #define TG3_FLG2_5705_PLUS 0x00040000 +#define TG3_FLG2_5750_PLUS 0x00080000 u32 split_mode_max_reqs; #define SPLIT_MODE_5704_MAX_REQ 3 From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:14 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipPP022436 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWR616325; Wed, 13 Apr 2005 19:32:27 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNcjBc008753; Wed, 13 Apr 2005 19:38:45 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNcjbH008752; Wed, 13 Apr 2005 19:38:45 -0400 Date: Wed, 13 Apr 2005 19:38:45 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 7/10] tg3: more use of TG3_FLG2_5705_PLUS flag Message-ID: <04132005193845.8720@laptop> In-Reply-To: <04132005193845.8656@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1727 Lines: 37 Rewrite of a couple of troublesome multi-way if statements to use TG3_FLG2_5705_PLUS flag. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 18:00:31.886220435 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 18:08:55.969298725 -0400 @@ -5237,10 +5237,8 @@ static int tg3_reset_hw(struct tg3 *tp) RDMAC_MODE_LNGREAD_ENAB); if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE; - if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && - tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) { + if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) && + tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) { if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE && (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 || tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) { @@ -5353,10 +5351,8 @@ static int tg3_reset_hw(struct tg3 *tp) WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB | WDMAC_MODE_LNGREAD_ENAB); - if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && - tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) { + if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) && + tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) { if ((tp->tg3_flags & TG3_FLG2_TSO_CAPABLE) && (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 || tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) { From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:14 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipN4022431 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWPP16297; Wed, 13 Apr 2005 19:32:25 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNchw5008328; Wed, 13 Apr 2005 19:38:43 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNchsY008327; Wed, 13 Apr 2005 19:38:43 -0400 Date: Wed, 13 Apr 2005 19:38:43 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 0/10] add bcm5752 support plus some cleanup to tg3 Message-ID: <04132005193843.8300@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 187 Lines: 5 Add support to tg3 for bcm5752 hardware. Also clean-up a lot of multi-way if statements and replace them with checks of flags representing classes of tg3 hardware. Patches to follow... From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:15 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipJN022443 for ; Wed, 13 Apr 2005 16:44:52 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWRJ16329; Wed, 13 Apr 2005 19:32:27 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNcjgg008812; Wed, 13 Apr 2005 19:38:45 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNcjQZ008803; Wed, 13 Apr 2005 19:38:45 -0400 Date: Wed, 13 Apr 2005 19:38:45 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 8/10] tg3: use TG3_FLG2_57{05,50}_PLUS flags in tg3_get_invariants Message-ID: <04132005193845.8775@laptop> In-Reply-To: <04132005193845.8720@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1301 Lines: 32 Rewrite checks in tg3_get_invariants to use TG3_FLG2_5705_PLUS and TG3_FLG2_5750_PLUS flags. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 18:11:46.207874683 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 18:11:36.696183379 -0400 @@ -7937,8 +7937,7 @@ static int __devinit tg3_get_invariants( GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_5750_PLUS; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) tp->tg3_flags2 |= TG3_FLG2_HW_TSO; if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0) @@ -8068,9 +8067,7 @@ static int __devinit tg3_get_invariants( if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0) tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG; /* Only 5701 and later support tagged irq status mode. From linville@tuxdriver.com Wed Apr 13 16:44:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:15 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNiv0W022483 for ; Wed, 13 Apr 2005 16:44:58 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWQM16305; Wed, 13 Apr 2005 19:32:26 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNci1K008452; Wed, 13 Apr 2005 19:38:44 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNcijT008451; Wed, 13 Apr 2005 19:38:44 -0400 Date: Wed, 13 Apr 2005 19:38:44 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 2/10] tg3: add bcm5752 to tg3_pci_tbl Message-ID: <04132005193844.8410@laptop> In-Reply-To: <04132005193843.8351@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 850 Lines: 20 Add hard-coded definition of bcm5752 PCI ID to tg3_pci_tbl. Signed-off-by: John W. Linville --- Next patch will change entry to use pci_ids.h-based definition. drivers/net/tg3.c | 2 ++ 1 files changed, 2 insertions(+) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:30:08.886197282 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:30:17.113065813 -0400 @@ -206,6 +206,8 @@ static struct pci_device_id tg3_pci_tbl[ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, 0x1600, /* TIGON3_5752 */ + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753M, From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:13 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipOZ022444 for ; Wed, 13 Apr 2005 16:44:52 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWSP16333; Wed, 13 Apr 2005 19:32:28 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNckf8008871; Wed, 13 Apr 2005 19:38:46 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNck7Q008870; Wed, 13 Apr 2005 19:38:46 -0400 Date: Wed, 13 Apr 2005 19:38:46 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 9/10] tg3: check TG3_FLG2_5750_PLUS flag to set TG3_FLG2_5705_PLUS flag Message-ID: <04132005193846.8835@laptop> In-Reply-To: <04132005193845.8775@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1193 Lines: 31 Use check of TG3_FLG2_5750_PLUS in tg3_get_invariants to set TG3_FLG2_5705_PLUS flag. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 18:13:24.632333096 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 18:13:19.559031079 -0400 @@ -7928,15 +7928,14 @@ static int __devinit tg3_get_invariants( tp->pci_hdr_type = (cacheline_sz_reg >> 16) & 0xff; tp->pci_bist = (cacheline_sz_reg >> 24) & 0xff; - if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) - tp->tg3_flags2 |= TG3_FLG2_5705_PLUS; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_5750_PLUS; + if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) || + (tp->tg3_flags2 & TG3_FLG2_5750_PLUS)) + tp->tg3_flags2 |= TG3_FLG2_5705_PLUS; + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) tp->tg3_flags2 |= TG3_FLG2_HW_TSO; From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:14 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipac022432 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWRR16313; Wed, 13 Apr 2005 19:32:27 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNciV7008575; Wed, 13 Apr 2005 19:38:44 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNci8D008568; Wed, 13 Apr 2005 19:38:44 -0400 Date: Wed, 13 Apr 2005 19:38:44 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 4/10] tg3: use TG3_FLG2_5705_PLUS instead of multi-way if's Message-ID: <04132005193844.8539@laptop> In-Reply-To: <04132005193844.8474@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 2405 Lines: 55 Replace a number of three-way if statements checking for 5705, 5750, and 5752 to reference the equivalent TG3_FLG2_5705_PLUS flag instead. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:42:28.059553796 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:42:16.584131525 -0400 @@ -85,9 +85,7 @@ /* hardware minimum and maximum for a single frame's data payload */ #define TG3_MIN_MTU 60 #define TG3_MAX_MTU(tp) \ - ((GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && \ - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && \ - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) ? 9000 : 1500) + (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS) ? 9000 : 1500) /* These numbers seem to be hard coded in the NIC firmware somehow. * You can't change the ring sizes, but you can change where you place @@ -863,9 +861,7 @@ out: if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) { /* Cannot do read-modify-write on 5401 */ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x4c20); - } else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) { + } else if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { u32 phy_reg; /* Set bit 14 with read-modify-write to preserve other bits */ @@ -877,9 +873,7 @@ out: /* Set phy register 0x10 bit 0 to high fifo elasticity to support * jumbo frames transmission. */ - if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) { + if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { u32 phy_reg; if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, &phy_reg)) @@ -8483,9 +8477,7 @@ static int __devinit tg3_test_dma(struct /* DMA read watermark not used on PCIE */ tp->dma_rwctrl |= 0x00180000; } else if (!(tp->tg3_flags & TG3_FLAG_PCIX_MODE)) { - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) tp->dma_rwctrl |= 0x003f0000; else tp->dma_rwctrl |= 0x003f000f; From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:15 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNip0w022429 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWQx16301; Wed, 13 Apr 2005 19:32:26 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNchJX008388; Wed, 13 Apr 2005 19:38:43 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNchxR008369; Wed, 13 Apr 2005 19:38:43 -0400 Date: Wed, 13 Apr 2005 19:38:43 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 1/10] tg3: add basic bcm5752 support Message-ID: <04132005193843.8351@laptop> In-Reply-To: <04132005193843.8300@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 9281 Lines: 216 Track-down all references to ASIC_REV_5750 and mirror them with references to the newly defined ASIC_REV_5752. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 63 ++++++++++++++++++++++++++++++++++++------------------ 1 files changed, 42 insertions(+), 21 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:28:59.660670261 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:29:05.039934450 -0400 @@ -86,7 +86,8 @@ #define TG3_MIN_MTU 60 #define TG3_MAX_MTU(tp) \ ((GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && \ - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) ? 9000 : 1500) + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && \ + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) ? 9000 : 1500) /* These numbers seem to be hard coded in the NIC firmware somehow. * You can't change the ring sizes, but you can change where you place @@ -861,7 +862,8 @@ out: /* Cannot do read-modify-write on 5401 */ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x4c20); } else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) { + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) { u32 phy_reg; /* Set bit 14 with read-modify-write to preserve other bits */ @@ -874,7 +876,8 @@ out: * jumbo frames transmission. */ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) { + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) { u32 phy_reg; if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, &phy_reg)) @@ -1068,7 +1071,8 @@ static int tg3_set_power_state(struct tg mac_mode = MAC_MODE_PORT_MODE_TBI; } - if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750) + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) tw32(MAC_LED_CTRL, tp->led_ctrl); if (((power_caps & PCI_PM_CAP_PME_D3cold) && @@ -3967,7 +3971,8 @@ static int tg3_chip_reset(struct tg3 *tp tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg); if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) { tp->tg3_flags |= TG3_FLAG_ENABLE_ASF; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE; } } @@ -5041,7 +5046,8 @@ static int tg3_reset_hw(struct tg3 *tp) tw32(GRC_MISC_CFG, val); /* Initialize MBUF/DESC pool. */ - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { /* Do nothing. */ } else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); @@ -5240,7 +5246,8 @@ static int tg3_reset_hw(struct tg3 *tp) rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE; if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750)) { + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) { if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE && (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 || tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) { @@ -5355,7 +5362,8 @@ static int tg3_reset_hw(struct tg3 *tp) if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) { if ((tp->tg3_flags & TG3_FLG2_TSO_CAPABLE) && (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 || tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) { @@ -7028,7 +7036,8 @@ static void __devinit tg3_get_nvram_info tw32(NVRAM_CFG1, nvcfg1); } - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { switch (nvcfg1 & NVRAM_CFG1_VENDOR_MASK) { case FLASH_VENDOR_ATMEL_FLASH_BUFFERED: tp->nvram_jedecnum = JEDEC_ATMEL; @@ -7093,7 +7102,8 @@ static void __devinit tg3_nvram_init(str GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) { tp->tg3_flags |= TG3_FLAG_NVRAM; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7102,7 +7112,8 @@ static void __devinit tg3_nvram_init(str tg3_get_nvram_info(tp); tg3_get_nvram_size(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7195,7 +7206,8 @@ static int tg3_nvram_read(struct tg3 *tp tg3_nvram_lock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32_f(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7210,7 +7222,8 @@ static int tg3_nvram_read(struct tg3 *tp tg3_nvram_unlock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32_f(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7438,7 +7451,8 @@ static int tg3_nvram_write_block(struct tg3_nvram_lock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7463,7 +7477,8 @@ static int tg3_nvram_write_block(struct grc_mode = tr32(GRC_MODE); tw32(GRC_MODE, grc_mode & ~GRC_MODE_NVRAM_WR_ENABLE); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7581,7 +7596,8 @@ static int __devinit tg3_phy_probe(struc } else eeprom_phy_id = 0; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { led_cfg = cfg2 & (NIC_SRAM_DATA_CFG_LED_MODE_MASK | SHASTA_EXT_LED_MODE_MASK); } else @@ -7634,7 +7650,8 @@ static int __devinit tg3_phy_probe(struc if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) { tp->tg3_flags |= TG3_FLAG_ENABLE_ASF; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE; } if (nic_cfg & NIC_SRAM_DATA_CFG_FIBER_WOL) @@ -7932,10 +7949,12 @@ static int __devinit tg3_get_invariants( tp->pci_bist = (cacheline_sz_reg >> 24) & 0xff; if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750)) + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752)) tp->tg3_flags2 |= TG3_FLG2_5705_PLUS; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_HW_TSO; if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0) @@ -8066,7 +8085,8 @@ static int __devinit tg3_get_invariants( tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG; if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG; /* Only 5701 and later support tagged irq status mode. @@ -8462,7 +8482,8 @@ static int __devinit tg3_test_dma(struct tp->dma_rwctrl |= 0x00180000; } else if (!(tp->tg3_flags & TG3_FLAG_PCIX_MODE)) { if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) tp->dma_rwctrl |= 0x003f0000; else tp->dma_rwctrl |= 0x003f000f; From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:15 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipDE022434 for ; Wed, 13 Apr 2005 16:44:51 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWRR16321; Wed, 13 Apr 2005 19:32:27 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNcjFC008693; Wed, 13 Apr 2005 19:38:45 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNcjJD008692; Wed, 13 Apr 2005 19:38:45 -0400 Date: Wed, 13 Apr 2005 19:38:45 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 6/10] tg3: use new TG3_FLG2_5750_PLUS flag Message-ID: <04132005193845.8656@laptop> In-Reply-To: <04132005193845.8597@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 5228 Lines: 135 Replace a number of two-way if statements checking for 5750, and/or 5752 to reference the newly-defined TG3_FLG2_5750_PLUS flag instead. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 38 +++++++++++++------------------------- 1 files changed, 13 insertions(+), 25 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:57:50.096149244 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:57:10.716485067 -0400 @@ -1067,8 +1067,7 @@ static int tg3_set_power_state(struct tg mac_mode = MAC_MODE_PORT_MODE_TBI; } - if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5750 && - GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5752) + if (!(tp->tg3_flags2 & TG3_FLG2_5750_PLUS)) tw32(MAC_LED_CTRL, tp->led_ctrl); if (((power_caps & PCI_PM_CAP_PME_D3cold) && @@ -3967,8 +3966,7 @@ static int tg3_chip_reset(struct tg3 *tp tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg); if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) { tp->tg3_flags |= TG3_FLAG_ENABLE_ASF; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE; } } @@ -5042,8 +5040,7 @@ static int tg3_reset_hw(struct tg3 *tp) tw32(GRC_MISC_CFG, val); /* Initialize MBUF/DESC pool. */ - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { /* Do nothing. */ } else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); @@ -7032,8 +7029,7 @@ static void __devinit tg3_get_nvram_info tw32(NVRAM_CFG1, nvcfg1); } - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { switch (nvcfg1 & NVRAM_CFG1_VENDOR_MASK) { case FLASH_VENDOR_ATMEL_FLASH_BUFFERED: tp->nvram_jedecnum = JEDEC_ATMEL; @@ -7098,8 +7094,7 @@ static void __devinit tg3_nvram_init(str GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) { tp->tg3_flags |= TG3_FLAG_NVRAM; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7108,8 +7103,7 @@ static void __devinit tg3_nvram_init(str tg3_get_nvram_info(tp); tg3_get_nvram_size(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7202,8 +7196,7 @@ static int tg3_nvram_read(struct tg3 *tp tg3_nvram_lock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32_f(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7218,8 +7211,7 @@ static int tg3_nvram_read(struct tg3 *tp tg3_nvram_unlock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32_f(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7447,8 +7439,7 @@ static int tg3_nvram_write_block(struct tg3_nvram_lock(tp); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess | ACCESS_ENABLE); @@ -7473,8 +7464,7 @@ static int tg3_nvram_write_block(struct grc_mode = tr32(GRC_MODE); tw32(GRC_MODE, grc_mode & ~GRC_MODE_NVRAM_WR_ENABLE); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) { u32 nvaccess = tr32(NVRAM_ACCESS); tw32(NVRAM_ACCESS, nvaccess & ~ACCESS_ENABLE); @@ -7592,11 +7582,10 @@ static int __devinit tg3_phy_probe(struc } else eeprom_phy_id = 0; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) { + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) led_cfg = cfg2 & (NIC_SRAM_DATA_CFG_LED_MODE_MASK | SHASTA_EXT_LED_MODE_MASK); - } else + else led_cfg = nic_cfg & NIC_SRAM_DATA_CFG_LED_MODE_MASK; switch (led_cfg) { @@ -7646,8 +7635,7 @@ static int __devinit tg3_phy_probe(struc if (nic_cfg & NIC_SRAM_DATA_CFG_ASF_ENABLE) { tp->tg3_flags |= TG3_FLAG_ENABLE_ASF; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) tp->tg3_flags2 |= TG3_FLG2_ASF_NEW_HANDSHAKE; } if (nic_cfg & NIC_SRAM_DATA_CFG_FIBER_WOL) From linville@tuxdriver.com Wed Apr 13 16:44:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:13 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNipEJ022441 for ; Wed, 13 Apr 2005 16:44:52 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWQF16309; Wed, 13 Apr 2005 19:32:26 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNciFr008516; Wed, 13 Apr 2005 19:38:44 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNciOr008502; Wed, 13 Apr 2005 19:38:44 -0400 Date: Wed, 13 Apr 2005 19:38:44 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 3/10] tg3: add bcm5752 entry to pci_ids.h Message-ID: <04132005193844.8474@laptop> In-Reply-To: <04132005193844.8410@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1399 Lines: 32 Add proper entry for bcm5752 PCI ID to pci_ids.h, and use it in tg3. Signed-off-by: John W. Linville --- I did this separately in case patches like this (i.e. new PCI IDs) need to come from more "official" sources. drivers/net/tg3.c | 2 +- include/linux/pci_ids.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-08 17:35:34.834372048 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-08 17:34:42.536563710 -0400 @@ -206,7 +206,7 @@ static struct pci_device_id tg3_pci_tbl[ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, - { PCI_VENDOR_ID_BROADCOM, 0x1600, /* TIGON3_5752 */ + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5752, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, --- bcm5752-support/include/linux/pci_ids.h.orig 2005-04-08 17:30:45.655140363 -0400 +++ bcm5752-support/include/linux/pci_ids.h 2005-04-08 17:31:52.965883217 -0400 @@ -2065,6 +2065,7 @@ #define PCI_DEVICE_ID_AFAVLAB_P030 0x2182 #define PCI_VENDOR_ID_BROADCOM 0x14e4 +#define PCI_DEVICE_ID_TIGON3_5752 0x1600 #define PCI_DEVICE_ID_TIGON3_5700 0x1644 #define PCI_DEVICE_ID_TIGON3_5701 0x1645 #define PCI_DEVICE_ID_TIGON3_5702 0x1646 From linville@tuxdriver.com Wed Apr 13 16:45:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Apr 2005 16:45:42 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DNjZi3022695 for ; Wed, 13 Apr 2005 16:45:35 -0700 Received: (from uucp@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) with UUCP id j3DNWS916337; Wed, 13 Apr 2005 19:32:28 -0400 Received: from laptop.mobile (laptop.mobile [127.0.0.1]) by laptop.mobile (8.13.1/8.13.1) with ESMTP id j3DNckD6008930; Wed, 13 Apr 2005 19:38:46 -0400 Received: (from linville@localhost) by laptop.mobile (8.13.1/8.13.1/Submit) id j3DNckwp008912; Wed, 13 Apr 2005 19:38:46 -0400 Date: Wed, 13 Apr 2005 19:38:46 -0400 From: "John W. Linville" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.12-rc2 10/10] tg3: add support for bcm5752 rev a1 Message-ID: <04132005193846.8893@laptop> In-Reply-To: <04132005193846.8835@laptop> User-Agent: PatchPost/0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1829 Lines: 44 Replace existing ASIC_REV_5752 definition with ASIC_REV_5752_A0, and add definition for ASIC_REV_5752_A1. Then, add ASIC_REV_5752_A1 to check for setting TG3_FLG2_5750_PLUS in tg3_get_invariants. Signed-off-by: John W. Linville --- drivers/net/tg3.c | 3 ++- drivers/net/tg3.h | 5 ++++- 2 files changed, 6 insertions(+), 2 deletions(-) --- bcm5752-support/drivers/net/tg3.c.orig 2005-04-12 14:19:06.302429500 -0400 +++ bcm5752-support/drivers/net/tg3.c 2005-04-12 14:17:50.963846711 -0400 @@ -7929,7 +7929,8 @@ static int __devinit tg3_get_invariants( tp->pci_bist = (cacheline_sz_reg >> 24) & 0xff; if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752) + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752_A0 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752_A1) tp->tg3_flags2 |= TG3_FLG2_5750_PLUS; if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) || --- bcm5752-support/drivers/net/tg3.h.orig 2005-04-12 14:19:06.288431435 -0400 +++ bcm5752-support/drivers/net/tg3.h 2005-04-12 14:17:50.981844223 -0400 @@ -125,6 +125,8 @@ #define CHIPREV_ID_5750_A0 0x4000 #define CHIPREV_ID_5750_A1 0x4001 #define CHIPREV_ID_5750_A3 0x4003 +#define CHIPREV_ID_5752_A0 0x5000 +#define CHIPREV_ID_5752_A1 0x6001 #define GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12) #define ASIC_REV_5700 0x07 #define ASIC_REV_5701 0x00 @@ -132,7 +134,8 @@ #define ASIC_REV_5704 0x02 #define ASIC_REV_5705 0x03 #define ASIC_REV_5750 0x04 -#define ASIC_REV_5752 0x05 +#define ASIC_REV_5752_A0 0x05 +#define ASIC_REV_5752_A1 0x06 #define GET_CHIP_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 8) #define CHIPREV_5700_AX 0x70 #define CHIPREV_5700_BX 0x71 From rainer.weikusat@sncag.com Thu Apr 14 02:04:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 02:05:04 -0700 (PDT) Received: from farside.sncag.com ([217.111.56.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3E94tMw016054 for ; Thu, 14 Apr 2005 02:04:56 -0700 Received: from farside.sncag.com (localhost [127.0.0.1]) by farside.sncag.com (8.13.3/8.13.3/Debian-8) with ESMTP id j3E94fNX005673; Thu, 14 Apr 2005 11:04:41 +0200 Received: (from rw@localhost) by farside.sncag.com (8.13.3/8.13.3/Submit) id j3E94e8D005670; Thu, 14 Apr 2005 11:04:40 +0200 To: Jean-Baptiste Note Cc: prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re: [Prism54-devel] Question on prism54 driver In-Reply-To: <87fyxu5oin.fsf@gxaafoot.homelinux.org> (Jean-Baptiste Note's message of "Wed, 13 Apr 2005 23:56:48 +0200") References: <87fyxu5oin.fsf@gxaafoot.homelinux.org> From: Rainer Weikusat Date: Thu, 14 Apr 2005 11:04:40 +0200 Message-ID: <87hdi9sp93.fsf@farside.sncag.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rainer.weikusat@sncag.com Precedence: bulk X-list: netdev Content-Length: 1998 Lines: 48 Jean-Baptiste Note writes: > Going through the prism54 code for reuse in the softmac driver, i > stumbled accross inconsistencies in the queue management functions for > the mgmt rx queue and the data rx queue that i cannot understand. > > Is there any reason that we have the following call in > islpci_mgt_receive (file islpci_mgt.c): > > /* Ensure the results of device DMA are visible to the CPU. */ > pci_dma_sync_single(priv->pdev, buf->pci_addr, > frag_len, PCI_DMA_FROMDEVICE); > > but have nothing of the sort in islpci_eth_receive (file islpci_eth.c)? > > In the same spirit, the control block is also written by DMA by the > device, I guess ; so how comes we don't have such a syncing call in the > interrupt handler before accessing the control block's values (file > islpci_dev.c) ? > > Am i missing something very obvious or very subtle? No, you are just hacking the code without even having tried to understand a) what it is doing b) why it does this [which, "by coincedence", happens to be the reason that this driver is so thouroughly broken] The data transfers (all of them) use streaming DMA mappings, which have to be synced explicitly between 'bus view' and 'CPU view', because they may involve bounce buffers (in 2.4) and to ensure that data the CPU has written to the cache is actually in memory and data the DMA engine has written is not ignored because of (actually stale) cache entries that predate it. The mgmt-queues use persistent streaming mapping, which means they have to be synced everytime the CPU intends to access them after they were accessed by the DMA engine. The skbuffs used by the data transfer code are mapped before they are passed to the device and unmapped (which syncs them) before the CPU accesses them. This isn't needed for the control block, because it is a consistent and not a streaming mapping. BTW, I shouldn't be telling you how your code works, don't you think so? From jean-baptiste.note@m4x.org Thu Apr 14 04:26:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 04:26:14 -0700 (PDT) Received: from debian.local.gxaafoot.homelinux.org (postfix@did75-11-82-231-41-149.fbx.proxad.net [82.231.41.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EBQ7nF026677 for ; Thu, 14 Apr 2005 04:26:07 -0700 Received: by debian.local.gxaafoot.homelinux.org (Postfix, from userid 1000) id A77BC4B19; Thu, 14 Apr 2005 13:25:38 +0200 (CEST) To: Rainer Weikusat Cc: prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re: [Prism54-devel] Question on prism54 driver References: <87fyxu5oin.fsf@gxaafoot.homelinux.org> <87hdi9sp93.fsf@farside.sncag.com> From: Jean-Baptiste Note Date: Thu, 14 Apr 2005 13:25:38 +0200 In-Reply-To: <87hdi9sp93.fsf@farside.sncag.com> (Rainer Weikusat's message of "Thu, 14 Apr 2005 11:04:40 +0200") Message-ID: <87r7hdwqfh.fsf@gxaafoot.homelinux.org> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-baptiste.note@wanadoo.fr Precedence: bulk X-list: netdev Content-Length: 1648 Lines: 47 Hello Rainer, dear list, First of all, thanks for your quick reply, which is very enlightening. > > No, you are just hacking the code without even having tried to > understand > > a) what it is doing > b) why it does this > [which, "by coincedence", happens to be the reason that this driver is > so thouroughly broken] > Please don't let my dumb questions shed a bad light on the prism54 developers as a whole. I have no doubt that such questions would be obvious to core prism54 developers; i only have reverse-engeneered the softmac usb protocol and am trying to use the prism54 code to do a pci version of the softmac usb driver. Rest assured that i will not touch the main prism54 code. > which means they have to be synced everytime the CPU intends to access > them after they were accessed by the DMA engine. The skbuffs used by > the data transfer code are mapped before they are passed to the device > and unmapped (which syncs them) before the CPU accesses them. This > isn't needed for the control block, because it is a consistent and not > a streaming mapping. Thank you for taking the time to look into this and answering so thoroughly. I missed the call to pci_unmap_single, and didn't know about the consistent mapping meaning. > BTW, I shouldn't be telling you how your code works, don't you think > so? I'm sorry my listing as a prism54 developer may lead to some confusion, and adversely affect all people in prism54 in addition to making a fool of myself. This has raised my awareness level. Thanks also for this :) JB -- Jean-Baptiste Note +33 (0)6 83 03 42 38 jean-baptiste.note@wanadoo.fr From herbert@gondor.apana.org.au Thu Apr 14 05:27:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 05:27:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ECRa24028599 for ; Thu, 14 Apr 2005 05:27:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DM3RC-0005vh-00; Thu, 14 Apr 2005 22:27:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DM3QD-00045e-00; Thu, 14 Apr 2005 22:26:13 +1000 From: Herbert Xu To: dlstevens@us.ibm.com (David Stevens) Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory Cc: davem@davemloft.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 14 Apr 2005 22:26:13 +1000 X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5974 Lines: 243 David Stevens wrote: > > I don't know if it is possible, after the fix for the second problem, to > get an > skb with nonzero nr_frags in rawv6_push_pending_frames() (maybe with > corking? or maybe via MSG_MORE?), but this patch includes support for > non-linear skbs as well as the missing flush on error that caused the > problem > to begin with. Yes it is possible to get nr_frags != 0. We also need to handle the case where there are multiple packets on sk_write_queue. So here is a patch that introduces skb_store_bits -- the opposite of skb_copy_bits, and uses them to read/write the csum field in rawv6. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== include/linux/skbuff.h 1.65 vs edited ===== --- 1.65/include/linux/skbuff.h 2005-03-12 07:32:26 +11:00 +++ edited/include/linux/skbuff.h 2005-04-14 22:04:30 +10:00 @@ -1183,6 +1183,8 @@ int len, unsigned int csum); extern int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); +extern int skb_store_bits(const struct sk_buff *skb, int offset, + void *from, int len); extern unsigned int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, int len, unsigned int csum); ===== net/core/skbuff.c 1.44 vs edited ===== --- 1.44/net/core/skbuff.c 2005-03-12 07:32:26 +11:00 +++ edited/net/core/skbuff.c 2005-04-14 22:22:21 +10:00 @@ -985,6 +985,94 @@ return -EFAULT; } +/** + * skb_store_bits - store bits from kernel buffer to skb + * @skb: destination buffer + * @offset: offset in destination + * @from: source buffer + * @len: number of bytes to copy + * + * Copy the specified number of bytes from the source buffer to the + * destination skb. This function handles all the messy bits of + * traversing fragment lists and such. + */ + +int skb_store_bits(const struct sk_buff *skb, int offset, void *from, int len) +{ + int i, copy; + int start = skb_headlen(skb); + + if (offset > (int)skb->len - len) + goto fault; + + if ((copy = start - offset) > 0) { + if (copy > len) + copy = len; + memcpy(skb->data + offset, from, copy); + if ((len -= copy) == 0) + return 0; + offset += copy; + from += copy; + } + + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { + skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; + int end; + + BUG_TRAP(start <= offset + len); + + end = start + frag->size; + if ((copy = end - offset) > 0) { + u8 *vaddr; + + if (copy > len) + copy = len; + + vaddr = kmap_skb_frag(frag); + memcpy(vaddr + frag->page_offset + offset - start, + from, copy); + kunmap_skb_frag(vaddr); + + if ((len -= copy) == 0) + return 0; + offset += copy; + from += copy; + } + start = end; + } + + if (skb_shinfo(skb)->frag_list) { + struct sk_buff *list = skb_shinfo(skb)->frag_list; + + for (; list; list = list->next) { + int end; + + BUG_TRAP(start <= offset + len); + + end = start + list->len; + if ((copy = end - offset) > 0) { + if (copy > len) + copy = len; + if (skb_store_bits(list, offset - start, + from, copy)) + goto fault; + if ((len -= copy) == 0) + return 0; + offset += copy; + from += copy; + } + start = end; + } + } + if (!len) + return 0; + +fault: + return -EFAULT; +} + +EXPORT_SYMBOL(skb_store_bits); + /* Checksum skb data. */ unsigned int skb_checksum(const struct sk_buff *skb, int offset, ===== net/ipv6/raw.c 1.80 vs edited ===== --- 1.80/net/ipv6/raw.c 2005-03-27 09:04:35 +10:00 +++ edited/net/ipv6/raw.c 2005-04-14 22:10:51 +10:00 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include @@ -452,12 +453,15 @@ } static int rawv6_push_pending_frames(struct sock *sk, struct flowi *fl, - struct raw6_sock *rp, int len) + struct raw6_sock *rp) { + struct inet_sock *inet = inet_sk(sk); struct sk_buff *skb; int err = 0; - u16 *csum; + int offset; + int len; u32 tmp_csum; + u16 csum; if (!rp->checksum) goto send; @@ -465,10 +469,10 @@ if ((skb = skb_peek(&sk->sk_write_queue)) == NULL) goto out; - if (rp->offset + 1 < len) - csum = (u16 *)(skb->h.raw + rp->offset); - else { + offset = rp->offset; + if (offset >= inet->cork.length - 1) { err = -EINVAL; + ip6_flush_pending_frames(sk); goto out; } @@ -479,23 +483,46 @@ */ tmp_csum = skb->csum; } else { + struct sk_buff *csum_skb = NULL; tmp_csum = 0; skb_queue_walk(&sk->sk_write_queue, skb) { tmp_csum = csum_add(tmp_csum, skb->csum); + + if (csum_skb) + continue; + + len = skb->len - (skb->h.raw - skb->data); + if (offset >= len) { + offset -= len; + continue; + } + + csum_skb = skb; } + + skb = csum_skb; } + offset += skb->h.raw - skb->data; + if (skb_copy_bits(skb, offset, &csum, 2)) + BUG(); + /* in case cksum was not initialized */ - if (unlikely(*csum)) - tmp_csum = csum_sub(tmp_csum, *csum); + if (unlikely(csum)) + tmp_csum = csum_sub(tmp_csum, csum); - *csum = csum_ipv6_magic(&fl->fl6_src, - &fl->fl6_dst, - len, fl->proto, tmp_csum); + tmp_csum = csum_ipv6_magic(&fl->fl6_src, + &fl->fl6_dst, + inet->cork.length, fl->proto, tmp_csum); + + if (tmp_csum == 0) + tmp_csum = -1; + + csum = tmp_csum; + if (skb_store_bits(skb, offset, &csum, 2)) + BUG(); - if (*csum == 0) - *csum = -1; send: err = ip6_push_pending_frames(sk); out: @@ -774,7 +801,7 @@ if (err) ip6_flush_pending_frames(sk); else if (!(msg->msg_flags & MSG_MORE)) - err = rawv6_push_pending_frames(sk, &fl, rp, len); + err = rawv6_push_pending_frames(sk, &fl, rp); } done: ip6_dst_store(sk, dst, From yoshfuji@linux-ipv6.org Thu Apr 14 05:32:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 05:32:22 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ECWHOm029215 for ; Thu, 14 Apr 2005 05:32:17 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8701933CC2; Thu, 14 Apr 2005 21:34:34 +0900 (JST) Date: Thu, 14 Apr 2005 21:34:32 +0900 (JST) Message-Id: <20050414.213432.123958433.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, davem@davemloft.net Cc: dlstevens@us.ibm.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel 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: 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-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1738 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: 497 Lines: 13 In article (at Thu, 14 Apr 2005 22:26:13 +1000), Herbert Xu says: > So here is a patch that introduces skb_store_bits -- the opposite of > skb_copy_bits, and uses them to read/write the csum field in rawv6. > > Signed-off-by: Herbert Xu (I re-review this later, but anyway,) I basically agree; this is what I wanted. Signed-off-by: Hideaki YOSHIFUJI --yoshfuji From herbert@gondor.apana.org.au Thu Apr 14 05:34:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 05:34:55 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ECYjOL029818 for ; Thu, 14 Apr 2005 05:34:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DM3YN-0005y4-00; Thu, 14 Apr 2005 22:34:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DM3Y7-0004Fr-00; Thu, 14 Apr 2005 22:34:23 +1000 Date: Thu, 14 Apr 2005 22:34:23 +1000 To: David Stevens Cc: davem@davemloft.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [IPV6] Replace bogus instances of inet->recverr Message-ID: <20050414123423.GA16334@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1951 Lines: 67 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: While looking at this problem I noticed that IPv6 was sometimes looking at inet->recverr which is bogus. Here is a patch to correct that and use np->recverr. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=raw6-2 ===== net/ipv6/ip6_output.c 1.91 vs edited ===== --- 1.91/net/ipv6/ip6_output.c 2005-03-19 05:44:52 +11:00 +++ edited/net/ipv6/ip6_output.c 2005-04-14 22:30:22 +10:00 @@ -1149,7 +1149,7 @@ err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dst->dev, dst_output); if (err) { if (err > 0) - err = inet->recverr ? net_xmit_errno(err) : 0; + err = np->recverr ? net_xmit_errno(err) : 0; if (err) goto error; } --- linux-2.6/net/ipv6/raw.c.orig 2005-04-14 22:27:07.000000000 +1000 +++ linux-2.6/net/ipv6/raw.c 2005-04-14 22:29:58.000000000 +1000 @@ -533,7 +533,7 @@ struct flowi *fl, struct rt6_info *rt, unsigned int flags) { - struct inet_sock *inet = inet_sk(sk); + struct ipv6_pinfo *np = inet6_sk(sk); struct ipv6hdr *iph; struct sk_buff *skb; unsigned int hh_len; @@ -570,7 +570,7 @@ err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, rt->u.dst.dev, dst_output); if (err > 0) - err = inet->recverr ? net_xmit_errno(err) : 0; + err = np->recverr ? net_xmit_errno(err) : 0; if (err) goto error; out: @@ -807,8 +807,6 @@ ip6_dst_store(sk, dst, ipv6_addr_equal(&fl.fl6_dst, &np->daddr) ? &np->daddr : NULL); - if (err > 0) - err = np->recverr ? net_xmit_errno(err) : 0; release_sock(sk); out: --GvXjxJ+pjyke8COw-- From yoshfuji@linux-ipv6.org Thu Apr 14 06:19:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 06:19:15 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EDJ845006337 for ; Thu, 14 Apr 2005 06:19:08 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3227C33CC2; Thu, 14 Apr 2005 22:21:26 +0900 (JST) Date: Thu, 14 Apr 2005 22:21:24 +0900 (JST) Message-Id: <20050414.222124.27105970.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, herbert@gondor.apana.org.au Cc: dlstevens@us.ibm.com, davem@davemloft.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [IPV6] Replace bogus instances of inet->recverr From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050414123423.GA16334@gondor.apana.org.au> References: <20050414123423.GA16334@gondor.apana.org.au> 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-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1740 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: 449 Lines: 13 In article <20050414123423.GA16334@gondor.apana.org.au> (at Thu, 14 Apr 2005 22:34:23 +1000), Herbert Xu says: > While looking at this problem I noticed that IPv6 was sometimes > looking at inet->recverr which is bogus. Here is a patch to > correct that and use np->recverr. > > Signed-off-by: Herbert Xu ok, agreed. Acked-by: Hideaki YOSHIFUJI --yoshfuji From rahul8143@gmail.com Thu Apr 14 06:47:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 06:47:09 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EDl3RU014306 for ; Thu, 14 Apr 2005 06:47:03 -0700 Received: by wproxy.gmail.com with SMTP id 70so804912wra for ; Thu, 14 Apr 2005 06:46:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TQOefoAdvu8a9gcFCsUxVRFps+GD2FW9UwiPxTYNkYWI3lWzmeGFnsLlJMs5EDrWKqECZh+cDi6kjE6QdDdWbEp6+JJl8VREgRIfidAHwNvWYjsMwbNbZgxvVkXYxWkP1eJxglA4eVre3TAGd7jNek758eX7PmV93e7N3uY0vOE= Received: by 10.54.7.52 with SMTP id 52mr1684299wrg; Thu, 14 Apr 2005 06:46:56 -0700 (PDT) Received: by 10.54.7.70 with HTTP; Thu, 14 Apr 2005 06:46:56 -0700 (PDT) Message-ID: Date: Thu, 14 Apr 2005 19:16:56 +0530 From: "rahul N." Reply-To: "rahul N." To: netdev@oss.sgi.com Subject: packet forwarding understandings Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3EDl3RU014306 X-archive-position: 1741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rahul8143@gmail.com Precedence: bulk X-list: netdev Content-Length: 813 Lines: 29 hello, Following is code snippet from ip_forward function from ip_forward.c ........ dev2 = rt->u.dst.dev; mtu = rt->u.dst.pmtu; /* * We now generate an ICMP HOST REDIRECT giving the route * we calculated. */ if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr) ip_rt_send_redirect(skb); /* We are about to mangle packet. Copy it! */ if (skb_cow(skb, dev2->hard_header_len)) goto drop; iph = skb->nh.iph; ............... when router takes packet to forward does above code is written to check if next dst hop has different network device or if it is using different hard_header_len so that skb_cow is called? whats use of skb_cow in ip_forward? I am using 2.4 series kernel. regards, rahul From chas@cmf.nrl.navy.mil Thu Apr 14 10:48:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 10:48:17 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EHmCFa004025 for ; Thu, 14 Apr 2005 10:48:12 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j3EHm6Q0022689; Thu, 14 Apr 2005 13:48:06 -0400 (EDT) Message-Id: <200504141748.j3EHm6Q0022689@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1/1][ATM]: sk_atm() conversion missed subtle change of vcc Date: Thu, 14 Apr 2005 13:48:06 -0400 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 1742 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: 863 Lines: 27 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/14 13:42:33-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: sk_atm() conversion missed subtle change of vcc # # Signed-off-by: Chas Williams # # net/atm/signaling.c # 2005/04/14 13:42:11-04:00 chas@relax.cmf.nrl.navy.mil +1 -0 # [ATM]: sk_atm() conversion missed subtle change of vcc # # Signed-off-by: Chas Williams # diff -Nru a/net/atm/signaling.c b/net/atm/signaling.c --- a/net/atm/signaling.c 2005-04-14 13:47:32 -04:00 +++ b/net/atm/signaling.c 2005-04-14 13:47:32 -04:00 @@ -134,6 +134,7 @@ break; case as_indicate: vcc = *(struct atm_vcc **) &msg->listen_vcc; + sk = sk_atm(vcc); DPRINTK("as_indicate!!!\n"); lock_sock(sk); if (sk_acceptq_is_full(sk)) { From ganesh.venkatesan@gmail.com Thu Apr 14 11:01:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 11:01:15 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EI17Ku004871 for ; Thu, 14 Apr 2005 11:01:07 -0700 Received: by zproxy.gmail.com with SMTP id 8so338332nzo for ; Thu, 14 Apr 2005 11:01:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IcoAE9OQwY1pd/JXAJEpqVnXkNEiTudfaKrRoji8T53lYPhqWWn2ivzrmu7lkdbl/ZRIDgHDyxdoZwsfwQa3GJAmrejbZnkX9aH/VR5m6BR6X+nPcPiT9WDvoSWrX4TjFTw5sCycIJfvM4aVHgJxkSnzS1nude4fkJ9HKH0B9ho= Received: by 10.36.74.9 with SMTP id w9mr132454nza; Thu, 14 Apr 2005 11:01:01 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Thu, 14 Apr 2005 11:01:01 -0700 (PDT) Message-ID: <5fc59ff305041411013fd35ed4@mail.gmail.com> Date: Thu, 14 Apr 2005 11:01:01 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Ben Greear Subject: Re: PCI interrupt problem: e1000 & Super-Micro X6DVA motherboard Cc: "netdev@oss.sgi.com" , linux-kernel , Lennert Buytenhek In-Reply-To: <42431734.3030905@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42421FF2.7050501@candelatech.com> <20050324081003.GA23453@xi.wantstofly.org> <42431734.3030905@candelatech.com> X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3EI17Ku004871 X-archive-position: 1743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 1340 Lines: 42 Ben: Have you checked if the BIOS on the super micro machine is the latest and greatest. I have had interrupt routing issues very similar to the one you are describing due to a BIOS Interrupt Routing issue. Moving to newer BIOS fixed it. ganesh. On 3/24/05, Ben Greear wrote: > Lennert Buytenhek wrote: > > On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote: > > > > > >>I have two 4-port e1000 NICs in the system, on a riser card. > > > > > > How is the riser card wired? F.e. does it have a single edge > > connector, and provides two PCI slots, or does it have a tiny > > additional edge connector that routes REQ#/GNT#/INTx from a > > nearby PCI slot, etc.? > > I was able to reproduce the problem even when the 4-port e1000 NIC > is plugged directly into the motherboard, so it's not the > riser... > > I also tried with a 4-port VIA-Rhine NIC (router-board 44). It also > fails it's third interface, with the same problem. So, it is not > the e1000 NIC nor the e1000 driver that is the problem. > > I do notice that it is the same interrupt (26) that is always assigned > to the broken port. I have the lspci and dmesg output for the via-rhine > boot if anyone wants it... > > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From dlstevens@us.ibm.com Thu Apr 14 11:37:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 11:37:09 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EIautw007857 for ; Thu, 14 Apr 2005 11:37:04 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3EIao4I172636 for ; Thu, 14 Apr 2005 14:36:50 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3EIaoNP244480 for ; Thu, 14 Apr 2005 12:36:50 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EIanTW031707 for ; Thu, 14 Apr 2005 12:36:49 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EIanda031694; Thu, 14 Apr 2005 12:36:49 -0600 In-Reply-To: To: Herbert Xu Cc: davem@davemloft.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 14 Apr 2005 12:36:46 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/14/2005 12:36:48 Content-Type: multipart/mixed; boundary="=_mixed 00663E1988256FE3_=" X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1744 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: 2411 Lines: 62 --=_mixed 00663E1988256FE3_= Content-Type: text/plain; charset="US-ASCII" I'm still looking at your patch. Below is a piece of my original patch that I've separated out to make sure it doesn't get lost in this discussion. It's the fix for the bug that triggered all of this and the real cause of the panic for the ordinary raw-socket cases, where nr_frags is supposed to be "0". Attached and in-line below. A couple comments initially on your patch: multiple packet support I don't think is needed here (in sendmsg). I agree it's good to put it in for other possible uses, but IPV6_CHECKSUM doesn't need it, as far as I can tell. How about a loop instead of a recursive call? If the list is long enough and the architecture eats stack a lot of stack space on function calls, that could be a problem. +-DLS The fix part of the patch: Signed-off-by: David L Stevens --- linux-2.6.11.7/net/ipv6/raw.c 2005-04-07 11:57:32.000000000 -0700 +++ linux-2.6.11.7T1/net/ipv6/raw.c 2005-04-12 15:05:00.000000000 -0700 @@ -771,8 +790,11 @@ back_from_confirm: if (err) ip6_flush_pending_frames(sk); - else if (!(msg->msg_flags & MSG_MORE)) + else if (!(msg->msg_flags & MSG_MORE)) { err = rawv6_push_pending_frames(sk, &fl, rp, len); + if (err) + ip6_flush_pending_frames(sk); + } } done: ip6_dst_store(sk, dst, --=_mixed 00663E1988256FE3_= Content-Type: application/octet-stream; name="rawv6-2.patch" Content-Disposition: attachment; filename="rawv6-2.patch" Content-Transfer-Encoding: base64 LS0tIGxpbnV4LTIuNi4xMS43L25ldC9pcHY2L3Jhdy5jCTIwMDUtMDQtMDcgMTE6NTc6MzIuMDAw MDAwMDAwIC0wNzAwCisrKyBsaW51eC0yLjYuMTEuN1QxL25ldC9pcHY2L3Jhdy5jCTIwMDUtMDQt MTIgMTU6MDU6MDAuMDAwMDAwMDAwIC0wNzAwCkBAIC03NzEsOCArNzkwLDExIEBAIGJhY2tfZnJv bV9jb25maXJtOgogCiAJCWlmIChlcnIpCiAJCQlpcDZfZmx1c2hfcGVuZGluZ19mcmFtZXMoc2sp OwotCQllbHNlIGlmICghKG1zZy0+bXNnX2ZsYWdzICYgTVNHX01PUkUpKQorCQllbHNlIGlmICgh KG1zZy0+bXNnX2ZsYWdzICYgTVNHX01PUkUpKSB7CiAJCQllcnIgPSByYXd2Nl9wdXNoX3BlbmRp bmdfZnJhbWVzKHNrLCAmZmwsIHJwLCBsZW4pOworCQkJaWYgKGVycikKKwkJCQlpcDZfZmx1c2hf cGVuZGluZ19mcmFtZXMoc2spOworCQl9CiAJfQogZG9uZToKIAlpcDZfZHN0X3N0b3JlKHNrLCBk c3QsCg== --=_mixed 00663E1988256FE3_=-- From shawn.starr@rogers.com Thu Apr 14 13:24:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 13:24:11 -0700 (PDT) Received: from web88006.mail.re2.yahoo.com (web88006.mail.re2.yahoo.com [206.190.37.193]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3EKNxU9017711 for ; Thu, 14 Apr 2005 13:24:00 -0700 Message-ID: <20050414202354.22785.qmail@web88006.mail.re2.yahoo.com> Received: from [192.219.104.10] by web88006.mail.re2.yahoo.com via HTTP; Thu, 14 Apr 2005 16:23:54 EDT Date: Thu, 14 Apr 2005 16:23:54 -0400 (EDT) From: Shawn Starr Subject: [2.6.12-rc2][panic][NET] qdisc_restart - When loading ipw2200 driver To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 21273 Lines: 526 Here's the dmesg/panic dump: Any problems with the Network scheduling in 2.6.12-rc2? [4294667.296000] Linux version 2.6.12-rc2 (root@segfault) (gcc version 4.0.0 20050319 (prerelease)) #1 Wed Apr 13 11:38:19 EDT 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable) [4294667.296000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) [4294667.296000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [4294667.296000] BIOS-e820: 0000000000100000 - 000000003ff60000 (usable) [4294667.296000] BIOS-e820: 000000003ff60000 - 000000003ff77000 (ACPI data) [4294667.296000] BIOS-e820: 000000003ff77000 - 000000003ff79000 (ACPI NVS) [4294667.296000] BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) [4294667.296000] BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) [4294667.296000] 127MB HIGHMEM available. [4294667.296000] 896MB LOWMEM available. [4294667.296000] DMI present. [4294667.296000] ACPI: PM-Timer IO Port: 0x1008 [4294667.296000] Allocating PCI resources starting at 40000000 (gap: 40000000:bf800000) [4294667.296000] Built 1 zonelists [4294667.296000] Kernel command line: root=/dev/hda1 ro acpi_sleep=s3_bios hdc=ide-cd lapic netconsole=@172.25.244.212/eth0,9353@172.25.244.222/00:0D:60:3C:3A:3F [4294667.296000] ide_setup: hdc=ide-cd [4294667.296000] netconsole: local port 6665 [4294667.296000] netconsole: local IP 172.25.244.212 [4294667.296000] netconsole: interface eth0 [4294667.296000] netconsole: remote port 9353 [4294667.296000] netconsole: remote IP 172.25.244.222 [4294667.296000] netconsole: remote ethernet address 00:0d:60:3c:3a:3f [4294667.296000] Local APIC disabled by BIOS -- reenabling. [4294667.296000] Found and enabled local APIC! [4294667.296000] Initializing CPU#0 [4294667.296000] CPU 0 irqstacks, hard=c060a000 soft=c0609000 [4294667.296000] PID hash table entries: 4096 (order: 12, 65536 bytes) [4294667.296000] Detected 1798.930 MHz processor. [4294667.296000] Using pmtmr for high-res timesource [4294667.296000] Console: colour VGA+ 80x25 [4294670.127000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [4294670.127000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [4294670.160000] Memory: 1032876k/1047936k available (3693k kernel code, 14480k reserved, 1200k data, 236k init, 130432k highmem) [4294670.160000] Checking if this processor honours the WP bit even in supervisor mode... Ok. [4294670.183000] Mount-cache hash table entries: 512 [4294670.183000] CPU: L1 I cache: 32K, L1 D cache: 32K [4294670.183000] CPU: L2 cache: 2048K [4294670.183000] Intel machine check architecture supported. [4294670.183000] Intel machine check reporting enabled on CPU#0. [4294670.183000] CPU: Intel(R) Pentium(R) M processor 1.80GHz stepping 06 [4294670.183000] Enabling fast FPU save and restore... done. [4294670.183000] Enabling unmasked SIMD FPU exception support... done. [4294670.183000] Checking 'hlt' instruction... OK. [4294670.187000] tbxface-0118 [02] acpi_load_tables : ACPI Tables successfully acquired [4294670.399000] Parsing all Control Methods:................................................................................................................................................................................................................................................................................................................................................................................................................... [4294670.869000] Table [DSDT](id F005) - 1342 Objects with 64 Devices 403 Methods 19 Regions [4294670.869000] Parsing all Control Methods:. [4294670.870000] Table [SSDT](id F003) - 1 Objects with 0 Devices 1 Methods 0 Regions [4294670.870000] ACPI Namespace successfully loaded at root c0632620 [4294670.870000] ACPI: setting ELCR to 0200 (from 0e28) [4294670.880000] evxfevnt-0094 [03] acpi_enable : Transition to ACPI mode successful [4294670.982000] NET: Registered protocol family 16 [4294670.983000] PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8 [4294670.983000] PCI: Using configuration type 1 [4294670.983000] mtrr: v2.0 (20020519) [4294670.991000] ACPI: Subsystem revision 20050309 [4294671.006000] evgpeblk-0979 [06] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x9 [4294671.006000] evgpeblk-0987 [06] ev_create_gpe_block : Found 7 Wake, Enabled 0 Runtime GPEs in this block [4294671.007000] ACPI: Found ECDT [4294671.017000] Completing Region/Field/Buffer/Package initialization:............................................................................................................................................................................................................................................................ [4294671.249000] Initialized 18/19 Regions 123/123 Fields 72/72 Buffers 39/46 Packages (1352 nodes) [4294671.249000] Executing all Device _STA and_INI methods:.............................................................. [4294671.560000] 62 Devices found containing: 62 _STA, 8 _INI methods [4294671.560000] ACPI: Interpreter enabled [4294671.560000] ACPI: Using PIC for interrupt routing [4294671.584000] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11) [4294671.607000] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11) [4294671.630000] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11) [4294671.652000] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) [4294671.669000] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.687000] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.704000] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.726000] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 9 10 11) [4294671.736000] ACPI: PCI Root Bridge [PCI0] (0000:00) [4294671.736000] PCI: Probing PCI hardware (bus 00) [4294671.737000] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [4294671.738000] PCI: Transparent bridge - 0000:00:1e.0 [4294671.772000] ACPI: Embedded Controller [EC] (gpe 28) [4294671.777000] ACPI: Power Resource [PUBS] (on) [4294671.857000] Linux Plug and Play Support v0.97 (c) Adam Belay [4294671.857000] pnp: PnP ACPI init [4294671.977000] pnp: PnP ACPI: found 12 devices [4294671.977000] PnPBIOS: Disabled by ACPI PNP [4294671.979000] SCSI subsystem initialized [4294671.979000] Linux Kernel Card Services [4294671.979000] options: [pci] [cardbus] [pm] [4294671.980000] usbcore: registered new driver usbfs [4294671.980000] usbcore: registered new driver hub [4294671.980000] PCI: Using ACPI for IRQ routing [4294671.980000] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [4294671.991000] NET: Registered protocol family 23 [4294671.992000] Bluetooth: Core ver 2.7 [4294671.992000] NET: Registered protocol family 31 [4294671.992000] Bluetooth: HCI device and connection manager initialized [4294671.992000] Bluetooth: HCI socket layer initialized [4294672.027000] Simple Boot Flag at 0x35 set to 0x1 [4294672.027000] Machine check exception polling timer started. [4294672.028000] IA-32 Microcode Update Driver: v1.14 [4294672.034000] highmem bounce pool size: 64 pages [4294672.034000] Initializing Cryptographic API [4294672.034000] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [4294672.034000] ibmphpd: IBM Hot Plug PCI Controller Driver version: 0.6 [4294672.034000] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.4 [4294672.074000] acpiphp: Slot [4294967295] registered [4294672.205000] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [4294672.206000] ACPI: AC Adapter [AC] (on-line) [4294672.297000] ACPI: Battery Slot [BAT0] (battery present) [4294672.297000] ACPI: Power Button (FF) [PWRF] [4294672.297000] ACPI: Lid Switch [LID] [4294672.297000] ACPI: Sleep Button (CM) [SLPB] [4294672.307000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [4294672.316000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [4294672.316000] ACPI: Processor [CPU] (supports 8 throttling states) [4294672.335000] ACPI: Thermal Zone [THM0] (49 C) [4294672.335000] ibm_acpi: IBM ThinkPad ACPI Extras v0.8 [4294672.335000] ibm_acpi: http://ibm-acpi.sf.net/ [4294672.344000] acpi_bus-0077 [95] acpi_bus_get_device : No context for object [c1905d24] [4294672.344000] ibm_acpi: dock device not present [4294672.349000] isapnp: Scanning for PnP cards... [4294672.703000] isapnp: No Plug & Play device found [4294672.758000] lp: driver loaded but no devices found [4294672.759000] Real Time Clock Driver v1.12 [4294672.759000] Non-volatile memory driver v1.2 [4294672.759000] hw_random: RNG not detected [4294672.759000] Linux agpgart interface v0.101 (c) Dave Jones [4294672.759000] agpgart: Detected an Intel 855PM Chipset. [4294672.773000] agpgart: AGP aperture is 256M @ 0xd0000000 [4294672.773000] Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60 seconds). [4294672.774000] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [4294672.779000] serio: i8042 AUX port at 0x60,0x64 irq 12 [4294672.780000] serio: i8042 KBD port at 0x60,0x64 irq 1 [4294672.805000] pnp: Device 00:09 activated. [4294672.805000] parport: PnPBIOS parport detected. [4294672.805000] parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE] [4294672.887000] lp0: using parport0 (interrupt-driven). [4294672.887000] io scheduler noop registered [4294672.887000] io scheduler anticipatory registered [4294672.887000] io scheduler deadline registered [4294672.887000] io scheduler cfq registered [4294672.888000] loop: loaded (max 8 devices) [4294672.888000] pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com [4294672.888000] Intel(R) PRO/1000 Network Driver - version 5.7.6-k2-NAPI [4294672.888000] Copyright (c) 1999-2004 Intel Corporation. [4294672.907000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9 [4294672.907000] PCI: setting IRQ 9 as level-triggered [4294672.907000] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294673.182000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [4294674.794000] e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Half Duplex [4294674.799000] netconsole: network logging started [4294674.799000] Linux video capture interface: v1.00 [4294674.799000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [4294674.799000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [4294674.800000] ICH4: IDE controller at PCI slot 0000:00:1f.1 [4294674.800000] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) [4294674.819000] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 [4294674.819000] PCI: setting IRQ 10 as level-triggered [4294674.819000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294674.819000] ICH4: chipset revision 1 [4294674.819000] ICH4: not 100% native mode: will probe irqs later [4294674.819000] ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio [4294674.819000] ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio [4294675.083000] hda: HTS548080M9AT00, ATA DISK drive [4294675.695000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [4294676.367000] hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4242N, ATAPI CD/DVD-ROM drive [4294676.674000] ide1 at 0x170-0x177,0x376 on irq 15 [4294676.674000] hda: max request size: 128KiB [4294676.691000] hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=65535/16/63, UDMA(100) [4294676.691000] hda: cache flushes supported [4294676.691000] hda: hda1 hda2 hda3 [4294676.710000] hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) [4294676.710000] Uniform CD-ROM driver Revision: 3.20 [4294676.721000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294676.721000] Yenta: CardBus bridge found at 0000:02:00.0 [1014:0552] [4294676.721000] Yenta: Using INTVAL to route CSC interrupts to PCI [4294676.721000] Yenta: Routing CardBus interrupts to PCI [4294676.721000] Yenta TI: socket 0000:02:00.0, mfunc 0x01d21b22, devctl 0x64 [4294676.942000] Yenta: ISA IRQ mask 0x0878, PCI irq 9 [4294676.942000] Socket status: 30000086 [4294677.211000] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 [4294677.211000] PCI: setting IRQ 5 as level-triggered [4294677.211000] ACPI: PCI Interrupt 0000:02:00.1[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [4294677.211000] Yenta: CardBus bridge found at 0000:02:00.1 [1014:0552] [4294677.211000] Yenta: Using INTVAL to route CSC interrupts to PCI [4294677.211000] Yenta: Routing CardBus interrupts to PCI [4294677.211000] Yenta TI: socket 0000:02:00.1, mfunc 0x01d21b22, devctl 0x64 [4294677.432000] Yenta: ISA IRQ mask 0x0858, PCI irq 5 [4294677.432000] Socket status: 30000086 [4294677.701000] ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 3 [4294677.701000] PCI: setting IRQ 3 as level-triggered [4294677.701000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 3 (level, low) -> IRQ 3 [4294677.701000] ehci_hcd 0000:00:1d.7: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [4294677.701000] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 [4294677.701000] ehci_hcd 0000:00:1d.7: irq 3, io mem 0xc0000000 [4294677.705000] ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 [4294677.705000] usb usb1: Product: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [4294677.706000] usb usb1: Manufacturer: Linux 2.6.12-rc2 ehci_hcd [4294677.706000] usb usb1: SerialNumber: 0000:00:1d.7 [4294677.706000] hub 1-0:1.0: USB hub found [4294677.706000] hub 1-0:1.0: 6 ports detected [4294677.727000] USB Universal Host Controller Interface driver v2.2 [4294677.727000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294677.727000] uhci_hcd 0000:00:1d.0: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [4294677.789000] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 [4294677.789000] uhci_hcd 0000:00:1d.0: irq 9, io base 0x00001800 [4294677.789000] uhci_hcd 0000:00:1d.0: detected 2 ports [4294677.789000] usb usb2: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [4294677.789000] usb usb2: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.789000] usb usb2: SerialNumber: 0000:00:1d.0 [4294677.789000] hub 2-0:1.0: USB hub found [4294677.789000] hub 2-0:1.0: 2 ports detected [4294677.810000] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 [4294677.810000] PCI: setting IRQ 11 as level-triggered [4294677.810000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [4294677.810000] uhci_hcd 0000:00:1d.1: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [4294677.872000] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 [4294677.872000] uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001820 [4294677.872000] uhci_hcd 0000:00:1d.1: detected 2 ports [4294677.872000] usb usb3: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [4294677.872000] usb usb3: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.872000] usb usb3: SerialNumber: 0000:00:1d.1 [4294677.872000] hub 3-0:1.0: USB hub found [4294677.872000] hub 3-0:1.0: 2 ports detected [4294677.875000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294677.875000] uhci_hcd 0000:00:1d.2: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [4294677.937000] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 [4294677.937000] uhci_hcd 0000:00:1d.2: irq 10, io base 0x00001840 [4294677.937000] uhci_hcd 0000:00:1d.2: detected 2 ports [4294677.937000] usb usb4: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [4294677.937000] usb usb4: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.937000] usb usb4: SerialNumber: 0000:00:1d.2 [4294677.937000] hub 4-0:1.0: USB hub found [4294677.937000] hub 4-0:1.0: 2 ports detected [4294677.940000] usbcore: registered new driver hiddev [4294677.940000] usbcore: registered new driver usbhid [4294677.940000] drivers/usb/input/hid-core.c: v2.01:USB HID core driver [4294677.940000] mice: PS/2 mouse device common for all mice [4294677.940000] input: PC Speaker [4294677.940000] i2c /dev entries driver [4294677.941000] Advanced Linux Sound Architecture Driver Version 1.0.9rc2 (Thu Mar 24 10:33:39 2005 UTC). [4294677.942000] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [4294677.951000] input: AT Translated Set 2 keyboard on isa0060/serio0 [4294678.569000] Synaptics Touchpad, model: 1 [4294678.569000] Firmware: 5.9 [4294678.569000] Sensor: 44 [4294678.569000] new absolute packet format [4294678.569000] Touchpad has extended capability bits [4294678.569000] -> multifinger detection [4294678.569000] -> palm detection [4294678.569000] -> pass-through port [4294678.569000] serio: Synaptics pass-through port at isa0060/serio1/input0 [4294678.569000] input: SynPS/2 Synaptics TouchPad on isa0060/serio1 [4294678.752000] intel8x0_measure_ac97_clock: measured 49287 usecs [4294678.752000] intel8x0: clocking to 48000 [4294678.753000] ALSA device list: [4294678.753000] #0: Intel 82801DB-ICH4 with AD1981B at 0xc0000c00, irq 5 [4294678.753000] NET: Registered protocol family 2 [4294678.763000] IP: routing cache hash table of 2048 buckets, 64Kbytes [4294678.763000] TCP established hash table entries: 262144 (order: 9, 2097152 bytes) [4294678.766000] TCP bind hash table entries: 65536 (order: 8, 1835008 bytes) [4294678.771000] TCP: Hash tables configured (established 262144 bind 65536) [4294678.771000] NET: Registered protocol family 1 [4294678.771000] NET: Registered protocol family 17 [4294678.947000] swsusp: Suspend partition has wrong signature? [4294678.975000] ACPI wakeup devices: [4294678.975000] LID SLPB PCI0 UART PCI1 USB0 USB1 AC9M [4294678.975000] ACPI: (supports S0 S3 S4 S5) [4294678.976000] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [4294679.005000] EXT3-fs: mounted filesystem with ordered data mode. [4294679.005000] VFS: Mounted root (ext3 filesystem) readonly. [4294679.005000] Freeing unused kernel memory: 236k freed [4294679.005000] kjournald starting. Commit interval 5 seconds [4294682.737000] input: PS/2 Generic Mouse on synaptics-pt/serio0 [4294684.613000] Adding 1050832k swap on /dev/hda3. Priority:-1 extents:1 [4294684.796000] EXT3 FS on hda1, internal journal [4294689.611000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.3 [4294689.611000] ipw2200: Copyright(c) 2003-2004 Intel Corporation [4294689.612000] ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294689.612000] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection [4294692.342000] Unable to handle kernel paging request at virtual address ffffffab [4294692.342000] printing eip: [4294692.342000] ffffffab [4294692.342000] *pde = 00002067 [4294692.342000] Oops: 0000 [#1] [4294692.342000] PREEMPT [4294692.342000] Modules linked in: ipw2200 ieee80211 ieee80211_crypt [4294692.342000] CPU: 0 [4294692.342000] EIP: 0060:[] Not tainted VLI [4294692.342000] EFLAGS: 00010286 (2.6.12-rc2) [4294692.342000] EIP is at 0xffffffab [4294692.342000] eax: f742ec24 ebx: c0609000 ecx: f7712280 edx: f7712000 [4294692.342000] esi: f7712280 edi: f746404c ebp: c0609eec esp: c0609e40 [4294692.342000] ds: 007b es: 007b ss: 0068 [4294692.342000] Process swapper (pid: 0, threadinfo=c0609000 task=c0520c80) [4294692.342000] Stack: f8861d22 c18dd180 f74efa40 c18dd180 f771b000 c0609e88 c0609e8c c0166f12 [4294692.342000] c040c81b f7712000 f7e1ca8c f7712280 f742ec24 00000001 00000912 00000001 [4294692.342000] 00000024 00000286 f7712284 00000000 00000108 f7e216b4 00000000 f7464010 [4294692.342000] Call Trace: [4294692.342000] [] show_stack+0xa6/0xe0 [4294692.342000] [] show_registers+0x15b/0x1f0 [4294692.342000] [] die+0x141/0x2d0 [4294692.342000] [] do_page_fault+0x22e/0x6a6 [4294692.342000] [] error_code+0x4f/0x54 [4294692.342000] [] qdisc_restart+0xba/0x730 [4294692.342000] [] dev_queue_xmit+0x13e/0x640 [4294692.342000] [] arp_solicit+0xfc/0x210 [4294692.342000] [] neigh_timer_handler+0x13e/0x320 [4294692.342000] [] run_timer_softirq+0x130/0x490 [4294692.342000] [] __do_softirq+0x42/0xa0 [4294692.342000] [] do_softirq+0x51/0x60 [4294692.342000] ======================= [4294692.342000] [] irq_exit+0x36/0x40 [4294692.342000] [] do_IRQ+0x5d/0xa0 [4294692.342000] [] common_interrupt+0x1a/0x20 [4294692.342000] [] cpu_idle+0x37/0x50 [4294692.342000] [] start_kernel+0x16a/0x180 [4294692.342000] [] 0xc010019f [4294692.342000] Code: Bad EIP value. [4294692.342000] <0>Kernel panic - not syncing: Fatal exception in interrupt [4294692.343000] From greearb@candelatech.com Thu Apr 14 13:34:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 13:34:35 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EKYROg018830 for ; Thu, 14 Apr 2005 13:34:28 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3EL1oGf022469; Thu, 14 Apr 2005 14:01:52 -0700 Message-ID: <425ED3C9.5090600@candelatech.com> Date: Thu, 14 Apr 2005 13:34:17 -0700 From: Ben Greear User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Venkatesan CC: "netdev@oss.sgi.com" , linux-kernel , Lennert Buytenhek Subject: Re: PCI interrupt problem: e1000 & Super-Micro X6DVA motherboard References: <42421FF2.7050501@candelatech.com> <20050324081003.GA23453@xi.wantstofly.org> <42431734.3030905@candelatech.com> <5fc59ff305041411013fd35ed4@mail.gmail.com> In-Reply-To: <5fc59ff305041411013fd35ed4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1746 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: 647 Lines: 25 Ganesh Venkatesan wrote: >Ben: > >Have you checked if the BIOS on the super micro machine is the latest >and greatest. I have had interrupt routing issues very similar to the >one you are describing due to a BIOS Interrupt Routing issue. Moving >to newer BIOS fixed it. > > A new BIOS didn't help. Super-Micro eventually reproduced the problem, and told me the fix was to send the MB back to them so they could solder another part onto it.... I haven't received the MB back yet so I don't know if they really have a fix for it or not... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From shawn.starr@rogers.com Thu Apr 14 13:55:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 13:55:39 -0700 (PDT) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3EKtWdd019664 for ; Thu, 14 Apr 2005 13:55:32 -0700 Received: from unknown (HELO ?172.25.244.212?) (shawn.starr@192.219.104.10 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 14 Apr 2005 20:55:26 -0000 From: Shawn Starr Organization: sh0n.net Subject: [2.6.12-rc2][panic][NET] qdisc_restart - When loading ipw2200 driver - not mangled Date: Thu, 14 Apr 2005 16:55:21 -0400 User-Agent: KMail/1.7.2 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504141655.21440.shawn.starr@rogers.com> X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 21253 Lines: 332 Here's the dmesg/panic dump: Any problems with the Network scheduling in 2.6.12-rc2? [4294667.296000] Linux version 2.6.12-rc2 (root@segfault) (gcc version 4.0.0 20050319 (prerelease)) #1 Wed Apr 13 11:38:19 EDT 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable) [4294667.296000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) [4294667.296000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [4294667.296000] BIOS-e820: 0000000000100000 - 000000003ff60000 (usable) [4294667.296000] BIOS-e820: 000000003ff60000 - 000000003ff77000 (ACPI data) [4294667.296000] BIOS-e820: 000000003ff77000 - 000000003ff79000 (ACPI NVS) [4294667.296000] BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) [4294667.296000] BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) [4294667.296000] 127MB HIGHMEM available. [4294667.296000] 896MB LOWMEM available. [4294667.296000] DMI present. [4294667.296000] ACPI: PM-Timer IO Port: 0x1008 [4294667.296000] Allocating PCI resources starting at 40000000 (gap: 40000000:bf800000) [4294667.296000] Built 1 zonelists [4294667.296000] Kernel command line: root=/dev/hda1 ro acpi_sleep=s3_bios hdc=ide-cd lapic netconsole=@172.25.244.212/eth0,9353@172.25.244.222/00:0D:60:3C:3A:3F [4294667.296000] ide_setup: hdc=ide-cd [4294667.296000] netconsole: local port 6665 [4294667.296000] netconsole: local IP 172.25.244.212 [4294667.296000] netconsole: interface eth0 [4294667.296000] netconsole: remote port 9353 [4294667.296000] netconsole: remote IP 172.25.244.222 [4294667.296000] netconsole: remote ethernet address 00:0d:60:3c:3a:3f [4294667.296000] Local APIC disabled by BIOS -- reenabling. [4294667.296000] Found and enabled local APIC! [4294667.296000] Initializing CPU#0 [4294667.296000] CPU 0 irqstacks, hard=c060a000 soft=c0609000 [4294667.296000] PID hash table entries: 4096 (order: 12, 65536 bytes) [4294667.296000] Detected 1798.930 MHz processor. [4294667.296000] Using pmtmr for high-res timesource [4294667.296000] Console: colour VGA+ 80x25 [4294670.127000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [4294670.127000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [4294670.160000] Memory: 1032876k/1047936k available (3693k kernel code, 14480k reserved, 1200k data, 236k init, 130432k highmem) [4294670.160000] Checking if this processor honours the WP bit even in supervisor mode... Ok. [4294670.183000] Mount-cache hash table entries: 512 [4294670.183000] CPU: L1 I cache: 32K, L1 D cache: 32K [4294670.183000] CPU: L2 cache: 2048K [4294670.183000] Intel machine check architecture supported. [4294670.183000] Intel machine check reporting enabled on CPU#0. [4294670.183000] CPU: Intel(R) Pentium(R) M processor 1.80GHz stepping 06 [4294670.183000] Enabling fast FPU save and restore... done. [4294670.183000] Enabling unmasked SIMD FPU exception support... done. [4294670.183000] Checking 'hlt' instruction... OK. [4294670.187000] tbxface-0118 [02] acpi_load_tables : ACPI Tables successfully acquired [4294670.399000] Parsing all Control Methods:.................................................................................................................................................. .......................................................................................................................................................... ....................................................................................................... [4294670.869000] Table [DSDT](id F005) - 1342 Objects with 64 Devices 403 Methods 19 Regions [4294670.869000] Parsing all Control Methods:. [4294670.870000] Table [SSDT](id F003) - 1 Objects with 0 Devices 1 Methods 0 Regions [4294670.870000] ACPI Namespace successfully loaded at root c0632620 [4294670.870000] ACPI: setting ELCR to 0200 (from 0e28) [4294670.880000] evxfevnt-0094 [03] acpi_enable : Transition to ACPI mode successful [4294670.982000] NET: Registered protocol family 16 [4294670.983000] PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8 [4294670.983000] PCI: Using configuration type 1 [4294670.983000] mtrr: v2.0 (20020519) [4294670.991000] ACPI: Subsystem revision 20050309 [4294671.006000] evgpeblk-0979 [06] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x9 [4294671.006000] evgpeblk-0987 [06] ev_create_gpe_block : Found 7 Wake, Enabled 0 Runtime GPEs in this block [4294671.007000] ACPI: Found ECDT [4294671.017000] Completing Region/Field/Buffer/Package initialization:.............................................................. .......................................................................................................................................................... .................................... [4294671.249000] Initialized 18/19 Regions 123/123 Fields 72/72 Buffers 39/46 Packages (1352 nodes) [4294671.249000] Executing all Device _STA and_INI methods:.............................................................. [4294671.560000] 62 Devices found containing: 62 _STA, 8 _INI methods [4294671.560000] ACPI: Interpreter enabled [4294671.560000] ACPI: Using PIC for interrupt routing [4294671.584000] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11) [4294671.607000] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11) [4294671.630000] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11) [4294671.652000] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) [4294671.669000] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.687000] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.704000] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [4294671.726000] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 9 10 11) [4294671.736000] ACPI: PCI Root Bridge [PCI0] (0000:00) [4294671.736000] PCI: Probing PCI hardware (bus 00) [4294671.737000] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [4294671.738000] PCI: Transparent bridge - 0000:00:1e.0 [4294671.772000] ACPI: Embedded Controller [EC] (gpe 28) [4294671.777000] ACPI: Power Resource [PUBS] (on) [4294671.857000] Linux Plug and Play Support v0.97 (c) Adam Belay [4294671.857000] pnp: PnP ACPI init [4294671.977000] pnp: PnP ACPI: found 12 devices [4294671.977000] PnPBIOS: Disabled by ACPI PNP [4294671.979000] SCSI subsystem initialized [4294671.979000] Linux Kernel Card Services [4294671.979000] options: [pci] [cardbus] [pm] [4294671.980000] usbcore: registered new driver usbfs [4294671.980000] usbcore: registered new driver hub [4294671.980000] PCI: Using ACPI for IRQ routing [4294671.980000] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [4294671.991000] NET: Registered protocol family 23 [4294671.992000] Bluetooth: Core ver 2.7 [4294671.992000] NET: Registered protocol family 31 [4294671.992000] Bluetooth: HCI device and connection manager initialized [4294671.992000] Bluetooth: HCI socket layer initialized [4294672.027000] Simple Boot Flag at 0x35 set to 0x1 [4294672.027000] Machine check exception polling timer started. [4294672.028000] IA-32 Microcode Update Driver: v1.14 [4294672.034000] highmem bounce pool size: 64 pages [4294672.034000] Initializing Cryptographic API [4294672.034000] pci_hotplug: PCI Hot Plug PCI Coreversion: 0.5 [4294672.034000] ibmphpd: IBM Hot Plug PCI Control ler Driver version: 0.6 [4294672.034000] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.4 [4294672.074000] acpiphp: Slot [4294967295] registered [4294672.205000] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [4294672.206000] ACPI: AC Adapter [AC] (on-line) [4294672.297000] ACPI: Battery Slot [BAT0] (battery present) [4294672.297000] ACPI: Power Button (FF) [PWRF] [4294672.297000] ACPI: Lid Switch [LID] [4294672.297000] ACPI: Sleep Button (CM) [SLPB] [4294672.307000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [4294672.316000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [4294672.316000] ACPI: Processor [CPU] (supports 8 throttling states) [4294672.335000] ACPI: Thermal Zone [THM0] (49 C) [4294672.335000] ibm_acpi: IBM ThinkPad ACPI Extras v0.8 [4294672.335000] ibm_acpi: http://ibm-acpi.sf.net/ [4294672.344000] acpi_bus-0077 [95] acpi_bus_get_device : No context for object [c1905d24] [4294672.344000] ibm_acpi: dock device not present [4294672.349000] isapnp: Scanning for PnP cards... [4294672.703000] isapnp: No Plug & Play device found [4294672.758000] lp: driver loaded but no devices found [4294672.759000] Real Time Clock Driver v1.12 [4294672.759000] Non-volatile memory driver v1.2 [4294672.759000] hw_random: RNG not detected [4294672.759000] Linux agpgart interface v0.101 (c)Dave Jones [4294672.759000] agpgart: Detected an Intel 855PM Chipset. [4294672.773000] agpgart: AGP aperture is 256M @ 0xd0000000 [4294672.773000] Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60 seconds). [4294672.774000] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [4294672.779000] serio: i8042 AUX port at 0x60,0x64 irq 12 [4294672.780000] serio: i8042 KBD port at 0x60,0x64 irq 1 [4294672.805000] pnp: Device 00:09 activated. [4294672.805000] parport: PnPBIOS parport detected. [4294672.805000] parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE] [4294672.887000] lp0: using parport0 (interrupt-driven). [4294672.887000] io scheduler noop registered [4294672.887000] io scheduler anticipatory registered [4294672.887000] io scheduler deadline registered [4294672.887000] io scheduler cfq registered [4294672.888000] loop: loaded (max 8 devices) [4294672.888000] pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com [4294672.888000] Intel(R) PRO/1000 Network Driver - version 5.7.6-k2-NAPI [4294672.888000] Copyright (c) 1999-2004 Intel Corporation. [4294672.907000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9 [4294672.907000] PCI: setting IRQ 9 as level-triggered [4294672.907000] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294673.182000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [4294674.794000] e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Half Duplex [4294674.799000] netconsole: network logging started [4294674.799000] Linux video capture interface: v1.00 [4294674.799000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [4294674.799000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [4294674.800000] ICH4: IDE controller at PCI slot 0000:00:1f.1 [4294674.800000] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) [4294674.819000] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 [4294674.819000] PCI: setting IRQ 10 as level-triggered [4294674.819000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294674.819000] ICH4: chipset revision 1 [4294674.819000] ICH4: not 100% native mode: will probe irqs later [4294674.819000] ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio [4294674.819000] ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio [4294675.083000] hda: HTS548080M9AT00, ATA DISK drive [4294675.695000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [4294676.367000] hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4242N, ATAPI CD/DVD-ROM drive [4294676.674000] ide1 at 0x170-0x177,0x376 on irq 15 [4294676.674000] hda: max request size: 128KiB [4294676.691000] hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=65535/16/63, UDMA(100) [4294676.691000] hda: cache flushes supported [4294676.691000] hda: hda1 hda2 hda3 [4294676.710000] hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) [4294676.710000] Uniform CD-ROM driver Revision: 3.20 [4294676.721000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294676.721000] Yenta: CardBus bridge found at 0000:02:00.0 [1014:0552] [4294676.721000] Yenta: Using INTVAL to route CSC interrupts to PCI [4294676.721000] Yenta: Routing CardBus interrupts to PCI [4294676.721000] Yenta TI: socket 0000:02:00.0, mfunc 0x01d21b22, devctl 0x64 [4294676.942000] Yenta: ISA IRQ mask 0x0878, PCI irq 9 [4294676.942000] Socket status: 30000086 [4294677.211000] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 [4294677.211000] PCI: setting IRQ 5 as level-triggered [4294677.211000] ACPI: PCI Interrupt 0000:02:00.1[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [4294677.211000] Yenta: CardBus bridge found at 0000:02:00.1 [1014:0552] [4294677.211000] Yenta: Using INTVAL to route CSC interrupts to PCI [4294677.211000] Yenta: Routing CardBus interrupts to PCI [4294677.211000] Yenta TI: socket 0000:02:00.1, mfunc 0x01d21b22, devctl 0x64 [4294677.432000] Yenta: ISA IRQ mask 0x0858, PCI irq 5 [4294677.432000] Socket status: 30000086 [4294677.701000] ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 3 [4294677.701000] PCI: setting IRQ 3 as level-triggered [4294677.701000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 3 (level, low) -> IRQ 3 [4294677.701000] ehci_hcd 0000:00:1d.7: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [4294677.701000] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 [4294677.701000] ehci_hcd 0000:00:1d.7: irq 3, io mem 0xc0000000 [4294677.705000] ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 [4294677.705000] usb usb1: Product: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [4294677.706000] usb usb1: Manufacturer: Linux 2.6.12-rc2 ehci_hcd [4294677.706000] usb usb1: SerialNumber: 0000:00:1d.7 [4294677.706000] hub 1-0:1.0: USB hub found [4294677.706000] hub 1-0:1.0: 6 ports detected [4294677.727000] USB Universal Host Controller Interface driver v2.2 [4294677.727000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [4294677.727000] uhci_hcd 0000:00:1d.0: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [4294677.789000] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 [4294677.789000] uhci_hcd 0000:00:1d.0: irq 9, io base 0x00001800 [4294677.789000] uhci_hcd 0000:00:1d.0: detected 2 ports [4294677.789000] usb usb2: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [4294677.789000] usb usb2: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.789000] usb usb2: SerialNumber: 0000:00:1d.0 [4294677.789000] hub 2-0:1.0: USB hub found [4294677.789000] hub 2-0:1.0: 2 ports detected [4294677.810000] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 [4294677.810000] PCI: setting IRQ 11 as level-triggered [4294677.810000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [4294677.810000] uhci_hcd 0000:00:1d.1: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [4294677.872000] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 [4294677.872000] uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001820 [4294677.872000] uhci_hcd 0000:00:1d.1: detected 2 ports [4294677.872000] usb usb3: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [4294677.872000] usb usb3: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.872000] usb usb3: SerialNumber: 0000:00:1d.1 [4294677.872000] hub 3-0:1.0: USB hub found [4294677.872000] hub 3-0:1.0: 2 ports detected [4294677.875000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294677.875000] uhci_hcd 0000:00:1d.2: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [4294677.937000] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 [4294677.937000] uhci_hcd 0000:00:1d.2: irq 10, io base 0x00001840 [4294677.937000] uhci_hcd 0000:00:1d.2: detected 2 ports [4294677.937000] usb usb4: Product: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [4294677.937000] usb usb4: Manufacturer: Linux 2.6.12-rc2 uhci_hcd [4294677.937000] usb usb4: SerialNumber: 0000:00:1d.2 [4294677.937000] hub 4-0:1.0: USB hub found [4294677.937000] hub 4-0:1.0: 2 ports detected [4294677.940000] usbcore: registered new driver hiddev [4294677.940000] usbcore: registered new driver usbhid [4294677.940000] drivers/usb/input/hid-core.c: v2.01:USB HID core driver [4294677.940000] mice: PS/2 mouse device common for all mice [4294677.940000] input: PC Speaker [4294677.940000] i2c /dev entries driver [4294677.941000] Advanced Linux Sound Architecture Driver Version 1.0.9rc2 (Thu Mar 24 10:33:39 2005 UTC). [4294677.942000] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [4294677.951000] input: AT Translated Set 2 keyboard on isa0060/serio0 [4294678.569000] Synaptics Touchpad, model: 1 [4294678.569000] Firmware: 5.9 [4294678.569000] Sensor: 44 [4294678.569000] new absolute packet format [4294678.569000] Touchpad has extended capability bits [4294678.569000] -> multifinger detection [4294678.569000] -> palm detection [4294678.569000] -> pass-through port [4294678.569000] serio: Synaptics pass-through port at isa0060/serio1/input0 [4294678.569000] input: SynPS/2 Synaptics TouchPad on isa0060/serio1 [4294678.752000] intel8x0_measure_ac97_clock: measured 49287 usecs [4294678.752000] intel8x0: clocking to 48000 [4294678.753000] ALSA device list: [4294678.753000] #0: Intel 82801DB-ICH4 with AD1981B at 0xc0000c00, irq 5 [4294678.753000] NET: Registered protocol family 2 [4294678.763000] IP: routing cache hash table of 2048 buckets, 64Kbytes [4294678.763000] TCP established hash table entries: 262144 (order: 9, 2097152 bytes) [4294678.766000] TCP bind hash table entries: 65536 (order: 8, 1835008 bytes) [4294678.771000] TCP: Hash tables configured (established 262144 bind 65536) [4294678.771000] NET: Registered protocol family 1 [4294678.771000] NET: Registered protocol family 17 [4294678.947000] swsusp: Suspend partition has wrong signature? [4294678.975000] ACPI wakeup devices: [4294678.975000] LID SLPB PCI0 UART PCI1 USB0 USB1 AC9M [4294678.975000] ACPI: (supports S0 S3 S4 S5) [4294678.976000] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [4294679.005000] EXT3-fs: mounted filesystem with ordered data mode. [4294679.005000] VFS: Mounted root (ext3 filesystem) readonly. [4294679.005000] Freeing unused kernel memory: 236k freed [4294679.005000] kjournald starting. Commit interval 5 seconds [4294682.737000] input: PS/2 Generic Mouse on synaptics-pt/serio0 [4294684.613000] Adding 1050832k swap on /dev/hda3. Priority:-1 extents:1 [4294684.796000] EXT3 FS on hda1, internal journal [4294689.611000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.3 [4294689.611000] ipw2200: Copyright(c) 2003-2004 Intel Corporation [4294689.612000] ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 [4294689.612000] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection [4294692.342000] Unable to handle kernel paging request at virtual address ffffffab [4294692.342000] printing eip: [4294692.342000] ffffffab [4294692.342000] *pde = 00002067 [4294692.342000] Oops: 0000 [#1] [4294692.342000] PREEMPT [4294692.342000] Modules linked in: ipw2200 ieee80211 ieee80211_crypt [4294692.342000] CPU: 0 [4294692.342000] EIP: 0060:[] Not tainted VLI [4294692.342000] EFLAGS: 00010286 (2.6.12-rc2) [4294692.342000] EIP is at 0xffffffab [4294692.342000] eax: f742ec24 ebx: c0609000 ecx: f7712280 edx: f7712000 [4294692.342000] esi: f7712280 edi: f746404c ebp: c0609eec esp: c0609e40 [4294692.342000] ds: 007b es: 007b ss: 0068 [4294692.342000] Process swapper (pid: 0, threadinfo=c0609000 task=c0520c80) [4294692.342000] Stack: f8861d22 c18dd180 f74efa40 c18dd180 f771b000 c0609e88 c0609e8c c0166f12 [4294692.342000] c040c81b f7712000 f7e1ca8c f7712280 f742ec24 00000001 00000912 00000001 [4294692.342000] 00000024 00000286 f7712284 00000000 00000108 f7e216b4 00000000 f7464010 [4294692.342000] Call Trace: [4294692.342000] [] show_stack+0xa6/0xe0 [4294692.342000] [] show_registers+0x15b/0x1f0 [4294692.342000] [] die+0x141/0x2d0 [4294692.342000] [] do_page_fault+0x22e/0x6a6 [4294692.342000] [] error_code+0x4f/0x54 [4294692.342000] [] qdisc_restart+0xba/0x730 [4294692.342000] [] dev_queue_xmit+0x13e/0x640 [4294692.342000] [] arp_solicit+0xfc/0x210 [4294692.342000] [] neigh_timer_handler+0x13e/0x320 [4294692.342000] [] run_timer_softirq+0x130/0x490 [4294692.342000] [] __do_softirq+0x42/0xa0 [4294692.342000] [] do_softirq+0x51/0x60 [4294692.342000] ======================= [4294692.342000] [] irq_exit+0x36/0x40 [4294692.342000] [] do_IRQ+0x5d/0xa0 [4294692.342000] [] common_interrupt+0x1a/0x20 [4294692.342000] [] cpu_idle+0x37/0x50 [4294692.342000] [] start_kernel+0x16a/0x180 [4294692.342000] [] 0xc010019f [4294692.342000] Code: Bad EIP value. [4294692.342000] <0>Kernel panic - not syncing: Fatal exception in interrupt [4294692.343000] From herbert@gondor.apana.org.au Thu Apr 14 14:32:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 14:32:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ELW9Qs021051 for ; Thu, 14 Apr 2005 14:32:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMBw5-0001xC-00; Fri, 15 Apr 2005 07:31:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMBv6-0005mS-00; Fri, 15 Apr 2005 07:30:40 +1000 Date: Fri, 15 Apr 2005 07:30:40 +1000 To: David Stevens Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory Message-ID: <20050414213040.GA21276@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1441 Lines: 34 On Thu, Apr 14, 2005 at 12:36:46PM -0600, David Stevens wrote: > > Below is a piece of my original patch that I've separated out to make sure > it doesn't get lost in this discussion. It's the fix for the bug that > triggered all > of this and the real cause of the panic for the ordinary raw-socket cases, > where > nr_frags is supposed to be "0". Attached and in-line below. Thanks. Actually I did include it in my patch too. > A couple comments initially on your patch: multiple packet support I don't > think is needed here (in sendmsg). I agree it's good to put it in for > other > possible uses, but IPV6_CHECKSUM doesn't need it, as far as I can tell. Multiple packets will exist on the queue when the user has written more than one MTU worth of data. > How about a loop instead of a recursive call? If the list is long enough > and the architecture eats stack a lot of stack space on function calls, > that could be a problem. You mean where skb_store_bits calls itself? This can only recurse once at most. In fact, in this particular instance it will not recurse at all since the fragments aren't chained together (the chaining occurs in ip6_push_pending_frames). This is how skb_copy_bits works too. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dlstevens@us.ibm.com Thu Apr 14 15:43:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 15:44:05 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EMhqjt022990 for ; Thu, 14 Apr 2005 15:43:58 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3EMhe5j516710 for ; Thu, 14 Apr 2005 18:43:40 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3EMheqi229524 for ; Thu, 14 Apr 2005 16:43:40 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EMhdNa007285 for ; Thu, 14 Apr 2005 16:43:40 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EMhdon007282; Thu, 14 Apr 2005 16:43:39 -0600 In-Reply-To: <20050414213040.GA21276@gondor.apana.org.au> To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 14 Apr 2005 15:43:37 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/14/2005 16:43:38, Serialize complete at 04/14/2005 16:43:38 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1749 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: 2455 Lines: 52 Herbert Xu wrote on 04/14/2005 02:30:40 PM: > Thanks. Actually I did include it in my patch too. Yes, I just saw this -- at lower layer. I prefer the flush up in sendmsg, since 1) that's where the other error case is done and 2) that's where the append happens. But I could go either way. > > A couple comments initially on your patch: multiple packet support I don't > > think is needed here (in sendmsg). I agree it's good to put it in for > > other > > possible uses, but IPV6_CHECKSUM doesn't need it, as far as I can tell. > Multiple packets will exist on the queue when the user has written > more than one MTU worth of data. I think the fragmentation happens in the IPv6 layer, so only memory fragmentation can happen from sendmsg (as far as I can tell). Meaning the frags array can have multiple buffers, but I'm not sure the frag_list can have anything on it. In my testing, I wrote a 2K packet (on Ethernet w/ 1500 MTU) and it all appeared in a single skb (in fact, all contiguous, in the head). The nr_frags != 0 only happened with multiple sendmsgs when the write queue had not been flushed, but I expect it can happen in other cases (e.g., corking). Unless I'm wrong, I think the frag_list stuff will only be filled at the (lower) IPv6 layer. It accounts for the fragment header length in the initial allocation if it will need to fragment, but doesn't appear to allocate the skbs as separate frags based on MTU. I may be reading it wrong, too, of course. :-) > > How about a loop instead of a recursive call? If the list is long enough > > and the architecture eats stack a lot of stack space on function calls, > > that could be a problem. > You mean where skb_store_bits calls itself? This can only recurse once > at most. In fact, in this particular instance it will not recurse at > all since the fragments aren't chained together (the chaining occurs in > ip6_push_pending_frames). This is how skb_copy_bits works too. Yeah, I wrote a non-recursive version of skb_store_bits, but it doesn't look any less complex (what I was hoping for). And it doesn't handle the case of a frag_list skb having a frag_list of its own, if that can happen. That's the case where it could recurse multple times, but I don't know if that's possible, either. Possible maybe on received packets, but, unless I'm wrong, none of that can happen here. +-DLS From bunk@stusta.de Thu Apr 14 16:20:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 16:20:42 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3ENKa8h027662 for ; Thu, 14 Apr 2005 16:20:37 -0700 Received: (qmail 2632 invoked from network); 14 Apr 2005 23:20:29 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 14 Apr 2005 23:20:29 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id BE8591274BA; Fri, 15 Apr 2005 01:20:28 +0200 (CEST) Date: Fri, 15 Apr 2005 01:20:28 +0200 From: Adrian Bunk To: Alan Cox Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: [2.6 patch] drivers/net/wan/: possible cleanups Message-ID: <20050414232028.GD20400@stusta.de> References: <20050327143418.GE4285@stusta.de> <1111941516.14877.325.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111941516.14877.325.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 725 Lines: 25 On Sun, Mar 27, 2005 at 05:38:38PM +0100, Alan Cox wrote: > On Sul, 2005-03-27 at 15:34, Adrian Bunk wrote: > > - syncppp.c: sppp_input > > - syncppp.c: sppp_change_mtu > > - z85230.c: z8530_dma_sync > > - z85230.c: z8530_txdma_sync > > Please leave the z85230 ones at least. They are an intentional part of > the external API for writing other 85230 card drivers. If they are part of an API, why aren't the prototypes for them in any header file? > Alan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From herbert@gondor.apana.org.au Thu Apr 14 16:23:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 16:24:00 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ENNl2C028240 for ; Thu, 14 Apr 2005 16:23:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMDg3-0002ek-00; Fri, 15 Apr 2005 09:23:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMDfH-0005xS-00; Fri, 15 Apr 2005 09:22:27 +1000 Date: Fri, 15 Apr 2005 09:22:27 +1000 To: David Stevens Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory Message-ID: <20050414232227.GB22721@gondor.apana.org.au> References: <20050414213040.GA21276@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2769 Lines: 65 On Thu, Apr 14, 2005 at 03:43:37PM -0700, David Stevens wrote: > > > Thanks. Actually I did include it in my patch too. > > Yes, I just saw this -- at lower layer. I prefer the flush up > in sendmsg, since 1) that's where the other error case is done > and 2) that's where the append happens. But I could go either way. Sorry I disagree. Look at the way ip6_push_pending_frames works, when it returns you're guaranteed that the packet has been sent or dropped. Either way the cork buffer has been freed. Therefore rawv6_push_pending_frames should act in an analagous way. In fact with your patch we can end up calling ip6_flush_pending_frames twice. Granted that it is currently harmless but it isn't nice. > > Multiple packets will exist on the queue when the user has written > > more than one MTU worth of data. > > I think the fragmentation happens in the IPv6 layer, so only memory > fragmentation can happen from sendmsg (as far as I can tell). Meaning Look at line 911 in ip6_output.c (inside ip6_append_data). When the user sends more data than can be accomdated in one MTU-sized packet, we will allocate new skb's and put them on the write queue. > the frags array can have multiple buffers, but I'm not sure the > frag_list can have anything on it. In my testing, I wrote a 2K packet frag_list is guaranteed to be empty in rawv6_push_pending_frames, however the write queue may have multiple packets. That's where your patch went wrong. It only handled the case where the checksum is in the first skb on the write queue. > (in fact, all contiguous, in the head). The nr_frags != 0 only happened > with multiple sendmsgs when the write queue had not been flushed, but > I expect it can happen in other cases (e.g., corking). Unless I'm wrong, nr_frags != 0 will happen when 1) Your NIC supports SG. 2) Your MTU > PAGE_SIZE or the socket page is partially used when you enter ip6_append_data. > Yeah, I wrote a non-recursive version of skb_store_bits, but it doesn't > look any less complex (what I was hoping for). And it doesn't handle > the case of a frag_list skb having a frag_list of its own, if that can > happen. That's the case where it could recurse multple times, but I don't It doesn't make sense to have a frag_list inside a frag_list and you can consider it disallowed. > know if that's possible, either. Possible maybe on received packets, but, > unless I'm wrong, none of that can happen here. Well if you do come up with any simplifications please simplify skb_copy_bits too and submit a patch :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dlstevens@us.ibm.com Thu Apr 14 17:31:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 17:31:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3F0VmaX030832 for ; Thu, 14 Apr 2005 17:31:49 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3F0VfLg508864 for ; Thu, 14 Apr 2005 20:31:42 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3F0VfNP242388 for ; Thu, 14 Apr 2005 18:31:41 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3F0VfM2029739 for ; Thu, 14 Apr 2005 18:31:41 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3F0VfLY029733; Thu, 14 Apr 2005 18:31:41 -0600 In-Reply-To: <20050414232227.GB22721@gondor.apana.org.au> To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 14 Apr 2005 17:31:38 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/14/2005 18:31:40, Serialize complete at 04/14/2005 18:31:40 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1752 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: 3398 Lines: 72 Herbert Xu wrote on 04/14/2005 04:22:27 PM: > On Thu, Apr 14, 2005 at 03:43:37PM -0700, David Stevens wrote: > > > > > Thanks. Actually I did include it in my patch too. > > > > Yes, I just saw this -- at lower layer. I prefer the flush up > > in sendmsg, since 1) that's where the other error case is done > > and 2) that's where the append happens. But I could go either way. > Sorry I disagree. Look at the way ip6_push_pending_frames works, when > it returns you're guaranteed that the packet has been sent or dropped. > Either way the cork buffer has been freed. > Therefore rawv6_push_pending_frames should act in an analagous way. > In fact with your patch we can end up calling ip6_flush_pending_frames > twice. Granted that it is currently harmless but it isn't nice. I don't see this. My original patch only calls ip6_flush_pending_frames() once, since the original code already only calls rawv6_push_pending_frames() in the "else" of "if (err)". It's just a question of whether you call it within rawv6_push_pending_frames() before returning error, or immediately after returning, doing it in the caller. It's asymmetric in your patch because the data isn't queued from rawv6_push...(), but it's freed (on error) within it, while the ip6_append_data...() itself flushs from the caller on error, rather than doing it within ip6_append_data() and then returning an error. I'm pretty sure they are functionally equivalent, which is why I can go either way. :-) > > > Multiple packets will exist on the queue when the user has written > > > more than one MTU worth of data. > > > > I think the fragmentation happens in the IPv6 layer, so only memory > > fragmentation can happen from sendmsg (as far as I can tell). Meaning > Look at line 911 in ip6_output.c (inside ip6_append_data). When the > user sends more data than can be accomdated in one MTU-sized packet, > we will allocate new skb's and put them on the write queue. I saw that in the code, but I also saw a 2K single skb when the MTU is 1500. A piece I looked at appeared to be allocating space for frag headers (to be filled in on fragmentation at IPv6 layer, I assume), but still putting the data in the same skb; I'll do some more testing and see if I can understand it better; maybe there's another bug, or a way to avoid a copy when fragmenting in lower layers. But, you're right, if it can happen (appeared not, to me) then your code handles that, too. Even if it doesn't happen in ordinary data>MTU case, I expect it may be possible with MSG_MORE, corking, or other less common cases. > > Yeah, I wrote a non-recursive version of skb_store_bits, but it doesn't > > look any less complex (what I was hoping for). And it doesn't handle > > the case of a frag_list skb having a frag_list of its own, if that can > > happen. That's the case where it could recurse multple times, but I don't > It doesn't make sense to have a frag_list inside a frag_list and you > can consider it disallowed. > Well if you do come up with any simplifications please simplify > skb_copy_bits too and submit a patch :) Well, it made more sense to me, but still complex enough that it might not be clearer to anyone else. skb_copy_bits() works as far as I know, so I guess we can keep both. :-) +-DLS From herbert@gondor.apana.org.au Thu Apr 14 17:42:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 17:42:13 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3F0fwgW031946 for ; Thu, 14 Apr 2005 17:41:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMEtr-00038E-00; Fri, 15 Apr 2005 10:41:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMEtK-00066v-00; Fri, 15 Apr 2005 10:41:02 +1000 Date: Fri, 15 Apr 2005 10:41:02 +1000 To: David Stevens Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory Message-ID: <20050415004102.GA23462@gondor.apana.org.au> References: <20050414232227.GB22721@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1131 Lines: 27 On Thu, Apr 14, 2005 at 05:31:38PM -0700, David Stevens wrote: > > > In fact with your patch we can end up calling ip6_flush_pending_frames > > twice. Granted that it is currently harmless but it isn't nice. > > I don't see this. My original patch only calls > ip6_flush_pending_frames() once, since the original code already only You called ip6_flush_pending_frames() when rawv6_push_pending_frames returned an error. However rawv6_push_pending_frames can return an error that was in turn returned by ip6_push_pending_frames. As you know ip6_push_pending_frames always frees the cork buffer so this is tantamount to calling ip6_flush_pending_frames twice. > I saw that in the code, but I also saw a 2K single skb when the > MTU is 1500. A piece I looked at appeared to be allocating space for That's definitely wrong. Please give us a test case (or patch :) so that this can be fixed. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Thu Apr 14 17:48:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Apr 2005 17:48:56 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3F0mlSD032588 for ; Thu, 14 Apr 2005 17:48:48 -0700 Received: (qmail 4320 invoked from network); 15 Apr 2005 00:48:42 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Apr 2005 00:48:42 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A6278E7D6E; Fri, 15 Apr 2005 02:48:41 +0200 (CEST) Date: Fri, 15 Apr 2005 02:48:41 +0200 From: Adrian Bunk To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/arcnet/: possible cleanups Message-ID: <20050415004841.GH20400@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5038 Lines: 160 This patch contains the following possible cleanups: - make needlessly global code static - arcnet.c: remove the outdated VERSION - arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null) - arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet) Signed-off-by: Adrian Bunk --- This patch was already sent on: - 24 Mar 2005 drivers/net/arcnet/arc-rawmode.c | 2 +- drivers/net/arcnet/arcnet.c | 19 ++++++++++--------- drivers/net/arcnet/rfc1051.c | 2 +- drivers/net/arcnet/rfc1201.c | 3 +-- include/linux/arcdevice.h | 9 --------- 5 files changed, 13 insertions(+), 22 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c.old 2005-02-16 15:16:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c 2005-02-16 15:16:51.000000000 +0100 @@ -42,7 +42,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); -struct ArcProto rawmode_proto = +static struct ArcProto rawmode_proto = { .suffix = 'r', .mtu = XMTU, --- linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h.old 2005-02-16 15:17:26.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h 2005-02-16 15:20:57.000000000 +0100 @@ -206,7 +206,6 @@ extern struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -extern struct ArcProto arc_proto_null; /* @@ -334,17 +333,9 @@ #define arcnet_dump_skb(dev,skb,desc) ; #endif -#if (ARCNET_DEBUG_MAX & D_RX) || (ARCNET_DEBUG_MAX & D_TX) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock); -#else -#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ; -#endif - void arcnet_unregister_proto(struct ArcProto *proto); irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs); struct net_device *alloc_arcdev(char *name); -void arcnet_rx(struct net_device *dev, int bufnum); #endif /* __KERNEL__ */ #endif /* _LINUX_ARCDEVICE_H */ --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c.old 2005-02-16 15:17:47.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c 2005-02-16 15:21:20.000000000 +0100 @@ -41,8 +41,6 @@ * */ -#define VERSION "arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n" - #include #include #include @@ -61,6 +59,7 @@ static int null_prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); +static void arcnet_rx(struct net_device *dev, int bufnum); /* * one ArcProto per possible proto ID. None of the elements of @@ -71,7 +70,7 @@ struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -struct ArcProto arc_proto_null = +static struct ArcProto arc_proto_null = { .suffix = '?', .mtu = XMTU, @@ -90,7 +89,6 @@ EXPORT_SYMBOL(arc_proto_default); EXPORT_SYMBOL(arc_bcast_proto); EXPORT_SYMBOL(arc_raw_proto); -EXPORT_SYMBOL(arc_proto_null); EXPORT_SYMBOL(arcnet_unregister_proto); EXPORT_SYMBOL(arcnet_debug); EXPORT_SYMBOL(alloc_arcdev); @@ -118,8 +116,8 @@ arcnet_debug = debug; - printk(VERSION); + printk("arcnet loaded.\n"); #ifdef ALPHA_WARNING BUGLVL(D_EXTRA) { printk("arcnet: ***\n" @@ -178,8 +174,8 @@ * Dump the contents of an ARCnet buffer */ #if (ARCNET_DEBUG_MAX & (D_RX | D_TX)) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock) +static void arcnet_dump_packet(struct net_device *dev, int bufnum, + char *desc, int take_arcnet_lock) { struct arcnet_local *lp = dev->priv; int i, length; @@ -208,7 +204,10 @@ } -EXPORT_SYMBOL(arcnet_dump_packet); +#else + +#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0) + #endif @@ -987,7 +986,7 @@ * This is a generic packet receiver that calls arcnet??_rx depending on the * protocol ID found. */ -void arcnet_rx(struct net_device *dev, int bufnum) +static void arcnet_rx(struct net_device *dev, int bufnum) { struct arcnet_local *lp = dev->priv; struct archdr pkt; --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c.old 2005-02-16 15:22:16.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c 2005-02-16 15:22:23.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); -struct ArcProto rfc1051_proto = +static struct ArcProto rfc1051_proto = { .suffix = 's', .mtu = XMTU - RFC1051_HDR_SIZE, --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c.old 2005-02-16 15:22:35.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c 2005-02-16 15:22:46.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); static int continue_tx(struct net_device *dev, int bufnum); -struct ArcProto rfc1201_proto = +static struct ArcProto rfc1201_proto = { .suffix = 'a', .mtu = 1500, /* could be more, but some receivers can't handle it... */ From baruch@ev-en.org Fri Apr 15 07:37:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 07:37:55 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FEbnP6009643 for ; Fri, 15 Apr 2005 07:37:50 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 4BD5711A5D1; Fri, 15 Apr 2005 17:37:44 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 3560911A5CE; Fri, 15 Apr 2005 17:37:40 +0300 (IDT) Message-ID: <425FD1AE.3060301@ev-en.org> Date: Fri, 15 Apr 2005 15:37:34 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Baruch Even Cc: netdev@oss.sgi.com, "David S. Miller" , Stephen Hemminger Subject: Re: TCP performance drop 2.6.6->2.6.7 References: <425C493B.5040206@ev-en.org> In-Reply-To: <425C493B.5040206@ev-en.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1111 Lines: 32 I have no clue *why* it happens, but a hint on when it happens. If I remove the ixgb driver from my .config, performance is back to normal. Note though that I don't even use the ixgb driver for my tests, it's just sitting idle on the machine and connected to nothing (the cisco router is turned off to reduce noise polution). To continue my work I'll disable the ixgb for now. Baruch Baruch Even wrote: > Hello, > > I'm trying to port my H-TCP and SACK improvements to 2.6.11, but I seem > to hit performance problems that are unrelated to what I worked on so far. > > My tests show that between 2.6.6 and 2.6.7 the TCP performance dropped > considerably. > > The setup for the tests, vanilla kernels, dummynet with 100 Mbit/s and > 40ms rtt using the BIC protocol. No patches applied whatsoever. > > iperf tests for 2.6.6 get about 90Mbit/s while 2.6.7 gets 30Mbit/s. > > I was wondering if someone can think of a reason why this happens? > > Is there a way to get the different network related patches between > these two versions? I don't have access to bk to get it myself. > > Baruch > From Robert.Olsson@data.slu.se Fri Apr 15 07:53:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 07:53:10 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FEqxi2010932 for ; Fri, 15 Apr 2005 07:53:00 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3FEqwKh026472 for ; Fri, 15 Apr 2005 16:52:58 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 4B07DEE1F1; Fri, 15 Apr 2005 16:52:58 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16991.54602.218744.163816@robur.slu.se> Date: Fri, 15 Apr 2005 16:52:58 +0200 To: netdev@oss.sgi.com Cc: Robert.Olsson@data.slu.se Subject: FIB alternative fib_hash2.c X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1758 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: 25082 Lines: 1049 Hello! Don't like to sit on this... originally an experiment to understand what we can expect from FIB lookup in the linux context. Beginning to think it might be useful as is... memory is cheap. With full bgp and rDoS I see around double FIB lookup performance. No-one has been brave enough to test it.... Patch is for 2.6.11 and includes an Kconfig option different FIB alternatives. Cheers. --ro --- net/ipv4/Kconfig.orig 2005-04-15 13:41:52.000000000 +0200 +++ net/ipv4/Kconfig 2005-04-15 15:14:43.000000000 +0200 @@ -1,6 +1,44 @@ # # IP configuration # +choice + prompt "Choose IP: FIB lookup"" + depends on INET + default IP_FIB_HASH + +config IP_FIB_HASH + bool "FIB_HASH" + ---help--- + Current FIB is very proven and good enough for most users. + +config IP_FIB_HASH2 + bool "FIB_HASH2" + depends on INET && EXPERIMENTAL + ---help--- + If you willing to trade memory for very fast FIB lookups + HASH2 can be considered. Experimental. + + HASH2 requires that vmalloc can allocate huge memory. vmalloc + can be increased with boot option i.e vmalloc=256MB. See kernel + documentation for this. + + TODO: Speedup listing of routes. + +endchoice + +config IP_FIB_MERGE_TABLE + + bool "IP: HASH2 trie merge of local and main table" + depends on IP_FIB_HASH2 + ---help--- + FIB performance increases when main table is kept with local + table. This avoids lookup from first local then the main + table in case of routing etc. + But this also breaks some linux ip functions as source routing + etc. For simple IP routing it can be considered. + + If unsure, say N. + config IP_MULTICAST bool "IP: multicasting" depends on INET --- net/ipv4/Makefile.orig 2005-04-15 13:42:12.000000000 +0200 +++ net/ipv4/Makefile 2005-04-15 14:55:14.000000000 +0200 @@ -7,8 +7,10 @@ ip_output.o ip_sockglue.o \ tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o tcp_minisocks.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ - sysctl_net_ipv4.o fib_frontend.o fib_semantics.o fib_hash.o + sysctl_net_ipv4.o fib_frontend.o fib_semantics.o +obj-$(CONFIG_IP_FIB_HASH) += fib_hash.o +obj-$(CONFIG_IP_FIB_HASH2) += fib_hash2.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o obj-$(CONFIG_IP_MROUTE) += ipmr.o --- ./include/linux/netlink.h.orig 2005-03-30 18:13:09.000000000 +0200 +++ ./include/linux/netlink.h 2005-03-30 18:13:22.000000000 +0200 @@ -145,7 +145,7 @@ int (*dump)(struct sk_buff * skb, struct netlink_callback *cb); int (*done)(struct netlink_callback *cb); int family; - long args[4]; + long args[5]; }; struct netlink_notify --- /dev/null 2005-04-14 15:05:36.930846264 +0200 +++ net/ipv4/fib_hash2.c 2005-04-15 15:42:37.000000000 +0200 @@ -0,0 +1,961 @@ +/* + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Robert Olsson Uppsala Universitet + * & Swedish University of Agricultural Sciences. + * + * Jens Laas Swedish University of + * Agricultural Sciences. + * + * Hans Liss Uppsala Universitet + * + * Code from fib_hash has been reused which includes the following header: + * + * Authors: Alexey Kuznetsov, + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + + +/* + * An alternative FIB for applications were you are willing to trade memory + * usage for very fast lookups. + * + * Operation is simple; 24 bits of ipv4 address is used as a key to bucket + * holding structures of fib_alias listheads. The structures are sorted in + * prefix order. + * + * 0 > prefixes > 24 are cloned to /24 prefixes for fast lookup. + * Last resorts are handled as special case. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "fib_lookup.h" + +#define VERSION "0.58" + +typedef unsigned int t_key; + +struct fib_hash2_info { + struct hlist_node hlist; + u32 plen; + u32 pfx; + struct list_head falh; + u32 flags; +}; + +struct fib_hash2_table { + struct hlist_head *hash; + rwlock_t lock; + int size; /* In buckets*/ +}; + +/* flags used in fib_hash2_info */ +#define FHI_CLONE (1<<0) + +#define IS_CLONE(n) (n->flags & FHI_CLONE) + +extern void rtmsg_fib(int event, u32 key, struct fib_alias *fa, int z, int tb_id, + struct nlmsghdr *n, struct netlink_skb_parms *req); + +extern struct fib_alias *fib_find_alias(struct list_head *fah, u8 tos, u32 prio); +extern int fib_detect_death(struct fib_info *fi, int order, + struct fib_info **last_resort, int *last_idx, int *dflt); + +static int debug = 0; +static kmem_cache_t *fn_alias_kmem; +static kmem_cache_t *fn_hash2_kmem; + +static inline void fn_free_node(struct fib_hash2_info * f) +{ + kmem_cache_free(fn_hash2_kmem, f); +} + +/* Candiate for fib_semantics */ + +static void fn_free_alias(struct fib_alias *fa) +{ + fib_release_info(fa->fa_info); + kmem_cache_free(fn_alias_kmem, fa); +} + +struct fib_hash2_table *hash2_local=NULL, *hash2_main=NULL; + + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + +/* + * Keep main in local table for performance reasons. + */ + +static inline struct fib_hash2_table* merge_tables(int tb_id, struct fib_hash2_table *t) +{ + if(tb_id == RT_TABLE_MAIN) + return hash2_local; + return t; +} +#endif + +static struct fib_hash2_info *fib_find_node(struct hlist_head *head, u32 key, int plen) +{ + struct hlist_node *node; + struct fib_hash2_info *fhi; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if ( fhi->plen == plen && fhi->pfx == key ) + return fhi; + } + return NULL; +} + +static void fib_insert_node(struct hlist_head *head, struct fib_hash2_info *new) +{ + struct fib_hash2_info *fhi=NULL, *last=NULL; + struct hlist_node *node, *tmp; + + if(hlist_empty(head)) + hlist_add_head(&new->hlist, head); + else { + hlist_for_each_entry_safe(fhi, node, tmp, head, hlist) { + + if (new->plen > fhi->plen) + break; + + last = fhi; + } + if(last) + hlist_add_after(&last->hlist, &new->hlist); + else + hlist_add_before(&new->hlist, &fhi->hlist); + } +} + +static int +hash2_insert(struct fib_hash2_table *t, u32 idx, u32 key, int plen, struct fib_table *tb, + struct rtmsg *r, struct kern_rta *rta, struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_alias *fa=NULL, *new_fa; + struct list_head *fa_head=NULL; + struct fib_info *fi; + int type = r->rtm_type; + u8 tos = r->rtm_tos; + int err = 0; + struct hlist_head *bh, *h; + struct fib_hash2_info *fhi=NULL, *new_fhi; + int clone = 0; + + if ((fi = fib_create_info(r, rta, nlhdr, &err)) == NULL) + return err; + + if( key>>8 != idx) + clone = 1; + + h = t->hash; + bh = (struct hlist_head*) &h[idx]; + + fhi = fib_find_node(bh, key, plen); + + if (!fhi) + fa = NULL; + else { + fa_head = &fhi->falh; + fa = fib_find_alias(fa_head, tos, fi->fib_priority); + } + + /* Now fa, if non-NULL, points to the first fib alias + * with the same keys [prefix,tos,priority], if such key already + * exists or to the node before which we will insert new one. + * + * If fa is NULL, we will need to allocate a new one and + * insert to the head of f. + * + * If f is NULL, no fib node matched the destination key + * and we need to allocate a new one of those as well. + */ + + if (fa && + fa->fa_info->fib_priority == fi->fib_priority) { + struct fib_alias *fa_orig; + + err = -EEXIST; + if (nlhdr->nlmsg_flags & NLM_F_EXCL) + goto out; + + if (nlhdr->nlmsg_flags & NLM_F_REPLACE) { + struct fib_info *fi_drop; + u8 state; + + write_lock_bh(&t->lock); + fi_drop = fa->fa_info; + fa->fa_info = fi; + fa->fa_type = type; + fa->fa_scope = r->rtm_scope; + state = fa->fa_state; + fa->fa_state &= ~FA_S_ACCESSED; + write_unlock_bh(&t->lock); + + fib_release_info(fi_drop); + if (state & FA_S_ACCESSED) + rt_cache_flush(-1); + return 0; + } + + /* Error if we find a perfect match which + * uses the same scope, type, and nexthop + * information. + */ + fa_orig = fa; + list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + if (fa->fa_tos != tos) + break; + if (fa->fa_info->fib_priority != fi->fib_priority) + break; + if (fa->fa_type == type && + fa->fa_scope == r->rtm_scope && + fa->fa_info == fi) + goto out; + } + if (!(nlhdr->nlmsg_flags & NLM_F_APPEND)) + fa = fa_orig; + } + + err = -ENOENT; + if (!(nlhdr->nlmsg_flags&NLM_F_CREATE)) + goto out; + + err = -ENOBUFS; + new_fa = kmem_cache_alloc(fn_alias_kmem, SLAB_KERNEL); + if (new_fa == NULL) + goto out; + + new_fa->fa_info = fi; + new_fa->fa_tos = tos; + new_fa->fa_type = type; + new_fa->fa_scope = r->rtm_scope; + new_fa->fa_state = 0; +#if 0 + new_fa->dst = NULL; +#endif + new_fhi = NULL; + if (!fhi) { + new_fhi = kmem_cache_alloc(fn_hash2_kmem, SLAB_KERNEL); + if(!new_fhi) + goto out_free_new_fa; + + new_fhi->plen = plen; + new_fhi->pfx = key; + + new_fhi->flags = 0; + if(clone) + new_fhi->flags |= FHI_CLONE; + + INIT_LIST_HEAD(&new_fhi->falh); + fa_head = &new_fhi->falh; + } + + /* + * Insert new entry to the list. + */ + + write_lock_bh(&t->lock); + if(new_fhi) + fib_insert_node(bh, new_fhi); + + list_add_tail(&new_fa->fa_list, + (fa ? &fa->fa_list : fa_head)); + write_unlock_bh(&t->lock); + + if(!clone) { + rt_cache_flush(-1); + rtmsg_fib(RTM_NEWROUTE, key, new_fa, plen, tb->tb_id, nlhdr, req); + } + return 0; + +out_free_new_fa: + kmem_cache_free(fn_alias_kmem, new_fa); +out: + fib_release_info(fi); + return err; +} + +static int +fn_hash2_insert(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + int plen = r->rtm_dst_len; + u32 key, first, mask; + int err = 0; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + first = key >> 8; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + + if(plen > 0 && plen < 24) { + u32 idx, last; + + last = (key | ~mask) >> 8; + for(idx=first; idx <= last ; idx++) + + /* Needs Alexey :) */ + + err |= hash2_insert(t, idx, key, plen, tb, r, rta, nlhdr, req); + } + else + err = hash2_insert(t, first, key, plen, tb, r, rta, nlhdr, req); + + if(debug) + printk("fn_hash2_insert id=%d %08x/%d\n", tb->tb_id, key, plen); + + return err; +} + +static int +fn_hash2_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + t_key key; + u32 idx, mask; + int ret; + struct hlist_head *h, *bh; + struct fib_hash2_info *fhi = NULL; + struct hlist_node *node; + + key = flp->fl4_dst; + key = ntohl(key); + idx = key >> 8; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + h = t->hash; + bh = (struct hlist_head*) &h[idx]; + + read_lock(&t->lock); + hlist_for_each_entry(fhi, node, bh, hlist) { + +#if 0 + printk("Table=%d fhi->pfx=%x k=%x plen=%d\n", + tb->tb_id, fhi->pfx, key, fhi->plen); +#endif + mask = ntohl( inet_make_mask(fhi->plen) ); + + if (fhi->pfx == (key & mask)) { + ret = fib_semantic_match(&fhi->falh, flp, res, fhi->plen); + + if(ret <= 0) + goto found; + } + } + /* Last resort? */ + + fhi = fib_find_node(&h[0], 0, 0); + + if(fhi) { + ret = fib_semantic_match(&fhi->falh, flp, res, 0); + if(ret <= 0) + goto found; + } + + ret = 1; +found: + +#if 0 + if (!ret) + printk("Lookup OK: plen=%d, nh_sel=%d, type=%d, scope=%d fib_info=%p\n", + res->prefixlen, res->nh_sel, res->type, res->scope, res->fi); + + else + printk("Lookup failed: t=%p key=%08x ret=%d\n", t, key, ret); +#endif + read_unlock(&t->lock); + return ret; +} + +static int +hash2_delete(struct fib_hash2_table *t, u32 idx, u32 key, int plen, struct fib_table *tb, struct rtmsg *r, + struct kern_rta *rta, struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + int err = 0; + struct fib_alias *fa, *fa_to_delete; + struct list_head *fa_head; + struct hlist_head *bh, *h; + struct hlist_node *node; + struct fib_hash2_info *fhi = NULL; + u8 tos = r->rtm_tos; + int clone = 0; + + if( key>>8 != idx) + clone = 1; + + h = t->hash; + bh = (struct hlist_head*) &h[idx]; + + if( hlist_empty(bh) ) { + err = -ESRCH; + goto out; + } + + hlist_for_each_entry(fhi, node, bh, hlist) { + if (fhi->plen == plen && fhi->pfx == key ) { + fa = fib_find_alias(&fhi->falh, tos, 0); + if(fa) goto got_alias; + } + } + + /* Last resort */ + + fhi = fib_find_node(&h[0], 0, 0); + if(fhi) { + fa = fib_find_alias(&fhi->falh, tos, 0); + if(fa) + goto got_alias; + } + + err = -ESRCH; + goto out; + +got_alias: + + fa_to_delete = NULL; + fa_head = fa->fa_list.prev; + list_for_each_entry(fa, fa_head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fa->fa_tos != tos) + break; + + if ((!r->rtm_type || + fa->fa_type == r->rtm_type) && + (r->rtm_scope == RT_SCOPE_NOWHERE || + fa->fa_scope == r->rtm_scope) && + (!r->rtm_protocol || + fi->fib_protocol == r->rtm_protocol) && + fib_nh_match(r, nlhdr, rta, fi) == 0) { + fa_to_delete = fa; + break; + } + } + + if (fa_to_delete) { + + int kill_fn = 0; + fa = fa_to_delete; + + if(clone) + rtmsg_fib(RTM_DELROUTE, key, fa, plen, tb->tb_id, nlhdr, req); + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + + /* Remove fib_hash2_info in case */ + + if(list_empty(fa_head)) { + hlist_del(&fhi->hlist); + kill_fn = 1; + } + write_unlock_bh(&t->lock); + + if (fa->fa_state & FA_S_ACCESSED) + rt_cache_flush(-1); + + fn_free_alias(fa); + + if (kill_fn) + fn_free_node(fhi); + } + else + err = -ESRCH; + out: + return err; +} + +static int +fn_hash2_delete(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + u32 key, first, mask; + int err = 0; + int plen = r->rtm_dst_len; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + first = key >> 8; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + if(plen > 0 && plen < 24) { + u32 idx, last; + + last = (key | ~mask) >> 8; + for(idx=first; idx <= last ; idx++) + + /* Needs Alexey :) */ + + err |= hash2_delete(t, idx, key, plen, tb, r, rta, nlhdr, req); + } + else + err = hash2_delete(t, first, key, plen, tb, r, rta, nlhdr, req); + + if(debug) + printk("fn_hash2_delete id=%d %08x/%d\n", tb->tb_id, key, plen); + + return err; +} + +static int hash2_flush_list(struct fib_hash2_table *t, struct list_head *fah) +{ + struct list_head *head = fah; + struct fib_alias *fa, *fa_node; + int found = 0; + + list_for_each_entry_safe(fa, fa_node, head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + write_unlock_bh(&t->lock); + + fn_free_alias(fa); + found++; + } + } + return found; +} + +static int fn_hash2_flush(struct fib_table *tb) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + int found = 0; + struct hlist_head *bh, *h; + struct hlist_node *node; + struct hlist_node *tmp; + struct fib_hash2_info *fhi; + int size; + u32 idx; + int kill_f; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + + if(debug) + printk("fn_hash2_flush table=%d\n", tb->tb_id); + + size = t->size; + h = t->hash; + + for(idx=0; idx < size; idx++) { + bh = (struct hlist_head*) &h[idx]; + if( hlist_empty(bh) ) + continue; + + hlist_for_each_entry_safe(fhi, node, tmp, bh, hlist) { + if(list_empty(&fhi->falh)) + continue; + + found += hash2_flush_list(t, &fhi->falh); + + kill_f = 0; + write_lock_bh(&t->lock); + if(list_empty(&fhi->falh)) { + hlist_del(&fhi->hlist); + kill_f = 1; + } + write_unlock_bh(&t->lock); + + if(kill_f) + fn_free_node(fhi); + } + } + + if(debug) + printk("fn_hash2_flush flushed=%d\n", found); + + return found; +} + +static int hash2_last_dflt=-1; + +static void +fn_hash2_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + int order, last_idx; + struct fib_info *fi = NULL; + struct fib_info *last_resort; + struct fib_alias *fa = NULL; + struct hlist_head *h; + struct fib_hash2_info *fhi; + + if(debug) + printk("fn_hash2_select_default\n"); + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + + h = t->hash; + fhi = fib_find_node(&h[0], 0, 0); + + if(!fhi) + return; + + if (list_empty(&fhi->falh)) + return; + + last_idx = -1; + last_resort = NULL; + order = -1; + + list_for_each_entry(fa, &fhi->falh, fa_list) { + struct fib_info *next_fi = fa->fa_info; + + if (fa->fa_scope != res->scope || + fa->fa_type != RTN_UNICAST) + continue; + + if (next_fi->fib_priority > res->fi->fib_priority) + break; + if (!next_fi->fib_nh[0].nh_gw || + next_fi->fib_nh[0].nh_scope != RT_SCOPE_LINK) + continue; + fa->fa_state |= FA_S_ACCESSED; + + if (fi == NULL) { + if (next_fi != res->fi) + break; + } else if (!fib_detect_death(fi, order, &last_resort, + &last_idx, &hash2_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hash2_last_dflt = order; + goto out; + } + fi = next_fi; + order++; + } + + if (order <= 0 || fi == NULL) { + hash2_last_dflt = -1; + goto out; + } + + if (!fib_detect_death(fi, order, &last_resort, &last_idx, &hash2_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hash2_last_dflt = order; + goto out; + } + + if (last_idx >= 0) { + if (res->fi) + fib_info_put(res->fi); + res->fi = last_resort; + if (last_resort) + atomic_inc(&last_resort->fib_clntref); + } + hash2_last_dflt = last_idx; + out:; +} + +static inline int fn_hash2_dump_fa(t_key key, int plen, struct list_head *fah, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int i, s_i; + struct fib_alias *fa; + u32 xkey=htonl(key); + s_i=cb->args[4]; + i = 0; + + list_for_each_entry(fa, fah, fa_list) { + + if (i < s_i) { + i++; + continue; + } + if (fa->fa_info->fib_nh == NULL) { + printk("Hash2 error _fib_nh=NULL in fa[%d] k=%08x plen=%d\n", i, key, plen); + i++; + continue; + } + if (fa->fa_info == NULL) { + printk("Hash2 error fa_info=NULL in fa[%d] k=%08x plen=%d\n", i, key, plen); + i++; + continue; + } + + if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, + RTM_NEWROUTE, + tb->tb_id, + fa->fa_type, + fa->fa_scope, + &xkey, + plen, + fa->fa_tos, + fa->fa_info) < 0) { + cb->args[4] = i; + return -1; + } + i++; + } + cb->args[4]=i; + return skb->len; +} + +static inline int fn_hash2_dump_info(struct hlist_head *head, int plen, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int s_i = cb->args[3]; + int i = 0; + struct hlist_node *node; + struct fib_hash2_info *fhi; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if (i < s_i) continue; + if (i > s_i) + memset(&cb->args[4], 0, + sizeof(cb->args) - 4*sizeof(cb->args[0])); + + if (IS_CLONE(fhi)) continue; + + if (fhi->plen == plen) { + + if (fn_hash2_dump_fa(fhi->pfx, fhi->plen, &fhi->falh, tb, skb, cb)<0) { + cb->args[3]=i; + return -1; + } + } + i++; + } + cb->args[3]=i; + return skb->len; +} + +static inline int fn_hash2_dump_plen(int plen, struct fib_table *tb, struct sk_buff *skb, + struct netlink_callback *cb) +{ + u32 idx; + int s_h; + int size; + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + struct hlist_head *bh, *h; + s_h=cb->args[2]; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + t = merge_tables(tb->tb_id, t); +#endif + size = t->size; + h = t->hash; + + for(idx=s_h; idx < size; idx++) { + + if (idx < s_h) continue; + if (idx > s_h) + memset(&cb->args[3], 0, + sizeof(cb->args) - 3*sizeof(cb->args[0])); + + bh = (struct hlist_head*) &h[idx]; + + if( hlist_empty(bh) ) + continue; + + read_lock(&t->lock); + + if( fn_hash2_dump_info(bh, plen, tb, skb, cb)) { + cb->args[2]=idx; + read_unlock(&t->lock); + return -1; + } + + read_unlock(&t->lock); + } + + cb->args[2] = idx; + return skb->len; +} + +static int fn_hash2_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) +{ + int m, s_m; + s_m= cb->args[1]; + + for (m=s_m; m<=32; m++) { + + if (m < s_m) continue; + if (m > s_m) + memset(&cb->args[2], 0, + sizeof(cb->args) - 2*sizeof(cb->args[0])); + + if (fn_hash2_dump_plen(32-m, tb, skb, cb)<0) { + cb->args[1] = m; + return -1; + } + } + cb->args[1] = m; + return skb->len; +} + +void create(struct fib_table *tb) +{ + struct fib_hash2_table *t = (struct fib_hash2_table *) tb->tb_data; + int i; + struct hlist_head *h; + int s = t->size * sizeof(struct hlist_head); + + t->hash = vmalloc(s); + + if (!t->hash) + panic("Failed to allocate IP route hash table\n"); + + h = t->hash; + + for(i=0; i < t->size; i++) + INIT_HLIST_HEAD(&h[i]); + + printk(KERN_INFO "IP: FIB vers %s routing table of %u buckets, %ldKbytes for table id=%d\n", + VERSION, t->size, (long) s / 1024, tb->tb_id); +} + +#ifdef CONFIG_IP_MULTIPLE_TABLES +struct fib_table * fib_hash_init(int id) +#else +struct fib_table * __init fib_hash_init(int id) +#endif +{ + struct fib_table *tb; + struct fib_hash2_table *t; + + if (fn_alias_kmem == NULL) + fn_alias_kmem = kmem_cache_create("ip_fib_alias", + sizeof(struct fib_alias), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + if (fn_hash2_kmem == NULL) + fn_hash2_kmem = kmem_cache_create("ip_fib2_info", + sizeof(struct fib_hash2_info), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fib_hash2_table), + GFP_KERNEL); + + if (tb == NULL) + return NULL; + + tb->tb_id = id; + tb->tb_lookup = fn_hash2_lookup; + tb->tb_insert = fn_hash2_insert; + tb->tb_delete = fn_hash2_delete; + tb->tb_flush = fn_hash2_flush; + tb->tb_select_default = fn_hash2_select_default; + tb->tb_dump = fn_hash2_dump; + memset(tb->tb_data, 0, sizeof(struct fib_hash2_table)); + + t = (struct fib_hash2_table *) tb->tb_data; + + t->lock = RW_LOCK_UNLOCKED; + + if (id == RT_TABLE_LOCAL) + hash2_local=t; + else if (id == RT_TABLE_MAIN) + hash2_main=t; + + t->size = 1 << 24; + +#ifdef CONFIG_IP_FIB_MERGE_TABLE + if (id == RT_TABLE_LOCAL) +#endif + create(tb); + + return tb; +} + +#ifdef CONFIG_PROC_FS + +int __init fib_proc_init(void) +{ + return 0; +} + +void __init fib_proc_exit(void) +{ + proc_net_remove("route"); +} +#endif /* CONFIG_PROC_FS */ + From niv@us.ibm.com Fri Apr 15 08:30:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 08:30:21 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FFU9Gi016605 for ; Fri, 15 Apr 2005 08:30:16 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3FFU3Lg373252 for ; Fri, 15 Apr 2005 11:30:03 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3FFU3Aq251358 for ; Fri, 15 Apr 2005 09:30:03 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3FFU2ps019862 for ; Fri, 15 Apr 2005 09:30:03 -0600 Received: from [9.49.140.120] (sig-9-49-140-120.mts.ibm.com [9.49.140.120]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3FFU18r019787; Fri, 15 Apr 2005 09:30:02 -0600 Message-ID: <425FDE1B.6050804@us.ibm.com> Date: Fri, 15 Apr 2005 08:30:35 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Baruch Even CC: netdev@oss.sgi.com, "David S. Miller" , Stephen Hemminger Subject: Re: TCP performance drop 2.6.6->2.6.7 References: <425C493B.5040206@ev-en.org> <425FD1AE.3060301@ev-en.org> In-Reply-To: <425FD1AE.3060301@ev-en.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 490 Lines: 13 Baruch Even wrote: > I have no clue *why* it happens, but a hint on when it happens. If I > remove the ixgb driver from my .config, performance is back to normal. > Note though that I don't even use the ixgb driver for my tests, it's > just sitting idle on the machine and connected to nothing (the cisco > router is turned off to reduce noise polution). Check your interrupts - it's probably sending out a large number of interrupts which are clogging the system.. thanks, Nivedita From jt@hpl.hp.com Fri Apr 15 09:54:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 09:55:02 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FGswQu020336 for ; Fri, 15 Apr 2005 09:54:58 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id E43A0403054; Fri, 15 Apr 2005 09:54:57 -0700 (PDT) Received: from bougret.hpl.hp.com (Debian-exim@bougret.hpl.hp.com [15.9.72.130]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id JAA04591; Fri, 15 Apr 2005 09:56:13 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 4.50) id 1DMU5n-0002Ha-A6; Fri, 15 Apr 2005 09:54:55 -0700 Date: Fri, 15 Apr 2005 09:54:55 -0700 To: rainer.weikusat@sncag.com, prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re : [Prism54-devel] Question on prism54 driver Message-ID: <20050415165455.GA8741@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 User-Agent: Mutt/1.5.6+20040907i From: Jean Tourrilhes X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 1857 Lines: 46 Rainer Weikusat wrote : > > Jean-Baptiste Note writes: > > Going through the prism54 code for reuse in the softmac driver, i > > stumbled accross inconsistencies in the queue management functions for > > the mgmt rx queue and the data rx queue that i cannot understand. > > > No, you are just hacking the code without even having tried to > understand > > a) what it is doing > b) why it does this > [which, "by coincedence", happens to be the reason that this driver is > so thouroughly broken] > > > BTW, I shouldn't be telling you how your code works, don't you think > so? Ah ! It's so fun to blast an e-mail and flame away. Now, I'm sorry to inform you that you got a few important fact wrong, and that your critics were totally unjustified. First, Jean-Baptiste is not the author, nor the maintainer of the Prism54 driver, and neither a contributor to it. The prism54 driver in the kernel is in no way "his" code. He is developping the softmac driver, which is another beast entirely. Second, he is not hacking the code without trying to understand. Jean-Baptiste started working on his driver only 2 months ago, and he is asking questions, which demonstrates that he is trying and willing to learn. Most of us are still trying to learn... Third, the prism54 driver may be broken, the usual procedure is either to send a patch or report specific bugs to the maintainers (which Jean-Baptiste is not). I've rarely seen pieces of code which are bug free, so having bugs in the prism54 is not the end of the world, they just need to be fixed. In any case, thanks a lot for explaining clearly the details of the pci interface to Jean-Baptiste, in my experience memory management is confusing for begginers, and I'm sure more people could benefits from your expertise. Regards, Jean From andre@tomt.net Fri Apr 15 10:31:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 10:31:04 -0700 (PDT) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FHV03I022430 for ; Fri, 15 Apr 2005 10:31:00 -0700 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id D4F9588602; Fri, 15 Apr 2005 19:30:58 +0200 (CEST) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 1C92888606; Fri, 15 Apr 2005 19:30:58 +0200 (CEST) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 172D4228E2; Fri, 15 Apr 2005 19:30:58 +0200 (CEST) Message-ID: <425FFA54.9070106@tomt.net> Date: Fri, 15 Apr 2005 19:31:00 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: FIB alternative fib_hash2.c References: <16991.54602.218744.163816@robur.slu.se> In-Reply-To: <16991.54602.218744.163816@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 515 Lines: 11 Robert Olsson wrote: > Hello! > > Don't like to sit on this... originally an experiment to understand what we > can expect from FIB lookup in the linux context. Beginning to think it > might be useful as is... memory is cheap. With full bgp and rDoS I see around > double FIB lookup performance. No-one has been brave enough to test it.... > Patch is for 2.6.11 and includes an Kconfig option different FIB alternatives. Drool. Got some numbers? pps - flows - memory use, on what hardware, that sort of thing. From alan@lxorguk.ukuu.org.uk Fri Apr 15 10:52:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 10:52:47 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FHqfl0023567 for ; Fri, 15 Apr 2005 10:52:42 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j3FHnwP4012480; Fri, 15 Apr 2005 18:50:00 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j3FHnwjV012479; Fri, 15 Apr 2005 18:49:58 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.6 patch] drivers/net/wan/: possible cleanups From: Alan Cox To: Adrian Bunk Cc: netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20050414232028.GD20400@stusta.de> References: <20050327143418.GE4285@stusta.de> <1111941516.14877.325.camel@localhost.localdomain> <20050414232028.GD20400@stusta.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1113587392.11155.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 15 Apr 2005 18:49:56 +0100 X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 729 Lines: 20 On Gwe, 2005-04-15 at 00:20, Adrian Bunk wrote: > On Sun, Mar 27, 2005 at 05:38:38PM +0100, Alan Cox wrote: > > On Sul, 2005-03-27 at 15:34, Adrian Bunk wrote: > > > - syncppp.c: sppp_input > > > - syncppp.c: sppp_change_mtu > > > - z85230.c: z8530_dma_sync > > > - z85230.c: z8530_txdma_sync > > > > Please leave the z85230 ones at least. They are an intentional part of > > the external API for writing other 85230 card drivers. > > If they are part of an API, why aren't the prototypes for them in any > header file? They were once. I guess that got "tided" at some point, possibly long ago even before submission. z8530_dma_sync and txdma_sync set up the device in DMA mode, or in DMA one direction only mode. From rainer.weikusat@sncag.com Fri Apr 15 13:26:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 13:26:09 -0700 (PDT) Received: from farside.sncag.com ([217.111.56.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FKQ30Z032024 for ; Fri, 15 Apr 2005 13:26:04 -0700 Received: from farside.sncag.com (localhost [127.0.0.1]) by farside.sncag.com (8.13.3/8.13.3/Debian-8) with ESMTP id j3FKPgVn010907; Fri, 15 Apr 2005 22:25:42 +0200 Received: (from rw@localhost) by farside.sncag.com (8.13.3/8.13.3/Submit) id j3FKPg5r010904; Fri, 15 Apr 2005 22:25:42 +0200 To: jt@hpl.hp.com Cc: rweikusat@sncag.com, prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re: Re : [Prism54-devel] Question on prism54 driver In-Reply-To: <20050415165455.GA8741@bougret.hpl.hp.com> (Jean Tourrilhes's message of "Fri, 15 Apr 2005 09:54:55 -0700") References: <20050415165455.GA8741@bougret.hpl.hp.com> From: Rainer Weikusat Date: Fri, 15 Apr 2005 22:25:42 +0200 Message-ID: <878y3jrdmh.fsf@farside.sncag.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rainer.weikusat@sncag.com Precedence: bulk X-list: netdev Content-Length: 934 Lines: 26 Jean Tourrilhes writes: > Rainer Weikusat wrote : >> Jean-Baptiste Note writes: >> > Going through the prism54 code for reuse in the softmac driver, i >> > stumbled accross inconsistencies in the queue management functions for >> > the mgmt rx queue and the data rx queue that i cannot understand. >> >> >> No, you are just hacking the code without even having tried to >> understand >> >> a) what it is doing >> b) why it does this >> [which, "by coincedence", happens to be the reason that this driver is >> so thouroughly broken] >> >> >> BTW, I shouldn't be telling you how your code works, don't you think >> so? > > Ah ! It's so fun to blast an e-mail and flame away. > Now, I'm sorry to inform you that you got a few important fact > wrong, and that your critics were totally unjustified. Documentation on this stuff is available online for free. From jt@hpl.hp.com Fri Apr 15 13:34:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 13:34:12 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FKY7pw000329 for ; Fri, 15 Apr 2005 13:34:08 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 7E8FE37A; Fri, 15 Apr 2005 13:34:01 -0700 (PDT) Received: from bougret.hpl.hp.com (Debian-exim@bougret.hpl.hp.com [15.9.72.130]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA28294; Fri, 15 Apr 2005 13:35:19 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 4.50) id 1DMXVp-0002Mj-1K; Fri, 15 Apr 2005 13:34:01 -0700 Date: Fri, 15 Apr 2005 13:34:01 -0700 To: Rainer Weikusat Cc: prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re: Re : [Prism54-devel] Question on prism54 driver Message-ID: <20050415203401.GA9079@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20050415165455.GA8741@bougret.hpl.hp.com> <878y3jrdmh.fsf@farside.sncag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878y3jrdmh.fsf@farside.sncag.com> 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 User-Agent: Mutt/1.5.6+20040907i From: Jean Tourrilhes X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 658 Lines: 18 On Fri, Apr 15, 2005 at 10:25:42PM +0200, Rainer Weikusat wrote: > Jean Tourrilhes writes: > > > Now, I'm sorry to inform you that you got a few important fact > > wrong, and that your critics were totally unjustified. > > Documentation on this stuff is available online for free. Yes, but that still doesn't justify your particular criticism, and you could have replied "RTFM" or ignored the message. Don't worry, I also make errors, we are only humans... It's probably because I answer to many stupid/rtfm question from begginners that I don't get mad about it anymore... Have fun, enjoy your day, and let's close the case... Jean From dlstevens@us.ibm.com Fri Apr 15 13:43:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 13:43:21 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FKh70T001143; Fri, 15 Apr 2005 13:43:15 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3FKh2ua485922; Fri, 15 Apr 2005 16:43:02 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3FKgxL8250718; Fri, 15 Apr 2005 14:42:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3FKgx2v017278; Fri, 15 Apr 2005 14:42:59 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3FKgwvS017273; Fri, 15 Apr 2005 14:42:58 -0600 In-Reply-To: <20050415004102.GA23462@gondor.apana.org.au> To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Subject: Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Fri, 15 Apr 2005 13:42:56 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/15/2005 14:42:58, Serialize complete at 04/15/2005 14:42:58 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1765 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: 1353 Lines: 34 netdev-bounce@oss.sgi.com wrote on 04/14/2005 05:41:02 PM: > On Thu, Apr 14, 2005 at 05:31:38PM -0700, David Stevens wrote: > > > > > In fact with your patch we can end up calling ip6_flush_pending_frames > > > twice. Granted that it is currently harmless but it isn't nice. > > > > I don't see this. My original patch only calls > > ip6_flush_pending_frames() once, since the original code already only > You called ip6_flush_pending_frames() when rawv6_push_pending_frames > returned an error. However rawv6_push_pending_frames can return an > error that was in turn returned by ip6_push_pending_frames. > As you know ip6_push_pending_frames always frees the cork buffer so > this is tantamount to calling ip6_flush_pending_frames twice. I missed that, as you know. :-) You're right, of course. Thanks! > > I saw that in the code, but I also saw a 2K single skb when the > > MTU is 1500. A piece I looked at appeared to be allocating space for I tracked this down-- that particular test was running over loopback, with its larger MTU. So, no prob. here that I know of here, either. I've reviewed your patch and looks good to me. I've also tested it with my test cases for IPV6_CHECKSUM and they work fine. So, I'm good with your patch. +-DLS From hadi@cyberus.ca Fri Apr 15 14:44:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 14:44:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FLiI1m003185 for ; Fri, 15 Apr 2005 14:44:18 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DMYbp-0007vr-1P for netdev@oss.sgi.com; Fri, 15 Apr 2005 17:44:17 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DMYbh-0001IY-W6; Fri, 15 Apr 2005 17:44:10 -0400 Subject: Re: ACPI/HT or Packet Scheduler BUG? From: jamal Reply-To: hadi@cyberus.ca To: Steven Rostedt Cc: netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org In-Reply-To: <1113601029.4294.80.camel@localhost.localdomain> References: <1113601029.4294.80.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Fri, 15 Apr 2005 17:44:06 -0400 Message-Id: <1113601446.17859.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1766 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: 3229 Lines: 84 Didnt see the beginings of this thread - please post on netdev instead of lkml network related questions. The real cause seems to be an ARP issue from what i saw in the oops posted a while back: -- [4294692.342000] Call Trace: [4294692.342000] [] show_stack+0xa6/0xe0 [4294692.342000] [] show_registers+0x15b/0x1f0 [4294692.342000] [] die+0x141/0x2d0 [4294692.342000] [] do_page_fault+0x22e/0x6a6 [4294692.342000] [] error_code+0x4f/0x54 [4294692.342000] [] qdisc_restart+0xba/0x730 [4294692.342000] [] dev_queue_xmit+0x13e/0x640 [4294692.342000] [] arp_solicit+0xfc/0x210 [4294692.342000] [] neigh_timer_handler+0x13e/0x320 [4294692.342000] [] run_timer_softirq+0x130/0x490 [4294692.342000] [] __do_softirq+0x42/0xa0 [4294692.342000] [] do_softirq+0x51/0x60 ----- Is this the same issue? Can you describe how you create this issue; kernel version etc. cheers, jamal On Fri, 2005-15-04 at 17:37 -0400, Steven Rostedt wrote: > On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote: > > On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote: > > > > > So the problem should be looked in that changes to the pkt sched API, > > > the patch containing only those changes is at > > > > The bug is in this portion of code from net/sched/sch_generic.c, > > in the qdisc_destroy() function: > > > > == > > list_for_each_entry(cq, &cql, list) > > list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) > > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { > > if (q->ops->cl_ops == NULL) > > list_del_init(&q->list); > > else > > list_move_tail(&q->list, &cql); > > } > > list_for_each_entry_safe(cq, n, &cql, list) > > list_del_init(&cq->list); > > == > > > > ...and it happens when q->ops->cl_ops is NULL and > > list_del_init(&q->list) is executed. > > > > The stuff from include/linux/list.h looks ok, it seems like one > > of those two iterations (list_for_each_entry() and > > list_for_each_entry_safe()) enters an endless loop when an element is > > removed from the list under some circumstances. > > There's a comment above qdisc_destroy that says: > > /* Under dev->queue_lock and BH! */ > > I'm not so sure this is the case. I've included the emails of those > listed as Authors of sch_generic.c and sch_htb.c, hopefully they are the > ones who can help (if not, sorry to bother you). > > The list.h is fine, but if another task goes down this list when it > list_del_init is done, there's a chance that the reading task can get to > the deleted item just as it is being deleted, and has pointed itself to > itself. p->next == p. This would go into an infinite loop. > > The reason sysrq works is because this doesn't stop interrupts. But put > a local_irq_save around that list and run your test, I bet you won't be > able to do anything, but power off with the big button. > > Hope someone can help. I don't know the queue disciplines well enough to > make a proper fix. > > -- Steve > > > From rostedt@goodmis.org Fri Apr 15 14:54:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 14:54:41 -0700 (PDT) Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FLsXG8004010 for ; Fri, 15 Apr 2005 14:54:33 -0700 Received: from [192.168.23.9] (cpe-24-94-57-164.stny.res.rr.com [24.94.57.164]) by ms-smtp-04.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id j3FLsCpl012828; Fri, 15 Apr 2005 17:54:12 -0400 (EDT) Subject: Re: ACPI/HT or Packet Scheduler BUG? From: Steven Rostedt To: hadi@cyberus.ca Cc: netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org In-Reply-To: <1113601446.17859.36.camel@localhost.localdomain> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> Content-Type: text/plain Organization: Kihon Technologies Date: Fri, 15 Apr 2005 17:54:12 -0400 Message-Id: <1113602052.4294.89.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Status: Clean X-archive-position: 1767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rostedt@goodmis.org Precedence: bulk X-list: netdev Content-Length: 7499 Lines: 186 Don't think the issue is the same. This problem is happening with Tarhon-Onu Victor. I'm including his previous two posts from LKML here. So you can read the whole thing in one letter. He states that the problem started in 2.6.10-rc2 and looking at a diff, between rc1 and rc2 the list walk was added in qdisc_destroy. Take a look at his scripts and you may see that on a SMP machine, this my have a race condition. -- Steve >From April 8th: I am not subscribed to this list so please CC me if you post a reply, if you need additional info or if you suggest a patch (in which I would be very interested). Occurrence: - the kernels must be compiled with Hyper Threading support (and the CPU/MB must support it); - a (tc) process is reading statistics from the htb tree and another tries to delete or deletes the tree. The bug will not occur if the system is booted with acpi=off or if it's not SMP (HT) capable. I reproduced the bug on 2.6.10-1.770_FCsmp (Fedora Core update package) and vanilla 2.6.11, 2.6.11.5, 2.6.11.6, 2.6.12-rc1 and 2.6.12-rc2 compiled with SMP and ACPI support in order to enable Hyper Threading (with and without preempt, with or without SMT support). The compiler I used is GCC version 3.4.2 (from Fedora Core 3). Result: almost all the time the system hangs but still can execute SysRq commands. How I tested ~~~~~~~~~~~~ On a console I was running a script that initializes a htb tree on an interface (dummy0) in an endless loop: while /bin/true; do . htbdown.dummy0.sh; done ...and on another console I run tc -s also in an endless loop: while /bin/true; do tc -s class sh dev dummy0; done After a while (sometimes after 2 runs of the htbdown.dummy0.sh script, sometimes after 20) the system hangs. It still responds to SysRq commands and I was able to see the two tc processes running. Sometimes I still have ping replies from it and one time, just one time in 2 days I still was able to log in remotely. There are no printk messages, or no other warnings or errors printed in the system log or kernel log. It just hangs and it seems like something is wasting all the CPU power: when I still was able to log in I noticed that one of the two virtual CPUs was 100% with system interrupts and the other was 100% system. I wasn't able to strace any of the two running tc's. What I was able to paste with the mouse in my console, to catch in a typescript and also the script that initializes the htb tree on dummy0 can be found at ftp://blackblue.iasi.rdsnet.ro/pub/various/k/ . The test host is a 3.0GHz Intel Prescott and I first noticed the bug on a system with a 2.8GHz Intel Northwood, both having motherboards with Intel chipset (865GBF). I am not able to test it in other SMP environments (Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm not able to tell if it's an ACPI bug, a SMP bug or a Packet Scheduler bug. >From April 12th: On Fri, 8 Apr 2005, Tarhon-Onu Victor wrote: > I am not subscribed to this list so please CC me if you post a reply, > if you need additional info or if you suggest a patch (in which I would be > very interested). > [snip] > (Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm not able to tell > if it's an ACPI bug, a SMP bug or a Packet Scheduler bug. It seems like this bug is a packed scheduler one and it was introduced in 2.6.10-rc2. In the summary of changes from 2.6.10-rc1 to 2.6.10-rc2 there are a lot of changes announced for the packet scheduler. I removed all the changes of the packet scheduler files from the incremental patch 2.6.10-rc1 to 2.6.10-rc2, I applied it to 2.6.10-rc1 and the new 2.6.10-rc2-whithout-sched-changes does not hang. So the problem should be looked in that changes to the pkt sched API, the patch containing only those changes is at ftp://blackblue.iasi.rdsnet.ro/pub/various/k/patch-2.6.10-sched_changes-from_rc1-to-rc2.gz On Fri, 2005-04-15 at 17:44 -0400, jamal wrote: > Didnt see the beginings of this thread - please post on netdev instead > of lkml network related questions. > > The real cause seems to be an ARP issue from what i saw in the oops > posted a while back: > -- > [4294692.342000] Call Trace: > [4294692.342000] [] show_stack+0xa6/0xe0 > [4294692.342000] [] show_registers+0x15b/0x1f0 > [4294692.342000] [] die+0x141/0x2d0 > [4294692.342000] [] do_page_fault+0x22e/0x6a6 > [4294692.342000] [] error_code+0x4f/0x54 > [4294692.342000] [] qdisc_restart+0xba/0x730 > [4294692.342000] [] dev_queue_xmit+0x13e/0x640 > [4294692.342000] [] arp_solicit+0xfc/0x210 > [4294692.342000] [] neigh_timer_handler+0x13e/0x320 > [4294692.342000] [] run_timer_softirq+0x130/0x490 > [4294692.342000] [] __do_softirq+0x42/0xa0 > [4294692.342000] [] do_softirq+0x51/0x60 > ----- > > Is this the same issue? > Can you describe how you create this issue; kernel version etc. > > cheers, > jamal > > On Fri, 2005-15-04 at 17:37 -0400, Steven Rostedt wrote: > > On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote: > > > On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote: > > > > > > > So the problem should be looked in that changes to the pkt sched API, > > > > the patch containing only those changes is at > > > > > > The bug is in this portion of code from net/sched/sch_generic.c, > > > in the qdisc_destroy() function: > > > > > > == > > > list_for_each_entry(cq, &cql, list) > > > list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) > > > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { > > > if (q->ops->cl_ops == NULL) > > > list_del_init(&q->list); > > > else > > > list_move_tail(&q->list, &cql); > > > } > > > list_for_each_entry_safe(cq, n, &cql, list) > > > list_del_init(&cq->list); > > > == > > > > > > ...and it happens when q->ops->cl_ops is NULL and > > > list_del_init(&q->list) is executed. > > > > > > The stuff from include/linux/list.h looks ok, it seems like one > > > of those two iterations (list_for_each_entry() and > > > list_for_each_entry_safe()) enters an endless loop when an element is > > > removed from the list under some circumstances. > > > > There's a comment above qdisc_destroy that says: > > > > /* Under dev->queue_lock and BH! */ > > > > I'm not so sure this is the case. I've included the emails of those > > listed as Authors of sch_generic.c and sch_htb.c, hopefully they are the > > ones who can help (if not, sorry to bother you). > > > > The list.h is fine, but if another task goes down this list when it > > list_del_init is done, there's a chance that the reading task can get to > > the deleted item just as it is being deleted, and has pointed itself to > > itself. p->next == p. This would go into an infinite loop. > > > > The reason sysrq works is because this doesn't stop interrupts. But put > > a local_irq_save around that list and run your test, I bet you won't be > > able to do anything, but power off with the big button. > > > > Hope someone can help. I don't know the queue disciplines well enough to > > make a proper fix. > > > > -- Steve > > > > > > > From tgraf@suug.ch Fri Apr 15 15:54:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 15:54:16 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FMsAn2006136 for ; Fri, 15 Apr 2005 15:54:11 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 6D04E1C0EB; Sat, 16 Apr 2005 00:54:22 +0200 (CEST) Date: Sat, 16 Apr 2005 00:54:22 +0200 From: Thomas Graf To: Steven Rostedt Cc: hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050415225422.GF4114@postel.suug.ch> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113602052.4294.89.camel@localhost.localdomain> X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2344 Lines: 50 * Steven Rostedt <1113602052.4294.89.camel@localhost.localdomain> 2005-04-15 17:54 > > == > > list_for_each_entry(cq, &cql, list) > > list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) > > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { > > if (q->ops->cl_ops == NULL) > > list_del_init(&q->list); > > else > > list_move_tail(&q->list, &cql); > > } > > list_for_each_entry_safe(cq, n, &cql, list) > > list_del_init(&cq->list); > > == > > > > ...and it happens when q->ops->cl_ops is NULL and > > list_del_init(&q->list) is executed. > > > > The stuff from include/linux/list.h looks ok, it seems like one > > of those two iterations (list_for_each_entry() and > > list_for_each_entry_safe()) enters an endless loop when an element is > > removed from the list under some circumstances. > > There's a comment above qdisc_destroy that says: > > /* Under dev->queue_lock and BH! */ > > I'm not so sure this is the case. It's not, we should change the comment. qdisc_destroy calls for inner leaf qdiscs comming from rcu scheduled __qdisc_destroy -> qdisc::destroy() -> qdisc_destroy() will not have a lock on queue_lock but it shouldn't be a problem since the qdiscs cannot be found anymore. Another case were it's not locked is upon a deletion of a class where the class deletes its inner qdisc, although there is only one case how this can happen and that's under rtnl semaphore so there is no way we can have a dumper at the same time. A wild guess would be that one of the many wrong locking places where dev->queue_lock is acquired but qdisc_tree_lock is not is the problem. tc_dump_qdisc assumed that locking on qdisc_tree_lock is enough which is absolutely right, still most callers to qdisc_destroy only lock on dev->queue_lock for the modification of the tree, which _was_ fine before we used list.h since the unlinking was atomic. This is no news and Patrick's patch in 2.6.10 ought to have fixed this by unlinking inner leaf qdiscs from dev->qdisc_list and thus preventing them to be found by anyone during unlocked calls to destroy_qdisc. So... we might have a unlocked qdisc_destroy call for a qdisc not properly unlinked from dev->qdisc_list. From yoshfuji@linux-ipv6.org Fri Apr 15 17:54:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 17:55:01 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G0sslN012775 for ; Fri, 15 Apr 2005 17:54:54 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3435A33CC2; Sat, 16 Apr 2005 09:57:13 +0900 (JST) Date: Sat, 16 Apr 2005 09:57:13 +0900 (JST) Message-Id: <20050416.095713.110297063.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, tgohad@mvista.com, yoshfuji@linux-ipv6.or Subject: [PATCH] [IPV6]: Fix a branch prediction From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 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-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1769 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: 629 Lines: 21 From: Tushar Gohad Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/addrconf.c 1.135 vs edited ===== --- 1.135/net/ipv6/addrconf.c 2005-03-31 09:34:56 +09:00 +++ edited/net/ipv6/addrconf.c 2005-04-16 09:48:15 +09:00 @@ -571,7 +571,7 @@ out2: read_unlock_bh(&addrconf_lock); - if (unlikely(err == 0)) + if (likely(err == 0)) notifier_call_chain(&inet6addr_chain, NETDEV_UP, ifa); else { kfree(ifa); -- Hideaki YOSHIFUJI @ USAGI Project Homepage: http://www.yoshifuji.org/~hideaki/ GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Fri Apr 15 18:51:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 18:51:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G1pcNe014392 for ; Fri, 15 Apr 2005 18:51:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMcSZ-0003Uq-00; Sat, 16 Apr 2005 11:50:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMcQk-0000u9-00; Sat, 16 Apr 2005 11:49:06 +1000 Date: Sat, 16 Apr 2005 11:49:06 +1000 To: Thomas Graf Cc: Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416014906.GA3291@gondor.apana.org.au> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20050415225422.GF4114@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3269 Lines: 99 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 15, 2005 at 10:54:22PM +0000, Thomas Graf wrote: > > Another case were it's not locked is upon a deletion of a class where > the class deletes its inner qdisc, although there is only one case > how this can happen and that's under rtnl semaphore so there is no > way we can have a dumper at the same time. Sorry, that's where tc went astray :) The assumption that the rtnl is held during dumping is false. It is only true for the initial dump call. All subsequent dumps are not protected by the rtnl. The solution is certainly not to place the dumpers under rtnl :) The dump operation is read-only and should not need any exclusive locks. In fact the whole qdisc locking is a mess. It's a cross-breed between locking with ad-hoc reference counting and RCU. What's more, the RCU is completely useless too because for the case where we actually have a queue we still end up taking the spin lock on each transmit! I think someone's been benchmarking the loopback device again :) It needs to be reengineered. Here is a quick'n'dirty fix to the problem at hand. What happened between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started changing the next pointer of qdisc entries which totally confuses the readers because qdisc_destroy doesn't always take the tree lock. This patch tries to ensure that all top-level calls to qdisc_destroy come under the tree lock. As Thomas correctedly pointed out, most of the other qdisc_destroy calls occur after the top qdisc has been unlinked from the device qdisc_list. However, someone should go through each one of the remaining ones (they're all in the individual sch_* implementations) and make sure that this assumption is really true. Signed-off-by: Herbert Xu If anyone has cycles to spare and a stomach strong enough for this stuff, here is your chance :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/sched/sch_api.c 1.47 vs edited ===== --- 1.47/net/sched/sch_api.c 2005-04-01 14:35:56 +10:00 +++ edited/net/sched/sch_api.c 2005-04-16 08:47:16 +10:00 @@ -608,9 +608,9 @@ return err; if (q) { qdisc_notify(skb, n, clid, q, NULL); - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(q); - spin_unlock_bh(&dev->queue_lock); + qdisc_unlock_tree(dev); } } else { qdisc_notify(skb, n, clid, NULL, q); @@ -743,17 +743,17 @@ err = qdisc_graft(dev, p, clid, q, &old_q); if (err) { if (q) { - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(q); - spin_unlock_bh(&dev->queue_lock); + qdisc_unlock_tree(dev); } return err; } qdisc_notify(skb, n, clid, old_q, q); if (old_q) { - spin_lock_bh(&dev->queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(old_q); - spin_unlock_bh(&dev->queue_lock); + qdisc_unlock_tree(dev); } } return 0; --9amGYk9869ThD9tj-- From rostedt@goodmis.org Fri Apr 15 22:02:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 22:02:16 -0700 (PDT) Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G528l5022679 for ; Fri, 15 Apr 2005 22:02:09 -0700 Received: from [192.168.23.9] (cpe-24-94-57-164.stny.res.rr.com [24.94.57.164]) by ms-smtp-04.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id j3G51cpl008607; Sat, 16 Apr 2005 01:01:39 -0400 (EDT) Subject: Re: ACPI/HT or Packet Scheduler BUG? From: Steven Rostedt To: Herbert Xu Cc: Thomas Graf , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" In-Reply-To: <20050416014906.GA3291@gondor.apana.org.au> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> Content-Type: text/plain Organization: Kihon Technologies Date: Sat, 16 Apr 2005 01:01:37 -0400 Message-Id: <1113627698.4294.132.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Status: Clean X-archive-position: 1771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rostedt@goodmis.org Precedence: bulk X-list: netdev Content-Length: 1326 Lines: 34 On Sat, 2005-04-16 at 11:49 +1000, Herbert Xu wrote: > Here is a quick'n'dirty fix to the problem at hand. What happened > between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started > changing the next pointer of qdisc entries which totally confuses > the readers because qdisc_destroy doesn't always take the tree lock. > > This patch tries to ensure that all top-level calls to qdisc_destroy > come under the tree lock. As Thomas correctedly pointed out, most > of the other qdisc_destroy calls occur after the top qdisc has been > unlinked from the device qdisc_list. However, someone should go > through each one of the remaining ones (they're all in the individual > sch_* implementations) and make sure that this assumption is really > true. > > Signed-off-by: Herbert Xu > > If anyone has cycles to spare and a stomach strong enough for > this stuff, here is your chance :) > FYI, I ran the test case that Tarhon-Ohn had, but had to change his tc execution from batch to single lines since the version of tc I have segfaults on newlines. Anyway, I did see the lock up with 2.6.11.2 after 7 iterations. I applied your patch, and it ran for 30 iterations before I manually killed it. I didn't test any more than that, but this seems to be the quick fix for now. -- Steve From herbert@gondor.apana.org.au Fri Apr 15 23:27:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Apr 2005 23:27:35 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G6RPDX024580 for ; Fri, 15 Apr 2005 23:27:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMglk-0004ZD-00; Sat, 16 Apr 2005 16:27:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMgj2-0007b3-00; Sat, 16 Apr 2005 16:24:16 +1000 Date: Sat, 16 Apr 2005 16:24:16 +1000 To: Andrew Morton Cc: netdev@oss.sgi.com, svallet@gmail.com, Jeff Garzik Subject: Re: Fw: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of IPv6 Neighbor-discovery multicast Message-ID: <20050416062416.GA29177@gondor.apana.org.au> References: <20050413103642.172d3976.akpm@osdl.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20050413103642.172d3976.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1649 Lines: 50 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 13, 2005 at 05:36:42PM +0000, Andrew Morton wrote: > > Summary: natsemi: incorrect initialization of IPv6 Neighbor- > discovery multicast I've got a pair of FA312 cards and this problem has bothered me for ages. This has finally prompted me to do something about it :) Turns out that somebody wasn't following the documentation. We were doing 16-bit writes to 32-bit registers which led to some addresses working and others not so lucky. This patch should fix the problem. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=natsemi-1 ===== drivers/net/natsemi.c 1.74 vs edited ===== --- 1.74/drivers/net/natsemi.c 2005-03-03 16:00:42 +11:00 +++ edited/drivers/net/natsemi.c 2005-04-16 16:20:29 +10:00 @@ -2433,9 +2433,9 @@ rx_mode = RxFilterEnable | AcceptBroadcast | AcceptMulticast | AcceptMyPhys; for (i = 0; i < 64; i += 2) { - writew(HASH_TABLE + i, ioaddr + RxFilterAddr); - writew((mc_filter[i+1]<<8) + mc_filter[i], - ioaddr + RxFilterData); + writel(HASH_TABLE + i, ioaddr + RxFilterAddr); + writel((mc_filter[i + 1] << 8) + mc_filter[i], + ioaddr + RxFilterData); } } writel(rx_mode, ioaddr + RxFilterAddr); --PEIAKu/WMn1b1Hv9-- From Robert.Olsson@data.slu.se Sat Apr 16 00:23:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 00:23:55 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G7NlrN030487 for ; Sat, 16 Apr 2005 00:23:48 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3G7Njs7010507 for ; Sat, 16 Apr 2005 09:23:45 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 2D125EE1F1; Sat, 16 Apr 2005 09:23:45 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16992.48513.102876.620927@robur.slu.se> Date: Sat, 16 Apr 2005 09:23:45 +0200 To: Andre Tomt Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: FIB alternative fib_hash2.c In-Reply-To: <425FFA54.9070106@tomt.net> References: <16991.54602.218744.163816@robur.slu.se> <425FFA54.9070106@tomt.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1773 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: 1947 Lines: 53 Andre Tomt writes: > Drool. Got some numbers? pps - flows - memory use, on what hardware, > that sort of thing. For testing reasons I use pure rDoS with 1 dst per packet. Routing table is taken from bgp route some year ago w 123 kroutes. Also to test just FIB lookup I use the preroute paches to bypass dst hash this only works with gatewayed routes which is fine for me. Some numbers from a 1.6 GHz Opteron. rDoS at 720 kpps injected in eth0. result is what get out on eth1, eth3. Current FIB ----------- Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 2346827 9125541 9125541 7653595 262 0 0 0 BRU eth1 1500 0 4 0 0 0 2325770 0 0 0 BRU eth2 1500 0 0 0 0 0 5 0 0 0 BRU eth3 1500 0 1 0 0 0 20652 0 0 0 BRU eth4 1500 0 0 0 0 0 5 0 0 0 BRU New hash2 ---------- eth0 1500 0 4389455 8372826 8372826 5610843 199 0 0 0 BRU eth1 1500 0 2 0 0 0 4349633 0 0 0 BRU eth2 1500 0 0 0 0 0 5 0 0 0 BRU eth3 1500 0 1 0 0 0 38875 0 0 0 BRU eth4 1500 0 0 0 0 0 5 0 0 0 BRU 168 kpps vs 316 kpps on this box so quite substantial improvement and if you can merge local and main table you get even more. Well to honest we can merge tables do this current FIB too. Mem usage IP: FIB vers 0.58 routing table of 16777216 buckets, 65536Kbytes for table id=255 So ~66 MB for hash structure to that comes routing info this can too a lot as hash2 makes /24 prefix-clones of prefixes in range 0>plen>24, I see 294 MB for the full BGP table. I have some single flow numbers if you are interested too. Cheers. --ro From laforge@gnumonks.org Sat Apr 16 01:21:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 01:21:10 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G8L3Ap032114 for ; Sat, 16 Apr 2005 01:21:03 -0700 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DMiY1-0000s3-M6; Sat, 16 Apr 2005 10:21:02 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1DMiY0-000495-E3; Sat, 16 Apr 2005 10:21:00 +0200 Date: Sat, 16 Apr 2005 10:21:00 +0200 From: Harald Welte To: Linux Netdev List Cc: David Miller Subject: (some persisting) troubles with neighbour cache code backport (even) in 2.4.30 Message-ID: <20050416082100.GY25433@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PCSS5jcV3Z4INoC2" Content-Disposition: inline User-Agent: mutt-ng 1.5.8-r168i (Debian) X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 6242 Lines: 166 --PCSS5jcV3Z4INoC2 Content-Type: multipart/mixed; boundary="84JQvybYWNxrNqac" Content-Disposition: inline --84JQvybYWNxrNqac Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I just received this bug report. I'll try to look into it later today/tomorrow, but just in case somebody else has thoughts on this, I'm forwarding it. Thanks! --=20 - Harald Welte http://gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --84JQvybYWNxrNqac Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from ganesha.gnumonks.org ([unix socket]) by ganesha (Cyrus v2.1.17-IPv6-Debian-2.1.17-0woody.3.1) with LMTP; Wed, 13 Apr 2005 22:19:13 +0200 X-Sieve: CMU Sieve 2.2 Return-path: Received: from vishnu.netfilter.org ([213.95.27.115]) by ganesha.gnumonks.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DLoKP-0008L2-HW for laforge@gnumonks.org; Wed, 13 Apr 2005 22:19:13 +0200 Received: from cedric.unob.cz ([160.216.40.10]) by vishnu.netfilter.org with esmtp (Exim 4.41 #1 (Debian)) id 1DLoPJ-0001Va-2L for ; Wed, 13 Apr 2005 22:24:20 +0200 Received: from localhost (rafaj@localhost) by cedric.unob.cz (8.12.10/8.12.10) with ESMTP id j3DKIuxc005914; Wed, 13 Apr 2005 22:19:00 +0200 Date: Wed, 13 Apr 2005 22:18:56 +0200 (MEST) From: Jan Rafaj To: laforge@netfilter.org Subject: (some persisting) troubles with neighbour cache code backport (even) in 2.4.30 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Spam-Score: -2.3 (--) Hi Harald, First of all, please excuse me for bothering you this way and for my amusing english (not used to write/speak it everyday). I'll try to be as brief as possible. Please note I'm not a programmer (although with certain C skills), and consider me a joe-blow Linux user (somewhat advanced since I do linux sysadm work for 10 years). I'm writing this in a hurry, so it may look horrible, but its better to report than nothing, I guess. I've recently decided to upgrade to 2.4.30 kernel on one of my routers, from 2.4.26 it has been running up to now. All went smoothly, except of one thing: I suddenly experienced that the router suddenly stopped sending traffic to its default destination route. By taking a look at ARP table, everything was OK - specifically, the gateway IP's ARP record was cached as normal. I just tried to delete the ARP record for gateway IP - and that has forced router to elicit ARP query for the peer (which it didnt send before for a long time), and the traffic was sent to gateway IP again! However, this state semi-randomly persisted ranging only from several minutes up to few hours, according to my observation. After that time, the router again lost the track to gateway IP (and manual deletion of cached ARP record for the gateway IP was needed again). It occasionally resurrected itself (after few hours, usually), but then everything was just repeating with same symptoms. And that circle went for several days, while I was investigating. Here, I have to say that the mentioned router has somewhat fairly 'odd' routing table: Most (direct, interface) routes are of 'host route' type, added by command like: ifconfig eth0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255 I know that according to RFCs that shouldnt be (and all that stuff that says that broadcasting capability is required for ethernet media - indeed it is, but in '2 endpoints involved' scenario ARP broadcast capability is really only necessary), but it works, has worked long time ago already and is still used in some special situations like in my case (assigned small range of 'public' IPs, and the effort to save as much those precious IPs for real machines has lead one to use private IPs on router interfaces pointing to client machines - please consider that also all those 'client' ethernet links have just two points (the client machine and router interface). First I suspected it might be just becouse of old e100 & e1000 drivers, so I've replaced them (compiled from scratch, of course; I always do compile everything) with those published directly by INTEL (that helped in case of 2.4.26, where I had another problem, that just turned out to be a driver issue). That didnt help. As I didnt want to downgrade back to 2.4.26 *just* becouse of this, I googled a bit more and came by to an 'dual ARP records' issue someone had reported with 2.4.28. Starting to suspect ARP code, I just quicky "backported" the original neighbour ARP handling code from 2.4.26 to 2.4.30 - by editing/replacing following files: ./include/net/neighbour.h ./net/core/neighbour.c ./net/ipv4/arp.c ./net/decnet/dn_route.c ./net/decnet/dn_neigh.c ./net/atm/proc.c ./net/netsyms.c And that helped! Now I again see the router asks for gateway IP's ARP in 1min. intervals again. And no odd 'gateway IP suddenly not responding & router sends no ARP queries after a minute' anymore. Please note that I didnt observe this strange problem on other routers here (already running 2.4.30), that have, however, more 'common' setup than the one mentioned above (usual routes with commonly used matching netmasks & broadcast addresses). Should I investigate more thoroughly (should you want exact reports from me), please let me know. Do you think you could look at this issue? Thanks & best regards, Jan --84JQvybYWNxrNqac-- --PCSS5jcV3Z4INoC2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCYMrsXaXGVTD0i/8RAjqpAJ9P8AoX5tEOq9ZmEsann6bj8iW0lgCdHPmI +B329uc+gdNnJtFxCnI09nA= =QIPV -----END PGP SIGNATURE----- --PCSS5jcV3Z4INoC2-- From andre@tomt.net Sat Apr 16 01:55:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 01:55:16 -0700 (PDT) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G8t9jg000625 for ; Sat, 16 Apr 2005 01:55:11 -0700 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 4F72A8858B; Sat, 16 Apr 2005 10:55:07 +0200 (CEST) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id BEF3B88586; Sat, 16 Apr 2005 10:55:04 +0200 (CEST) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id B324D22A62; Sat, 16 Apr 2005 10:55:04 +0200 (CEST) Message-ID: <4260D2EB.6070400@tomt.net> Date: Sat, 16 Apr 2005 10:55:07 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: FIB alternative fib_hash2.c References: <16991.54602.218744.163816@robur.slu.se> <425FFA54.9070106@tomt.net> <16992.48513.102876.620927@robur.slu.se> In-Reply-To: <16992.48513.102876.620927@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 1775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 2420 Lines: 57 Robert Olsson wrote: > Andre Tomt writes: > > > Drool. Got some numbers? pps - flows - memory use, on what hardware, > > that sort of thing. > > For testing reasons I use pure rDoS with 1 dst per packet. Routing table > is taken from bgp route some year ago w 123 kroutes. > > Also to test just FIB lookup I use the preroute paches to bypass dst > hash this only works with gatewayed routes which is fine for me. > > Some numbers from a 1.6 GHz Opteron. rDoS at 720 kpps injected in eth0. > result is what get out on eth1, eth3. > > > Current FIB > ----------- > Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags > eth0 1500 0 2346827 9125541 9125541 7653595 262 0 0 0 BRU > eth1 1500 0 4 0 0 0 2325770 0 0 0 BRU > eth2 1500 0 0 0 0 0 5 0 0 0 BRU > eth3 1500 0 1 0 0 0 20652 0 0 0 BRU > eth4 1500 0 0 0 0 0 5 0 0 0 BRU > > > New hash2 > ---------- > eth0 1500 0 4389455 8372826 8372826 5610843 199 0 0 0 BRU > eth1 1500 0 2 0 0 0 4349633 0 0 0 BRU > eth2 1500 0 0 0 0 0 5 0 0 0 BRU > eth3 1500 0 1 0 0 0 38875 0 0 0 BRU > eth4 1500 0 0 0 0 0 5 0 0 0 BRU > > > 168 kpps vs 316 kpps on this box so quite substantial improvement and if > you can merge local and main table you get even more. Well to honest we > can merge tables do this current FIB too. Nice. What kind of equipment and/or software do you use to generate this sort of traffic pattern? And how much is one expected to gain by merging local and main tables? I try to avoid policy routing wherever possible - so merging is very interesting indeed. > Mem usage > > IP: FIB vers 0.58 routing table of 16777216 buckets, 65536Kbytes for table id=255 > > So ~66 MB for hash structure to that comes routing info this can too a lot > as hash2 makes /24 prefix-clones of prefixes in range 0>plen>24, I see > 294 MB for the full BGP table. I reckon this would be limited to available lowmem on 32bit (ick) systems? > I have some single flow numbers if you are interested too. If its not too much trouble I would apriciate it. From tgraf@suug.ch Sat Apr 16 04:06:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 04:06:37 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GB6NYo006431 for ; Sat, 16 Apr 2005 04:06:24 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 4F9391C0EB; Sat, 16 Apr 2005 13:06:39 +0200 (CEST) Date: Sat, 16 Apr 2005 13:06:39 +0200 From: Thomas Graf To: Herbert Xu Cc: Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416110639.GI4114@postel.suug.ch> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416014906.GA3291@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2217 Lines: 51 * Herbert Xu <20050416014906.GA3291@gondor.apana.org.au> 2005-04-16 11:49 > On Fri, Apr 15, 2005 at 10:54:22PM +0000, Thomas Graf wrote: > > > > Another case were it's not locked is upon a deletion of a class where > > the class deletes its inner qdisc, although there is only one case > > how this can happen and that's under rtnl semaphore so there is no > > way we can have a dumper at the same time. > > Sorry, that's where tc went astray :) > > The assumption that the rtnl is held during dumping is false. It is > only true for the initial dump call. All subsequent dumps are not > protected by the rtnl. Ahh.. it's the unlocked subsequent dump calls that are _still_ running when the destroy is invoked. That's where Patrick and I went wrong when we tried to fix this issue. We set our t0 to qdisc_destroy and didn't really consider any prior unlocked tasks still running. > In fact the whole qdisc locking is a mess. It's a cross-breed > between locking with ad-hoc reference counting and RCU. What's > more, the RCU is completely useless too because for the case > where we actually have a queue we still end up taking the spin > lock on each transmit! I think someone's been benchmarking the > loopback device again :) It's not completely useless, it speeds up the deletion classful qdiscs having some depth. However, it's not worth the locking troubles I guess. > Here is a quick'n'dirty fix to the problem at hand. I think it's pretty clean but it doesn't solve the problem completely, see below. > This patch tries to ensure that all top-level calls to qdisc_destroy > come under the tree lock. As Thomas correctedly pointed out, most > of the other qdisc_destroy calls occur after the top qdisc has been > unlinked from the device qdisc_list. However, someone should go > through each one of the remaining ones (they're all in the individual > sch_* implementations) and make sure that this assumption is really > true. qdisc_destroy can still be invoked without qdisc_tree_lock via the deletion of a class when it calls qdisc_destroy to destroy its leaf qdisc. > If anyone has cycles to spare and a stomach strong enough for > this stuff, here is your chance :) I will look into this. From herbert@gondor.apana.org.au Sat Apr 16 04:14:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 04:15:00 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GBEhLR007167 for ; Sat, 16 Apr 2005 04:14:43 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMlFY-0005WS-00; Sat, 16 Apr 2005 21:14:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMlE4-0008DS-00; Sat, 16 Apr 2005 21:12:36 +1000 Date: Sat, 16 Apr 2005 21:12:36 +1000 To: Thomas Graf Cc: Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416111236.GA31550@gondor.apana.org.au> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416110639.GI4114@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 622 Lines: 18 On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote: > > qdisc_destroy can still be invoked without qdisc_tree_lock via the > deletion of a class when it calls qdisc_destroy to destroy its > leaf qdisc. Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock which is another name for qdisc_tree_lock. CBQ on the other hand needs to have a little tweak. > I will look into this. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Apr 16 04:25:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 04:25:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GBPI3b011263 for ; Sat, 16 Apr 2005 04:25:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DMlPY-0005YS-00; Sat, 16 Apr 2005 21:24:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DMlOb-0008Hy-00; Sat, 16 Apr 2005 21:23:29 +1000 Date: Sat, 16 Apr 2005 21:23:29 +1000 To: Thomas Graf Cc: Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416112329.GA31847@gondor.apana.org.au> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416110639.GI4114@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 590 Lines: 14 On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote: > > It's not completely useless, it speeds up the deletion classful > qdiscs having some depth. However, it's not worth the locking > troubles I guess. RCU is meant to optimise the common reader path. In this case that's the packet transmission code. Unfortunately it fails miserably when judged by that criterion. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Sat Apr 16 04:34:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 04:34:38 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GBYUqN011911 for ; Sat, 16 Apr 2005 04:34:30 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 639F71C0EB; Sat, 16 Apr 2005 13:34:46 +0200 (CEST) Date: Sat, 16 Apr 2005 13:34:46 +0200 From: Thomas Graf To: Herbert Xu Cc: Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416113446.GJ4114@postel.suug.ch> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> <20050416112329.GA31847@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416112329.GA31847@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 897 Lines: 18 * Herbert Xu <20050416112329.GA31847@gondor.apana.org.au> 2005-04-16 21:23 > On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote: > > > > It's not completely useless, it speeds up the deletion classful > > qdiscs having some depth. However, it's not worth the locking > > troubles I guess. > > RCU is meant to optimise the common reader path. In this case > that's the packet transmission code. Unfortunately it fails > miserably when judged by that criterion. There is one case where it can do good for latency which is for per flow qdiscs or any other scenarios implying hundreds or thousands of leaf qdiscs where a destroyage of one such qdisc tree will take up quite some cpu to traverse all the classes under dev->queue_lock. I don't have any numbers on this, but I don't completely dislike the method of hiding the qdiscs under the lock and do the expensive traveling unlocked. From linux_lover2004@yahoo.com Sat Apr 16 07:14:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 07:14:47 -0700 (PDT) Received: from web52203.mail.yahoo.com (web52203.mail.yahoo.com [206.190.39.85]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3GEEfiP017564 for ; Sat, 16 Apr 2005 07:14:41 -0700 Received: (qmail 60971 invoked by uid 60001); 16 Apr 2005 14:14:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=3XnHmeNb687aJ9lNslPbgKaGgtBHGke+F6/lkFhGHu5StWHZHx0F1BgODJSjX2Nof2CSVn0UOvvqEcyaVXL6US8P9AJ3+ApMHFJj9io7ApeqrRHU4Zl3hCAYI245eWJMWo7n0NpbPEX5HMJGz3EcDoIfuzGCjXzr5BEp5jyho6A= ; Message-ID: <20050416141435.60969.qmail@web52203.mail.yahoo.com> Received: from [202.56.231.117] by web52203.mail.yahoo.com via HTTP; Sat, 16 Apr 2005 07:14:35 PDT Date: Sat, 16 Apr 2005 07:14:35 -0700 (PDT) From: linux lover Subject: kfree_skb gives oops To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 584 Lines: 20 hello, I am checking some conditions in packet after IP header is removed and based on that want network stack to discard skbuff so i add it in ip_input.c . But it gives oops message that Warning: kfree_skb passed an skb still on a list and then prints oops Please help how to do that and correct me to use a way by which i will not face any kernel panic message? Thanks in advance. regards, linux_lover. __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From jkriger@cwazy.co.uk Sat Apr 16 08:31:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 08:31:41 -0700 (PDT) Received: from dylan.cwazy.net (dylan.cwazy.net [195.10.244.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GFVYJk023291 for ; Sat, 16 Apr 2005 08:31:34 -0700 Received: from www.cwazy.co.uk (localhost [127.0.0.1]) by dylan.cwazy.net (Postfix) with ESMTP id 8554BD9F11; Sat, 16 Apr 2005 15:30:28 +0000 (UTC) Received: from 200.55.71.239 (SquirrelMail authenticated user jkriger); by www.cwazy.net with HTTP; Sat, 16 Apr 2005 12:30:28 -0300 (ART) Message-ID: <1763.200.55.71.239.1113665428.squirrel@200.55.71.239> In-Reply-To: <20050412143541.260fdff4@dxpl.pdx.osdl.net> References: <20050412143541.260fdff4@dxpl.pdx.osdl.net> Date: Sat, 16 Apr 2005 12:30:28 -0300 (ART) Subject: Re: [Netem] [PATCH] netem: change packet scheduling From: "Julio Kriger" To: "Stephen Hemminger" Cc: "David S. Miller" , netdev@oss.sgi.com, netem@lists.osdl.org Reply-To: jkriger@hotpop.com User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkriger@cwazy.co.uk Precedence: bulk X-list: netdev Content-Length: 6795 Lines: 242 Hi! I've installed linux-2.6.11-r5 on my PC and I couldn't apply the patch. I get: julio root # patch -p1 --dry-run < patch_netem.patch missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- sch_netem.c 2005-04-04 09:39:41.000000000 -0700 |+++ sch_netem.c 2005-04-06 15:54:09.514780384 -0700 -------------------------- File to patch: n/sch_netem.c patching file n/sch_netem.c patch: **** malformed patch at line 5: ('n' is a softlink to /usr/src/linux/net/sched) From what I read, this patch is to apply to a linux-2.6.12-rc2. Could you change it so I could apply it to a linux-2.6.11-r5, please? TIA. Regards, Julio -- ------------------------------- Julio Kriger jkriger AT hotpop DOT com jkriger AT cwazy DOT co DOT uk > Netem was dumping packets into the child qdisc when timer expires. > This creates problems if netem is not the root qdisc and can even cause > a livelock situation. This patch changes it to only transfer packets > during > the enqueue/dequeue routines. > > This alternative makes netem be self clocking as well, so if using the CPU > counter for the timing source it is possible to get smoother (non bursty) > throughput. It also corrects the bug where a delay of 0 would always cause > a delay of 1 tick. > > Signed-off-by: Stephen Hemminger > > --- linux-2.6.12-rc2/net/sched/sch_netem.c 2005-04-04 09:39:41.000000000 > -0700 > +++ netem/net/sched/sch_netem.c 2005-04-06 15:54:09.514780384 -0700 > @@ -138,38 +138,78 @@ > } > > /* Put skb in the private delayed queue. */ > -static int delay_skb(struct Qdisc *sch, struct sk_buff *skb) > +static int netem_delay(struct Qdisc *sch, struct sk_buff *skb) > { > struct netem_sched_data *q = qdisc_priv(sch); > - struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; > psched_tdiff_t td; > psched_time_t now; > > PSCHED_GET_TIME(now); > td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); > - PSCHED_TADD2(now, td, cb->time_to_send); > > /* Always queue at tail to keep packets in order */ > if (likely(q->delayed.qlen < q->limit)) { > + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; > + > + PSCHED_TADD2(now, td, cb->time_to_send); > + > + pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, > + now, cb->time_to_send); > + > __skb_queue_tail(&q->delayed, skb); > - if (!timer_pending(&q->timer)) { > - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); > - add_timer(&q->timer); > - } > return NET_XMIT_SUCCESS; > } > > + pr_debug("netem_delay: queue over limit %d\n", q->limit); > + sch->qstats.overlimits++; > kfree_skb(skb); > return NET_XMIT_DROP; > } > > +/* > + * Move a packet that is ready to send from the delay holding > + * list to the underlying qdisc. > + */ > +static int netem_run(struct Qdisc *sch) > +{ > + struct netem_sched_data *q = qdisc_priv(sch); > + struct sk_buff *skb; > + psched_time_t now; > + > + PSCHED_GET_TIME(now); > + > + skb = skb_peek(&q->delayed); > + if (skb) { > + const struct netem_skb_cb *cb > + = (const struct netem_skb_cb *)skb->cb; > + long delay > + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); > + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); > + > + /* if more time remaining? */ > + if (delay > 0) { > + mod_timer(&q->timer, jiffies + delay); > + return 1; > + } > + > + __skb_unlink(skb, &q->delayed); > + > + if (q->qdisc->enqueue(skb, q->qdisc)) { > + sch->q.qlen--; > + sch->qstats.drops++; > + } > + } > + > + return 0; > +} > + > static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) > { > struct netem_sched_data *q = qdisc_priv(sch); > struct sk_buff *skb2; > int ret; > > - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); > + pr_debug("netem_enqueue skb=%p\n", skb); > > /* Random packet drop 0 => none, ~0 => all */ > if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { > @@ -184,7 +224,7 @@ > && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { > pr_debug("netem_enqueue: dup %p\n", skb2); > > - if (delay_skb(sch, skb2)) { > + if (netem_delay(sch, skb2)) { > sch->q.qlen++; > sch->bstats.bytes += skb2->len; > sch->bstats.packets++; > @@ -202,7 +242,8 @@ > ret = q->qdisc->enqueue(skb, q->qdisc); > } else { > q->counter = 0; > - ret = delay_skb(sch, skb); > + ret = netem_delay(sch, skb); > + netem_run(sch); > } > > if (likely(ret == NET_XMIT_SUCCESS)) { > @@ -241,56 +282,35 @@ > return len; > } > > -/* Dequeue packet. > - * Move all packets that are ready to send from the delay holding > - * list to the underlying qdisc, then just call dequeue > - */ > static struct sk_buff *netem_dequeue(struct Qdisc *sch) > { > struct netem_sched_data *q = qdisc_priv(sch); > struct sk_buff *skb; > + int pending; > + > + pending = netem_run(sch); > > skb = q->qdisc->dequeue(q->qdisc); > - if (skb) > + if (skb) { > + pr_debug("netem_dequeue: return skb=%p\n", skb); > sch->q.qlen--; > + sch->flags &= ~TCQ_F_THROTTLED; > + } > + else if (pending) { > + pr_debug("netem_dequeue: throttling\n"); > + sch->flags |= TCQ_F_THROTTLED; > + } > + > return skb; > } > > static void netem_watchdog(unsigned long arg) > { > struct Qdisc *sch = (struct Qdisc *)arg; > - struct netem_sched_data *q = qdisc_priv(sch); > - struct net_device *dev = sch->dev; > - struct sk_buff *skb; > - psched_time_t now; > > - pr_debug("netem_watchdog: fired @%lu\n", jiffies); > - > - spin_lock_bh(&dev->queue_lock); > - PSCHED_GET_TIME(now); > - > - while ((skb = skb_peek(&q->delayed)) != NULL) { > - const struct netem_skb_cb *cb > - = (const struct netem_skb_cb *)skb->cb; > - long delay > - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); > - pr_debug("netem_watchdog: skb %p@%lu %ld\n", > - skb, jiffies, delay); > - > - /* if more time remaining? */ > - if (delay > 0) { > - mod_timer(&q->timer, jiffies + delay); > - break; > - } > - __skb_unlink(skb, &q->delayed); > - > - if (q->qdisc->enqueue(skb, q->qdisc)) { > - sch->q.qlen--; > - sch->qstats.drops++; > - } > - } > - qdisc_run(dev); > - spin_unlock_bh(&dev->queue_lock); > + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); > + sch->flags &= ~TCQ_F_THROTTLED; > + netif_schedule(sch->dev); > } > > static void netem_reset(struct Qdisc *sch) > @@ -301,6 +321,7 @@ > skb_queue_purge(&q->delayed); > > sch->q.qlen = 0; > + sch->flags &= ~TCQ_F_THROTTLED; > del_timer_sync(&q->timer); > } > > _______________________________________________ > Netem mailing list > Netem@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/netem > From hadi@cyberus.ca Sat Apr 16 09:04:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 09:04:37 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GG4UtG026694 for ; Sat, 16 Apr 2005 09:04:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DMpmL-00045W-Mk for netdev@oss.sgi.com; Sat, 16 Apr 2005 12:04:17 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DMpmF-0008G1-39; Sat, 16 Apr 2005 12:04:11 -0400 Subject: Re: ACPI/HT or Packet Scheduler BUG? From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , Steven Rostedt , netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" In-Reply-To: <20050416113446.GJ4114@postel.suug.ch> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> <20050416112329.GA31847@gondor.apana.org.au> <20050416113446.GJ4114@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Sat, 16 Apr 2005 12:04:07 -0400 Message-Id: <1113667447.7419.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1783 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: 1384 Lines: 31 On Sat, 2005-16-04 at 13:34 +0200, Thomas Graf wrote: > * Herbert Xu <20050416112329.GA31847@gondor.apana.org.au> 2005-04-16 21:23 > > On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote: > > > > > > It's not completely useless, it speeds up the deletion classful > > > qdiscs having some depth. However, it's not worth the locking > > > troubles I guess. > > > > RCU is meant to optimise the common reader path. In this case > > that's the packet transmission code. Unfortunately it fails > > miserably when judged by that criterion. > > There is one case where it can do good for latency which is for > per flow qdiscs or any other scenarios implying hundreds or > thousands of leaf qdiscs where a destroyage of one such qdisc > tree will take up quite some cpu to traverse all the classes > under dev->queue_lock. I don't have any numbers on this, but > I don't completely dislike the method of hiding the qdiscs under > the lock and do the expensive traveling unlocked. The rule of "optimize for the common" fails miserably in this case because this is not a common case/usage of qdiscs. I have a feeling though that the patch went in due to dude-optimizing-loopback as pointed by Herbert. It could also be it was done because RCU-is-so-cool. I dont recall. Maybe worth reverting to the earlier scheme if it is going to continue to be problematic. cheers, jamal From tgraf@suug.ch Sat Apr 16 11:21:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Apr 2005 11:21:08 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GIKx4Y030240 for ; Sat, 16 Apr 2005 11:21:02 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1BFF71C0EB; Sat, 16 Apr 2005 20:21:15 +0200 (CEST) Date: Sat, 16 Apr 2005 20:21:14 +0200 From: Thomas Graf To: jamal Cc: Herbert Xu , Steven Rostedt , netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, Patrick McHardy , "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050416182114.GL4114@postel.suug.ch> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> <20050416112329.GA31847@gondor.apana.org.au> <20050416113446.GJ4114@postel.suug.ch> <1113667447.7419.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113667447.7419.9.camel@localhost.localdomain> X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 819 Lines: 20 * jamal <1113667447.7419.9.camel@localhost.localdomain> 2005-04-16 12:04 > The rule of "optimize for the common" fails miserably in this case > because this is not a common case/usage of qdiscs. I tend to agree. OTOH, I use exactly such setups... ;-> > I have a feeling though that the patch went in due to > dude-optimizing-loopback as pointed by Herbert. I checked, it was in fact during the lockless loopback optimizations. > Maybe worth reverting to the earlier scheme if it is going to continue > to be problematic. Let me first check and see how the locking can be done at best, it doesn't match the principles in sch_generic.c anyway at the moment so once we know how to do the locking efficient and how to remove the error proneess we can see if the optimization fits in without problems and make a call. From jchapman@katalix.com Sun Apr 17 06:00:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 06:00:22 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HD0Hpt023154 for ; Sun, 17 Apr 2005 06:00:17 -0700 Received: from jchapman.plus.com ([84.92.108.75] helo=[192.168.1.10]) by s14.s14avahost.net with esmtpa (Exim 4.44) id 1DN9Nl-0004Vy-Tw; Sun, 17 Apr 2005 08:00:14 -0500 Message-ID: <42625DDB.4090600@katalix.com> Date: Sun, 17 Apr 2005 14:00:11 +0100 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Andy Fleming CC: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org, Benjamin Herrenschmidt Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <423734FB.40101@katalix.com> <96c50184a02557c88dee0e6d17f3a539@freescale.com> In-Reply-To: <96c50184a02557c88dee0e6d17f3a539@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 1795 Lines: 41 Andy Fleming wrote: > Ok, here's the new patch with changes suggested by James Chapman: I guess I still have questions about the way interrupts are used. Using an interrupt to schedule a work queue which then sets a variable that is used by a timer seems odd. Why not do all the work in the work queue and schedule it from the interrupt handler or timer? Many network devices have status bits in their interrupt status registers to indicate PHY events. These bits are handled in the network device driver; there is no separate irq. It would obviously be good to change these drivers to hook up your abstraction layer to handle PHY functions. You suggested previously that the network driver and PHY driver could share the irq when the PHY's interrupt is indicated through the network device's status registers. I still don't see how SA_SHIRQ could work given that the PHY code uses disable_irq_nosync() and enable_irq() when handling interrupts. If the irq is shared with the net device interrupt, this will cause packet interrupts to stop until the phy's work queue callback is called. If the irq is shared with other possibly unrelated devices, other bad effects could occur. Perhaps the following code (taken from phy_change()) could be called by the net driver when link state changes are detected by its interrupt or NAPI poll handler? if ((PHY_RUNNING == phydev->state) || (PHY_NOLINK == phydev->state)) { phydev->state = PHY_CHANGELINK; schedule_work(&phydev->phy_queue); } In the above case, the net driver would use phy_connect() to connect its PHY and phydev->irq would be -1 to disable use of PHY interrupts by the PHY code. Would this work? If so, a new API function for net drivers to call would be useful. Also, did you mean to leave the #if 0 code in davicom.c? /james From kaber@trash.net Sun Apr 17 08:38:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 08:38:43 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HFccf4032217 for ; Sun, 17 Apr 2005 08:38:38 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DNBr6-00064v-KS; Sun, 17 Apr 2005 17:38:40 +0200 Message-ID: <42628300.9010007@trash.net> Date: Sun, 17 Apr 2005 17:38:40 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> In-Reply-To: <20050407120417.4297cd14@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 290 Lines: 9 Stephen Hemminger wrote: > Would this work better.? It just increases qlen by +/- 1 on enqueue, dequeue. > It also allows < 1ms delays if there is enough traffic going through. It looks better, but with duplication there can still be an increment of 2 in netem_enqueue(). Regards Patrick From kaber@trash.net Sun Apr 17 10:47:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 10:47:08 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HHl263004744 for ; Sun, 17 Apr 2005 10:47:02 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DNDqa-0006ff-UW; Sun, 17 Apr 2005 19:46:16 +0200 Message-ID: <4262A0E8.9020905@trash.net> Date: Sun, 17 Apr 2005 19:46:16 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Thomas Graf , Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> <20050416111236.GA31550@gondor.apana.org.au> In-Reply-To: <20050416111236.GA31550@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 566 Lines: 17 Herbert Xu wrote: > On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote: > >>qdisc_destroy can still be invoked without qdisc_tree_lock via the >>deletion of a class when it calls qdisc_destroy to destroy its >>leaf qdisc. > > Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock > which is another name for qdisc_tree_lock. CBQ on the other hand > needs to have a little tweak. HTB also needs to be fixed. Destruction is usually defered by the refcnt until ->put(), htb_put() doesn't lock the tree. Same for HFSC and CBQ. Regards Patrick From herbert@gondor.apana.org.au Sun Apr 17 14:40:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 14:40:31 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HLeMjd016446 for ; Sun, 17 Apr 2005 14:40:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DNHUM-0006d5-00; Mon, 18 Apr 2005 07:39:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DNHSP-0005qr-00; Mon, 18 Apr 2005 07:37:33 +1000 Date: Mon, 18 Apr 2005 07:37:33 +1000 To: Patrick McHardy Cc: Thomas Graf , Steven Rostedt , hadi@cyberus.ca, netdev , Tarhon-Onu Victor , kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: ACPI/HT or Packet Scheduler BUG? Message-ID: <20050417213733.GB22372@gondor.apana.org.au> References: <1113601029.4294.80.camel@localhost.localdomain> <1113601446.17859.36.camel@localhost.localdomain> <1113602052.4294.89.camel@localhost.localdomain> <20050415225422.GF4114@postel.suug.ch> <20050416014906.GA3291@gondor.apana.org.au> <20050416110639.GI4114@postel.suug.ch> <20050416111236.GA31550@gondor.apana.org.au> <4262A0E8.9020905@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4262A0E8.9020905@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 458 Lines: 12 On Sun, Apr 17, 2005 at 07:46:16PM +0200, Patrick McHardy wrote: > > HTB also needs to be fixed. Destruction is usually defered by the > refcnt until ->put(), htb_put() doesn't lock the tree. Same for > HFSC and CBQ. Yes you're absolutely right. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mcgrof@gmail.com Sun Apr 17 15:24:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 15:25:07 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HMOwEP018326 for ; Sun, 17 Apr 2005 15:24:59 -0700 Received: by wproxy.gmail.com with SMTP id 68so1294901wri for ; Sun, 17 Apr 2005 15:24:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q2aRe1OcmIeM60GF681Z27O1WYA+G6cvL3tuYNn5SeM9I0Bx5eWwcu462T7lOXbwXF+Ije7TW9fwGezqCI2Eh6QpSq+G6Cg+PqfPInmf9I1cBhLodHBhVl7lMfZRYe+9AgVBlQXJ8tSjTYbcODphrIjg67sh+KN5TtJvf54joQc= Received: by 10.54.40.34 with SMTP id n34mr3783734wrn; Sun, 17 Apr 2005 15:24:53 -0700 (PDT) Received: by 10.54.13.56 with HTTP; Sun, 17 Apr 2005 15:24:53 -0700 (PDT) Message-ID: <43e72e8905041715247c8765f0@mail.gmail.com> Date: Sun, 17 Apr 2005 18:24:53 -0400 From: "Luis R. Rodriguez" Reply-To: "Luis R. Rodriguez" To: "Randy.Dunlap" Subject: Re: [PATCH] prism54: fix printk format warnings Cc: netdev@oss.sgi.com, jgarzik , mcgrof@ruslug.rutgers.edu, prism54-devel@prism54.org In-Reply-To: <20050301212137.57f9532f.rddunlap@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050301212137.57f9532f.rddunlap@osdl.org> X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3HMOwEP018326 X-archive-position: 1789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@gmail.com Precedence: bulk X-list: netdev Content-Length: 3730 Lines: 78 Thanks Randy. This is already in prism54 svn tree. Feel free to apply Jeff. Luis On 3/2/05, Randy.Dunlap wrote: > > prism54 build shows some printk format complaints: > (sparc64 build warning) > > drivers/net/wireless/prism54/isl_38xx.c:131: warning: long int format, different type arg (arg 3) > drivers/net/wireless/prism54/isl_38xx.c:151: warning: long int format, different type arg (arg 3) > > cross-compile results: > https://www.osdl.org/plm-cgi/plm?module=patch_info&patch_id=4240 > > Signed-off-by: Randy Dunlap > > diffstat:= > drivers/net/wireless/prism54/isl_38xx.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff -Naurp ./drivers/net/wireless/prism54/isl_38xx.c~prism_printk ./drivers/net/wireless/prism54/isl_38xx.c > --- ./drivers/net/wireless/prism54/isl_38xx.c~prism_printk 2004-12-24 13:34:45.000000000 -0800 > +++ ./drivers/net/wireless/prism54/isl_38xx.c 2005-03-01 20:15:00.189995120 -0800 > @@ -125,11 +125,11 @@ isl38xx_trigger_device(int asleep, void > #if VERBOSE > SHOW_ERROR_MESSAGES > do_gettimeofday(¤t_time); > DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", > - current_time.tv_sec, current_time.tv_usec); > + current_time.tv_sec, (long)current_time.tv_usec); > #endif > > DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", > - current_time.tv_sec, current_time.tv_usec, > + current_time.tv_sec, (long)current_time.tv_usec, > readl(device_base + ISL38XX_CTRL_STAT_REG)); > udelay(ISL38XX_WRITEIO_DELAY); > > @@ -139,7 +139,7 @@ isl38xx_trigger_device(int asleep, void > do_gettimeofday(¤t_time); > DEBUG(SHOW_TRACING, > "%08li.%08li Device register abadface\n", > - current_time.tv_sec, current_time.tv_usec); > + current_time.tv_sec, (long)current_time.tv_usec); > #endif > /* read the Device Status Register until Sleepmode bit is set */ > while (reg = readl(device_base + ISL38XX_CTRL_STAT_REG), > @@ -150,7 +150,7 @@ isl38xx_trigger_device(int asleep, void > > DEBUG(SHOW_TRACING, > "%08li.%08li Device register read %08x\n", > - current_time.tv_sec, current_time.tv_usec, > + current_time.tv_sec, (long)current_time.tv_usec, > readl(device_base + ISL38XX_CTRL_STAT_REG)); > udelay(ISL38XX_WRITEIO_DELAY); > > @@ -158,7 +158,7 @@ isl38xx_trigger_device(int asleep, void > do_gettimeofday(¤t_time); > DEBUG(SHOW_TRACING, > "%08li.%08li Device asleep counter %i\n", > - current_time.tv_sec, current_time.tv_usec, > + current_time.tv_sec, (long)current_time.tv_usec, > counter); > #endif > } > @@ -174,7 +174,7 @@ isl38xx_trigger_device(int asleep, void > #if VERBOSE > SHOW_ERROR_MESSAGES > do_gettimeofday(¤t_time); > DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", > - current_time.tv_sec, current_time.tv_usec, reg); > + current_time.tv_sec, (long)current_time.tv_usec, reg); > #endif > } else { > /* device is (still) awake */ > > --- > From acme@ghostprotocols.net Sun Apr 17 16:03:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 16:03:33 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HN3P6V019676 for ; Sun, 17 Apr 2005 16:03:27 -0700 Received: from [200.103.136.131] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DNIpJ-0007Tj-00; Sun, 17 Apr 2005 20:05:17 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 975CB2C014; Sun, 17 Apr 2005 19:54:33 -0300 (BRT) Date: Sun, 17 Apr 2005 19:54:33 -0300 To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH][IPV6] export inet6_sock_nr Message-ID: <20050417225433.GC10626@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev Content-Length: 502 Lines: 20 Hi David, Please apply, SCTP/DCCP needs this. - Arnaldo Signed-off-by: Arnaldo Carvalho de Melo Index: net/ipv6/af_inet6.c =================================================================== --- net/ipv6/af_inet6.c (revision 57) +++ net/ipv6/af_inet6.c (working copy) @@ -88,6 +88,7 @@ #ifdef INET_REFCNT_DEBUG atomic_t inet6_sock_nr; +EXPORT_SYMBOL(inet6_sock_nr); #endif /* The inetsw table contains everything that inet_create needs to From bunk@stusta.de Sun Apr 17 16:47:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 16:47:52 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3HNljFd025577 for ; Sun, 17 Apr 2005 16:47:47 -0700 Received: (qmail 31195 invoked from network); 17 Apr 2005 23:47:39 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 17 Apr 2005 23:47:39 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 06688AF9C3; Mon, 18 Apr 2005 01:47:39 +0200 (CEST) Date: Mon, 18 Apr 2005 01:47:39 +0200 From: Adrian Bunk To: Alan Cox Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: [2.6 patch] drivers/net/wan/: possible cleanups Message-ID: <20050417234738.GY3625@stusta.de> References: <20050327143418.GE4285@stusta.de> <1111941516.14877.325.camel@localhost.localdomain> <20050414232028.GD20400@stusta.de> <1113587392.11155.33.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113587392.11155.33.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1198 Lines: 35 On Fri, Apr 15, 2005 at 06:49:56PM +0100, Alan Cox wrote: > On Gwe, 2005-04-15 at 00:20, Adrian Bunk wrote: > > On Sun, Mar 27, 2005 at 05:38:38PM +0100, Alan Cox wrote: > > > On Sul, 2005-03-27 at 15:34, Adrian Bunk wrote: > > > > - syncppp.c: sppp_input > > > > - syncppp.c: sppp_change_mtu > > > > - z85230.c: z8530_dma_sync > > > > - z85230.c: z8530_txdma_sync > > > > > > Please leave the z85230 ones at least. They are an intentional part of > > > the external API for writing other 85230 card drivers. > > > > If they are part of an API, why aren't the prototypes for them in any > > header file? > > They were once. I guess that got "tided" at some point, possibly long > ago even before submission. >... Are there any external drivers using these exports, and if there are, why aren't they in the kernel? If there aren't and someone will at some time in the future need them, re-adding the exports will be trivial. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From herbert@gondor.apana.org.au Sun Apr 17 19:09:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 19:09:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I29UAP029872 for ; Sun, 17 Apr 2005 19:09:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DNLgm-0008Ji-00; Mon, 18 Apr 2005 12:08:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DNLfx-0000yd-00; Mon, 18 Apr 2005 12:07:49 +1000 From: Herbert Xu To: tgraf@suug.ch (Thomas Graf) Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Cc: fmp@palmen.homeip.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050411125113.GL26731@postel.suug.ch> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 18 Apr 2005 12:07:49 +1000 X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 868 Lines: 28 Thomas Graf wrote: > > OK, I think the problem is a few missing dev_hold() when the net_device > handle is assigned to routes, probes, etc. Indeed. Here is a patch that adds the references that are held by the routes. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/appletalk/ddp.c 1.58 vs edited ===== --- 1.58/net/appletalk/ddp.c 2005-03-27 09:04:35 +10:00 +++ edited/net/appletalk/ddp.c 2005-04-18 11:29:17 +10:00 @@ -573,6 +573,7 @@ /* Fill in the routing entry */ rt->target = ta->sat_addr; + dev_hold(devhint); rt->dev = devhint; rt->flags = r->rt_flags; rt->gateway = ga->sat_addr; From jesse.brandeburg@intel.com Sun Apr 17 23:11:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Apr 2005 23:11:33 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I6BRaa007436 for ; Sun, 17 Apr 2005 23:11:27 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3I6BLBn032150 for ; Mon, 18 Apr 2005 06:11:21 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3I6BLgZ011682 for ; Mon, 18 Apr 2005 06:11:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041723112124842 for ; Sun, 17 Apr 2005 23:11:21 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 23:11:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: NAPI, e100, and system performance problem Date: Sun, 17 Apr 2005 23:11:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAPI, e100, and system performance problem Thread-Index: AcVD3XBXq/Y2JwRxTPm1KUfm1LRaig== From: "Brandeburg, Jesse" To: X-OriginalArrivalTime: 18 Apr 2005 06:11:21.0200 (UTC) FILETIME=[70F70F00:01C543DD] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3I6BRaa007436 X-archive-position: 1793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 3934 Lines: 107 _Summary_ As the part owner of the e100 driver, this issue has been nagging at me for a while. NAPI seems to be able to swamp a system with interrupts and context switches. In this case the system does not respond to having zero cpu cycles available by polling more, as I figured it would. This was mostly based on observation, but I included some quick data gathering for this mail. _Background_ I've noticed that when napi is enabled on a 10/100 (e100.c) adapter, that if I push a lot of small packets through the 10/100 adapter that the system begins to show interrupt lag. In this case it is 64 bit power processor machine. The processors on this machine generally execute code very quickly, while the bus is a little slow With the current e100 driver in NAPI mode the adapter can generate upwards of 36000 interrupts a second from only receiving 77000 packets/second (pktgen traffic) _test 1_ I really couldn't think of a decent way to show the lag except to say that the network and keyboard visibly lag when a 10/100 adapter is pounding away. *** Here is the localhost ping data first with an idle system --- 127.0.0.1 ping statistics --- 100000 packets transmitted, 100000 received, 0% packet loss, time 4332ms rtt min/avg/max/mdev = 0.008/0.009/0.077/0.005 ms, pipe 2, ipg/ewma 0.043/0.010 ms *** now while receiving ~77000 packets per second of discardable traffic --- 127.0.0.1 ping statistics --- 100000 packets transmitted, 100000 received, 0% packet loss, time 26370ms rtt min/avg/max/mdev = 0.008/0.010/9.410/0.034 ms, pipe 2, ipg/ewma 0.263/0.010 ms *** ping took 4.3 seconds unloaded and 26.4 seconds when receiving traffic. _test 2_ Run netperf with 10 threads to localhost in order to stress the cpus netserver; netperf -l 60 -H localhost Shows 100% cpu utilization Start pktgen at other end, and these are the results from vmstat 2 13 0 0 3711936 95192 92932 0 0 0 0 2 41175 10 90 0 0 14 0 0 3711872 95192 92932 0 0 0 0 16 41886 11 89 0 0 13 0 0 3711824 95192 92932 0 0 0 30 3 44299 11 89 0 0 13 0 0 3711952 95192 92932 0 0 0 0 5 77821 9 91 0 0 --->>> pktgen starts 13 0 0 3711888 95192 92932 0 0 0 16 27057 74014 7 93 0 0 12 0 0 3712016 95192 92932 0 0 0 0 34001 36483 8 92 0 0 13 1 0 3711952 95192 92932 0 0 0 28 31673 35748 8 92 0 0 14 0 0 3711952 95192 92932 0 0 0 2 32145 1411 9 91 0 0 14 0 0 3711952 95192 92932 0 0 0 0 32166 1231 9 91 0 0 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 14 0 0 3712088 95192 92932 0 0 0 0 32157 2597 9 91 0 0 13 0 0 3711960 95192 92932 0 0 0 0 32130 1210 9 91 0 0 13 1 0 3711832 95192 92932 0 0 0 28 32095 1182 9 91 0 0 13 0 0 3712088 95192 92932 0 0 0 68 33023 11742 9 91 0 0 14 0 0 3711888 95192 92932 0 0 0 0 32460 1279 9 91 0 0 14 0 0 3712080 95192 92932 0 0 0 30 32126 1908 9 91 0 0 14 0 0 3711952 95192 92932 0 0 0 0 32736 22616 8 92 0 0 *** I expected a more significant drop in interrupts/sec _conclusion_ Is there any way we can configure how soon or often to be polled (called)? For 100Mb speeds at worst we can get about one 64 byte packet every 9us (if I did my math right) and since the processors don't take that long to schedule NAPI, process a packet and handle an interrupt, we just overload the system with interrupts going into and out of napi mode. In this case I only have one adapter getting scheduled. Suggestions? Help? Want me to do more tests? Thanks for sticking with me... Jesse -- Jesse Brandeburg From mchan@broadcom.com Mon Apr 18 00:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 00:41:04 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I7ew0c024241 for ; Mon, 18 Apr 2005 00:40:58 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 00:40:48 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 00:40:46 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATP08207; Mon, 18 Apr 2005 00:40:44 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA09131; Mon, 18 Apr 2005 00:40:44 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 07:40:42 +0000 Received: from rh4 by nt-irva-0741; 17 Apr 2005 23:42:31 -0700 Subject: [PATCH 2.6.12-rc2 0/11] tg3: Add complete support for 5752 From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <04132005193843.8300@laptop> References: <04132005193843.8300@laptop> Date: Sun, 17 Apr 2005 23:42:31 -0700 Message-ID: <1113806551.6504.11.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DBB0A29G367789-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 449 Lines: 9 These patches should be applied on top of John Linville's patches posted a few days ago. The last 2 patches are MSI patches for 5751 C0 and 5752. They are very similar to the MSI patches posted a few weeks ago. I've modified the MSI test patch to display a warning message to ask the user to report the failure if the MSI test fails. If Jeff still objects to this, then just skip patch 11 but apply patch 10 which enables MSI on the latest chips. From mchan@broadcom.com Mon Apr 18 00:49:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 00:49:13 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I7n7Q1024928 for ; Mon, 18 Apr 2005 00:49:07 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 00:49:26 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 00:48:51 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ00105; Mon, 18 Apr 2005 00:48:49 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA09801; Mon, 18 Apr 2005 00:48:49 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 07:48:48 +0000 Received: from rh4 by nt-irva-0741; 17 Apr 2005 23:50:37 -0700 Subject: [PATCH 2.6.12-rc2 1/11] tg3: Minor 5752 fixes From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> Date: Sun, 17 Apr 2005 23:50:37 -0700 Message-ID: <1113807037.6504.17.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DB90C1OC366902-01-01 Content-Type: multipart/mixed; boundary="=-zs1q4b0+IhXKtD3KuRFt" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 5085 Lines: 82 --=-zs1q4b0+IhXKtD3KuRFt Content-Type: text/plain Content-Transfer-Encoding: 7bit Some minor 5752 fixes mostly for correctness and add 5752 PHY ID. Signed-off-by: Michael Chan --=-zs1q4b0+IhXKtD3KuRFt Content-Disposition: attachment; filename=tg3-101.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-101.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwMC9kcml2ZXJzL25ldC90ZzMuYyAxMDEvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDAvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxMzo0ODozMC4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDEvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNDowODoxNi4wMDAwMDAw MDAgLTA3MDANCkBAIC0xMDk0LDcgKzEwOTQsNyBAQA0KIAkJICAgICBDTE9DS19DVFJMX0FMVENM SyB8DQogCQkgICAgIENMT0NLX0NUUkxfUFdSRE9XTl9QTEwxMzMpOw0KIAkJdWRlbGF5KDQwKTsN Ci0JfSBlbHNlIGlmICghKChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gNTc1 MCkgJiYNCisJfSBlbHNlIGlmICghKCh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3NTBfUExV UykgJiYNCiAJCSAgICAgKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19FTkFCTEVfQVNGKSkpIHsN CiAJCXUzMiBuZXdiaXRzMSwgbmV3Yml0czI7DQogDQpAQCAtNTIzNyw4ICs1MjM3LDExIEBADQog CQkgICAgICBSRE1BQ19NT0RFX0xOR1JFQURfRU5BQik7DQogCWlmICh0cC0+dGczX2ZsYWdzICYg VEczX0ZMQUdfU1BMSVRfTU9ERSkNCiAJCXJkbWFjX21vZGUgfD0gUkRNQUNfTU9ERV9TUExJVF9F TkFCTEU7DQotCWlmICgodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpICYmDQot CSAgICAgdHAtPnBjaV9jaGlwX3Jldl9pZCAhPSBDSElQUkVWX0lEXzU3MDVfQTApIHsNCisNCisJ LyogSWYgc3RhdGVtZW50IGFwcGxpZXMgdG8gNTcwNSBhbmQgNTc1MCBQQ0kgZGV2aWNlcyBvbmx5 ICovDQorCWlmICgoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVW XzU3MDUgJiYNCisJICAgICB0cC0+cGNpX2NoaXBfcmV2X2lkICE9IENISVBSRVZfSURfNTcwNV9B MCkgfHwNCisJICAgIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19S RVZfNTc1MCkpIHsNCiAJCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1RTT19DQVBBQkxF ICYmDQogCQkgICAgKHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9JRF81NzA1X0ExIHx8 DQogCQkgICAgIHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9JRF81NzA1X0EyKSkgew0K QEAgLTUyNDksNiArNTI1Miw5IEBADQogCQl9DQogCX0NCiANCisJaWYgKHRwLT50ZzNfZmxhZ3My ICYgVEczX0ZMRzJfUENJX0VYUFJFU1MpDQorCQlyZG1hY19tb2RlIHw9IFJETUFDX01PREVfRklG T19MT05HX0JVUlNUOw0KKw0KICNpZiBURzNfVFNPX1NVUFBPUlQgIT0gMA0KIAlpZiAodHAtPnRn M19mbGFnczIgJiBURzNfRkxHMl9IV19UU08pDQogCQlyZG1hY19tb2RlIHw9ICgxIDw8IDI3KTsN CkBAIC01MzUxLDggKzUzNTcsMTAgQEANCiAJICAgICAgIFdETUFDX01PREVfRklGT1VSVU5fRU5B QiB8IFdETUFDX01PREVfRklGT09SRUFEX0VOQUIgfA0KIAkgICAgICAgV0RNQUNfTU9ERV9MTkdS RUFEX0VOQUIpOw0KIA0KLQlpZiAoKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTcwNV9QTFVT KSAmJg0KLQkgICAgIHRwLT5wY2lfY2hpcF9yZXZfaWQgIT0gQ0hJUFJFVl9JRF81NzA1X0EwKSB7 DQorCS8qIElmIHN0YXRlbWVudCBhcHBsaWVzIHRvIDU3MDUgYW5kIDU3NTAgUENJIGRldmljZXMg b25seSAqLw0KKwlpZiAoKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lD X1JFVl81NzA1ICYmDQorCSAgICAgdHAtPnBjaV9jaGlwX3Jldl9pZCAhPSBDSElQUkVWX0lEXzU3 MDVfQTApIHx8DQorCSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJ Q19SRVZfNTc1MCkgew0KIAkJaWYgKCh0cC0+dGczX2ZsYWdzICYgVEczX0ZMRzJfVFNPX0NBUEFC TEUpICYmDQogCQkgICAgKHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9JRF81NzA1X0Ex IHx8DQogCQkgICAgIHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9JRF81NzA1X0EyKSkg ew0KQEAgLTcwMjUsNyArNzAzMyw3IEBADQogCQl0dzMyKE5WUkFNX0NGRzEsIG52Y2ZnMSk7DQog CX0NCiANCi0JaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTc1MF9QTFVTKSB7DQorCWlm IChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkgew0K IAkJc3dpdGNoIChudmNmZzEgJiBOVlJBTV9DRkcxX1ZFTkRPUl9NQVNLKSB7DQogCQkJY2FzZSBG TEFTSF9WRU5ET1JfQVRNRUxfRkxBU0hfQlVGRkVSRUQ6DQogCQkJCXRwLT5udnJhbV9qZWRlY251 bSA9IEpFREVDX0FUTUVMOw0KQEAgLTg0NjIsNyArODQ3MCw4IEBADQogCQkvKiBETUEgcmVhZCB3 YXRlcm1hcmsgbm90IHVzZWQgb24gUENJRSAqLw0KIAkJdHAtPmRtYV9yd2N0cmwgfD0gMHgwMDE4 MDAwMDsNCiAJfSBlbHNlIGlmICghKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19QQ0lYX01PREUp KSB7DQotCQlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpDQorCQlpZiAo R0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUgfHwNCisJ CSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkN CiAJCQl0cC0+ZG1hX3J3Y3RybCB8PSAweDAwM2YwMDAwOw0KIAkJZWxzZQ0KIAkJCXRwLT5kbWFf cndjdHJsIHw9IDB4MDAzZjAwMGY7DQpAQCAtODYyOCw2ICs4NjM3LDcgQEANCiAJY2FzZSBQSFlf SURfQkNNNTcwNDoJcmV0dXJuICI1NzA0IjsNCiAJY2FzZSBQSFlfSURfQkNNNTcwNToJcmV0dXJu ICI1NzA1IjsNCiAJY2FzZSBQSFlfSURfQkNNNTc1MDoJcmV0dXJuICI1NzUwIjsNCisJY2FzZSBQ SFlfSURfQkNNNTc1MjoJcmV0dXJuICI1NzUyIjsNCiAJY2FzZSBQSFlfSURfQkNNODAwMjoJcmV0 dXJuICI4MDAyL3NlcmRlcyI7DQogCWNhc2UgMDoJCQlyZXR1cm4gInNlcmRlcyI7DQogCWRlZmF1 bHQ6CQlyZXR1cm4gInVua25vd24iOw0KZGlmZiAtTnJ1IDEwMC9kcml2ZXJzL25ldC90ZzMuaCAx MDEvZHJpdmVycy9uZXQvdGczLmgNCi0tLSAxMDAvZHJpdmVycy9uZXQvdGczLmgJMjAwNS0wNC0x NSAxMzo0ODozMC4wMDAwMDAwMDAgLTA3MDANCisrKyAxMDEvZHJpdmVycy9uZXQvdGczLmgJMjAw NS0wNC0xNSAxNDowODoxNi4wMDAwMDAwMDAgLTA3MDANCkBAIC0yMTUwLDYgKzIxNTAsNyBAQA0K ICNkZWZpbmUgUEhZX0lEX0JDTTU3MDQJCQkweDYwMDA4MTkwDQogI2RlZmluZSBQSFlfSURfQkNN NTcwNQkJCTB4NjAwMDgxYTANCiAjZGVmaW5lIFBIWV9JRF9CQ001NzUwCQkJMHg2MDAwODE4MA0K KyNkZWZpbmUgUEhZX0lEX0JDTTU3NTIJCQkweDYwMDA4MTAwDQogI2RlZmluZSBQSFlfSURfQkNN ODAwMgkJCTB4NjAwMTAxNDANCiAjZGVmaW5lIFBIWV9JRF9JTlZBTElECQkJMHhmZmZmZmZmZg0K ICNkZWZpbmUgUEhZX0lEX1JFVl9NQVNLCQkJMHgwMDAwMDAwZg0K --=-zs1q4b0+IhXKtD3KuRFt-- From herbert@gondor.apana.org.au Mon Apr 18 01:10:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:10:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8AW5R029677 for ; Mon, 18 Apr 2005 01:10:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DNRKR-0001Tw-00; Mon, 18 Apr 2005 18:09:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DNRJW-0001Tr-00; Mon, 18 Apr 2005 18:09:02 +1000 Date: Mon, 18 Apr 2005 18:09:02 +1000 To: Thomas Graf Cc: fmp@palmen.homeip.net, netdev@oss.sgi.com, "David S. Miller" Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050418080902.GA5675@gondor.apana.org.au> References: <20050411125113.GL26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 639 Lines: 16 On Mon, Apr 18, 2005 at 12:07:49PM +1000, Herbert Xu wrote: > > Indeed. Here is a patch that adds the references that are held by > the routes. BTW, there are other problems in the appletalk stack that should be fixed too. For instance, the route entries and skb's there don't hold a reference to the device that they point to. So if anyone is going to spend time on appletalk then they should have a look at them. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mchan@broadcom.com Mon Apr 18 01:11:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:11:43 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8Ba1f029793 for ; Mon, 18 Apr 2005 01:11:37 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:06:43 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:06:44 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ02653; Mon, 18 Apr 2005 01:06:43 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA11478; Mon, 18 Apr 2005 01:06:43 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:06:42 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 07:08:31 +0000 Subject: [PATCH 2.6.12-rc2 2/11] tg3: Split tg3_phy_probe into 2 functions From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113807037.6504.17.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113807037.6504.17.camel@rh4> Date: Mon, 18 Apr 2005 00:08:31 -0700 Message-ID: <1113808111.6504.32.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DB503294381239-01-01 Content-Type: multipart/mixed; boundary="=-J94+mrcKePHBGYnkIiLG" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 5601 Lines: 91 --=-J94+mrcKePHBGYnkIiLG Content-Type: text/plain Content-Transfer-Encoding: 7bit Split the 1st half of tg3_phy_probe() into tg3_get_eeprom_hw_cfg() so that the TG3_FLAG_EEPROM_WRITE_PROT can be determined before calling tg3_set_power_state() in tg3_get_invariants(). This will allow tg3_set_power_state() to drive the GPIOs correctly based on the config. information in eeprom. On the 5752, there are no pull-up resistors on the GPIO pins and it is necessary to drive the unused GPIOs as output. Signed-off-by: Michael Chan --=-J94+mrcKePHBGYnkIiLG Content-Disposition: attachment; filename=tg3-102.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; charset=utf-8; name=tg3-102.patch ZGlmZiAtTnJ1IDEwMS9kcml2ZXJzL25ldC90ZzMuYyAxMDIvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDEvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNDowODoxNi4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDIvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNDo0MDoxMC4wMDAwMDAw MDAgLTA3MDANCkBAIC03NTQyLDIxICs3NTQyLDI3IEBADQogCXJldHVybiBOVUxMOw0KIH0NCiAN Ci1zdGF0aWMgaW50IF9fZGV2aW5pdCB0ZzNfcGh5X3Byb2JlKHN0cnVjdCB0ZzMgKnRwKQ0KKy8q IFNpbmNlIHRoaXMgZnVuY3Rpb24gbWF5IGJlIGNhbGxlZCBpbiBEMy1ob3QgcG93ZXIgc3RhdGUg ZHVyaW5nDQorICogdGczX2luaXRfb25lKCksIG9ubHkgY29uZmlnIGN5Y2xlcyBhcmUgYWxsb3dl ZC4NCisgKi8NCitzdGF0aWMgdm9pZCBfX2RldmluaXQgdGczX2dldF9lZXByb21faHdfY2ZnKHN0 cnVjdCB0ZzMgKnRwKQ0KIHsNCi0JdTMyIGVlcHJvbV9waHlfaWQsIGh3X3BoeV9pZF8xLCBod19w aHlfaWRfMjsNCi0JdTMyIGh3X3BoeV9pZCwgaHdfcGh5X2lkX21hc2tlZDsNCiAJdTMyIHZhbDsN Ci0JaW50IGVlcHJvbV9zaWduYXR1cmVfZm91bmQsIGVlcHJvbV9waHlfc2VyZGVzLCBlcnI7DQor DQorCS8qIE1ha2Ugc3VyZSByZWdpc3RlciBhY2Nlc3NlcyAoaW5kaXJlY3Qgb3Igb3RoZXJ3aXNl KQ0KKwkgKiB3aWxsIGZ1bmN0aW9uIGNvcnJlY3RseS4NCisJICovDQorCXBjaV93cml0ZV9jb25m aWdfZHdvcmQodHAtPnBkZXYsIFRHM1BDSV9NSVNDX0hPU1RfQ1RSTCwNCisJCQkgICAgICAgdHAt Pm1pc2NfaG9zdF9jdHJsKTsNCiANCiAJdHAtPnBoeV9pZCA9IFBIWV9JRF9JTlZBTElEOw0KLQll ZXByb21fcGh5X2lkID0gUEhZX0lEX0lOVkFMSUQ7DQotCWVlcHJvbV9waHlfc2VyZGVzID0gMDsN Ci0JZWVwcm9tX3NpZ25hdHVyZV9mb3VuZCA9IDA7DQorCXRwLT5sZWRfY3RybCA9IExFRF9DVFJM X01PREVfUEhZXzE7DQorDQogCXRnM19yZWFkX21lbSh0cCwgTklDX1NSQU1fREFUQV9TSUcsICZ2 YWwpOw0KIAlpZiAodmFsID09IE5JQ19TUkFNX0RBVEFfU0lHX01BR0lDKSB7DQogCQl1MzIgbmlj X2NmZywgbGVkX2NmZzsNCi0JCXUzMiBuaWNfcGh5X2lkLCB2ZXIsIGNmZzIgPSAwOw0KKwkJdTMy IG5pY19waHlfaWQsIHZlciwgY2ZnMiA9IDAsIGVlcHJvbV9waHlfaWQ7DQorCQlpbnQgZWVwcm9t X3BoeV9zZXJkZXMgPSAwOw0KIA0KIAkJdGczX3JlYWRfbWVtKHRwLCBOSUNfU1JBTV9EQVRBX0NG RywgJm5pY19jZmcpOw0KIAkJdHAtPm5pY19zcmFtX2RhdGFfY2ZnID0gbmljX2NmZzsNCkBAIC03 NTY5LDggKzc1NzUsNiBAQA0KIAkJICAgICh2ZXIgPiAwKSAmJiAodmVyIDwgMHgxMDApKQ0KIAkJ CXRnM19yZWFkX21lbSh0cCwgTklDX1NSQU1fREFUQV9DRkdfMiwgJmNmZzIpOw0KIA0KLQkJZWVw cm9tX3NpZ25hdHVyZV9mb3VuZCA9IDE7DQotDQogCQlpZiAoKG5pY19jZmcgJiBOSUNfU1JBTV9E QVRBX0NGR19QSFlfVFlQRV9NQVNLKSA9PQ0KIAkJICAgIE5JQ19TUkFNX0RBVEFfQ0ZHX1BIWV9U WVBFX0ZJQkVSKQ0KIAkJCWVlcHJvbV9waHlfc2VyZGVzID0gMTsNCkBAIC03NTg2LDYgKzc1OTAs MTAgQEANCiAJCX0gZWxzZQ0KIAkJCWVlcHJvbV9waHlfaWQgPSAwOw0KIA0KKwkJdHAtPnBoeV9p ZCA9IGVlcHJvbV9waHlfaWQ7DQorCQlpZiAoZWVwcm9tX3BoeV9zZXJkZXMpDQorCQkJdHAtPnRn M19mbGFnczIgfD0gVEczX0ZMRzJfUEhZX1NFUkRFUzsNCisNCiAJCWlmICh0cC0+dGczX2ZsYWdz MiAmIFRHM19GTEcyXzU3NTBfUExVUykNCiAJCQlsZWRfY2ZnID0gY2ZnMiAmIChOSUNfU1JBTV9E QVRBX0NGR19MRURfTU9ERV9NQVNLIHwNCiAJCQkJICAgIFNIQVNUQV9FWFRfTEVEX01PREVfTUFT Syk7DQpAQCAtNzY1Myw2ICs3NjYxLDEzIEBADQogCQlpZiAoY2ZnMiAmICgxIDw8IDE4KSkNCiAJ CQl0cC0+dGczX2ZsYWdzMiB8PSBURzNfRkxHMl9TRVJERVNfUFJFRU1QSEFTSVM7DQogCX0NCit9 DQorDQorc3RhdGljIGludCBfX2RldmluaXQgdGczX3BoeV9wcm9iZShzdHJ1Y3QgdGczICp0cCkN Cit7DQorCXUzMiBod19waHlfaWRfMSwgaHdfcGh5X2lkXzI7DQorCXUzMiBod19waHlfaWQsIGh3 X3BoeV9pZF9tYXNrZWQ7DQorCWludCBlcnI7DQogDQogCS8qIFJlYWRpbmcgdGhlIFBIWSBJRCBy ZWdpc3RlciBjYW4gY29uZmxpY3Qgd2l0aCBBU0YNCiAJICogZmlyd21hcmUgYWNjZXNzIHRvIHRo ZSBQSFkgaGFyZHdhcmUuDQpAQCAtNzY4MSwxMCArNzY5NiwxMCBAQA0KIAkJaWYgKGh3X3BoeV9p ZF9tYXNrZWQgPT0gUEhZX0lEX0JDTTgwMDIpDQogCQkJdHAtPnRnM19mbGFnczIgfD0gVEczX0ZM RzJfUEhZX1NFUkRFUzsNCiAJfSBlbHNlIHsNCi0JCWlmIChlZXByb21fc2lnbmF0dXJlX2ZvdW5k KSB7DQotCQkJdHAtPnBoeV9pZCA9IGVlcHJvbV9waHlfaWQ7DQotCQkJaWYgKGVlcHJvbV9waHlf c2VyZGVzKQ0KLQkJCQl0cC0+dGczX2ZsYWdzMiB8PSBURzNfRkxHMl9QSFlfU0VSREVTOw0KKwkJ aWYgKHRwLT5waHlfaWQgIT0gUEhZX0lEX0lOVkFMSUQpIHsNCisJCQkvKiBEbyBub3RoaW5nLCBw aHkgSUQgYWxyZWFkeSBzZXQgdXAgaW4NCisJCQkgKiB0ZzNfZ2V0X2VlcHJvbV9od19jZmcoKS4N CisJCQkgKi8NCiAJCX0gZWxzZSB7DQogCQkJc3RydWN0IHN1YnN5c190YmxfZW50ICpwOw0KIA0K QEAgLTc3NTUsOSArNzc3MCw2IEBADQogCQllcnIgPSB0ZzNfaW5pdF81NDAxcGh5X2RzcCh0cCk7 DQogCX0NCiANCi0JaWYgKCFlZXByb21fc2lnbmF0dXJlX2ZvdW5kKQ0KLQkJdHAtPmxlZF9jdHJs ID0gTEVEX0NUUkxfTU9ERV9QSFlfMTsNCi0NCiAJaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZM RzJfUEhZX1NFUkRFUykNCiAJCXRwLT5saW5rX2NvbmZpZy5hZHZlcnRpc2luZyA9DQogCQkJKEFE VkVSVElTRURfMTAwMGJhc2VUX0hhbGYgfA0KQEAgLTgwMjMsNiArODAzNSwxNiBAQA0KIAkJcGNp X3dyaXRlX2NvbmZpZ19kd29yZCh0cC0+cGRldiwgVEczUENJX1BDSVNUQVRFLCBwY2lfc3RhdGVf cmVnKTsNCiAJfQ0KIA0KKwkvKiBHZXQgZWVwcm9tIGh3IGNvbmZpZyBiZWZvcmUgY2FsbGluZyB0 ZzNfc2V0X3Bvd2VyX3N0YXRlKCkuDQorCSAqIEluIHBhcnRpY3VsYXIsIHRoZSBURzNfRkxBR19F RVBST01fV1JJVEVfUFJPVCBmbGFnIG11c3QgYmUNCisJICogZGV0ZXJtaW5lZCBiZWZvcmUgY2Fs bGluZyB0ZzNfc2V0X3Bvd2VyX3N0YXRlKCkgc28gdGhhdA0KKwkgKiB3ZSBrbm93IHdoZXRoZXIg b3Igbm90IHRvIHN3aXRjaCBvdXQgb2YgVmF1eCBwb3dlci4NCisJICogV2hlbiB0aGUgZmxhZyBp cyBzZXQsIGl0IG1lYW5zIHRoYXQgR1BJTzEgaXMgdXNlZCBmb3IgZWVwcm9tDQorCSAqIHdyaXRl IHByb3RlY3QgYW5kIGFsc28gaW1wbGllcyB0aGF0IGl0IGlzIGEgTE9NIHdoZXJlIEdQSU9zDQor CSAqIGFyZSBub3QgdXNlZCB0byBzd2l0Y2ggcG93ZXIuDQorCSAqLyANCisJdGczX2dldF9lZXBy b21faHdfY2ZnKHRwKTsNCisNCiAJLyogRm9yY2UgdGhlIGNoaXAgaW50byBEMC4gKi8NCiAJZXJy ID0gdGczX3NldF9wb3dlcl9zdGF0ZSh0cCwgMCk7DQogCWlmIChlcnIpIHsNCg== --=-J94+mrcKePHBGYnkIiLG-- From mchan@broadcom.com Mon Apr 18 01:25:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:25:56 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8Pq6h030980 for ; Mon, 18 Apr 2005 01:25:52 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:20:31 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:20:41 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ04596; Mon, 18 Apr 2005 01:20:40 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA13169; Mon, 18 Apr 2005 01:20:40 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:20:39 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:22:28 -0700 Subject: [PATCH 2.6.12-rc2 3/11] tg3: Setup proper GPIO settings From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> Date: Mon, 18 Apr 2005 00:22:28 -0700 Message-ID: <1113808948.6504.41.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DB246294384087-01-01 Content-Type: multipart/mixed; boundary="=-TunRTX3BRUlhImgA+Y50" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3713 Lines: 65 --=-TunRTX3BRUlhImgA+Y50 Content-Type: text/plain Content-Transfer-Encoding: 7bit Setup proper GPIO settings in tp->grc_local_ctrl before calling tg3_set_power() state in tg3_get_invariants() and after chip reset. Signed-off-by: Michael Chan --=-TunRTX3BRUlhImgA+Y50 Content-Disposition: attachment; filename=tg3-103.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-103.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwMi9kcml2ZXJzL25ldC90ZzMuYyAxMDMvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDIvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNDo0MDoxMC4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDMvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNTowMTozNy4wMDAwMDAw MDAgLTA3MDANCkBAIC01MzM2LDEwICs1MzM2LDIzIEBADQogCXR3MzJfZihNQUNfTU9ERSwgdHAt Pm1hY19tb2RlIHwgTUFDX01PREVfUlhTVEFUX0NMRUFSIHwgTUFDX01PREVfVFhTVEFUX0NMRUFS KTsNCiAJdWRlbGF5KDQwKTsNCiANCi0JdHAtPmdyY19sb2NhbF9jdHJsID0gR1JDX0xDTENUUkxf SU5UX09OX0FUVE4gfCBHUkNfTENMQ1RSTF9BVVRPX1NFRVBST007DQotCWlmIChHRVRfQVNJQ19S RVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwMCkNCisJLyogdHAtPmdyY19s b2NhbF9jdHJsIGlzIHBhcnRpYWxseSBzZXQgdXAgZHVyaW5nIHRnM19nZXRfaW52YXJpYW50cygp Lg0KKwkgKiBJZiBURzNfRkxBR19FRVBST01fV1JJVEVfUFJPVCBpcyBzZXQsIHdlIHNob3VsZCBy ZWFkIHRoZQ0KKwkgKiByZWdpc3RlciB0byBwcmVzZXJ2ZSB0aGUgR1BJTyBzZXR0aW5ncyBmb3Ig TE9Ncy4gVGhlIEdQSU9zLA0KKwkgKiB3aGV0aGVyIHVzZWQgYXMgaW5wdXRzIG9yIG91dHB1dHMs IGFyZSBzZXQgYnkgYm9vdCBjb2RlIGFmdGVyDQorCSAqIHJlc2V0Lg0KKwkgKi8NCisJaWYgKHRw LT50ZzNfZmxhZ3MgJiBURzNfRkxBR19FRVBST01fV1JJVEVfUFJPVCkgew0KKwkJdTMyIGdwaW9f bWFzazsNCisNCisJCWdwaW9fbWFzayA9IEdSQ19MQ0xDVFJMX0dQSU9fT0UwIHwgR1JDX0xDTENU UkxfR1BJT19PRTIgfA0KKwkJCSAgICBHUkNfTENMQ1RSTF9HUElPX09VVFBVVDAgfCBHUkNfTENM Q1RSTF9HUElPX09VVFBVVDI7DQorCQl0cC0+Z3JjX2xvY2FsX2N0cmwgfD0gdHIzMihHUkNfTE9D QUxfQ1RSTCkgJiBncGlvX21hc2s7DQorDQorCQkvKiBHUElPMSBtdXN0IGJlIGRyaXZlbiBoaWdo IGZvciBlZXByb20gd3JpdGUgcHJvdGVjdCAqLw0KIAkJdHAtPmdyY19sb2NhbF9jdHJsIHw9IChH UkNfTENMQ1RSTF9HUElPX09FMSB8DQogCQkJCSAgICAgICBHUkNfTENMQ1RSTF9HUElPX09VVFBV VDEpOw0KKwl9DQogCXR3MzJfZihHUkNfTE9DQUxfQ1RSTCwgdHAtPmdyY19sb2NhbF9jdHJsKTsN CiAJdWRlbGF5KDEwMCk7DQogDQpAQCAtNzQzMCw4ICs3NDQzLDggQEANCiAJfQ0KIA0KIAlpZiAo dHAtPnRnM19mbGFncyAmIFRHM19GTEFHX0VFUFJPTV9XUklURV9QUk9UKSB7DQotCQl0dzMyX2Yo R1JDX0xPQ0FMX0NUUkwsIHRwLT5ncmNfbG9jYWxfY3RybCB8DQotCQkgICAgICAgR1JDX0xDTENU UkxfR1BJT19PRTEpOw0KKwkJdHczMl9mKEdSQ19MT0NBTF9DVFJMLCB0cC0+Z3JjX2xvY2FsX2N0 cmwgJg0KKwkJICAgICAgIH5HUkNfTENMQ1RSTF9HUElPX09VVFBVVDEpOw0KIAkJdWRlbGF5KDQw KTsNCiAJfQ0KIA0KQEAgLTc0NzcsOCArNzQ5MCw3IEBADQogCX0NCiANCiAJaWYgKHRwLT50ZzNf ZmxhZ3MgJiBURzNfRkxBR19FRVBST01fV1JJVEVfUFJPVCkgew0KLQkJdHczMl9mKEdSQ19MT0NB TF9DVFJMLCB0cC0+Z3JjX2xvY2FsX2N0cmwgfA0KLQkJICAgICAgIEdSQ19MQ0xDVFJMX0dQSU9f T0UxIHwgR1JDX0xDTENUUkxfR1BJT19PVVRQVVQxKTsNCisJCXR3MzJfZihHUkNfTE9DQUxfQ1RS TCwgdHAtPmdyY19sb2NhbF9jdHJsKTsNCiAJCXVkZWxheSg0MCk7DQogCX0NCiANCkBAIC04MDQ1 LDYgKzgwNTcsMTYgQEANCiAJICovIA0KIAl0ZzNfZ2V0X2VlcHJvbV9od19jZmcodHApOw0KIA0K KwkvKiBTZXQgdXAgdHAtPmdyY19sb2NhbF9jdHJsIGJlZm9yZSBjYWxsaW5nIHRnM19zZXRfcG93 ZXJfc3RhdGUoKS4NCisJICogR1BJTzEgZHJpdmVuIGhpZ2ggd2lsbCBicmluZyA1NzAwJ3MgZXh0 ZXJuYWwgUEhZIG91dCBvZiByZXNldC4NCisJICogSXQgaXMgYWxzbyB1c2VkIGFzIGVlcHJvbSB3 cml0ZSBwcm90ZWN0IG9uIExPTXMuDQorCSAqLw0KKwl0cC0+Z3JjX2xvY2FsX2N0cmwgPSBHUkNf TENMQ1RSTF9JTlRfT05fQVRUTiB8IEdSQ19MQ0xDVFJMX0FVVE9fU0VFUFJPTTsNCisJaWYgKChH RVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwMCkgfHwNCisJ ICAgICh0cC0+dGczX2ZsYWdzICYgVEczX0ZMQUdfRUVQUk9NX1dSSVRFX1BST1QpKQ0KKwkJdHAt PmdyY19sb2NhbF9jdHJsIHw9IChHUkNfTENMQ1RSTF9HUElPX09FMSB8DQorCQkJCSAgICAgICBH UkNfTENMQ1RSTF9HUElPX09VVFBVVDEpOw0KKw0KIAkvKiBGb3JjZSB0aGUgY2hpcCBpbnRvIEQw LiAqLw0KIAllcnIgPSB0ZzNfc2V0X3Bvd2VyX3N0YXRlKHRwLCAwKTsNCiAJaWYgKGVycikgew0K --=-TunRTX3BRUlhImgA+Y50-- From mchan@broadcom.com Mon Apr 18 01:32:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:32:08 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8W3BR031639 for ; Mon, 18 Apr 2005 01:32:03 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:26:47 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:27:01 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ05457; Mon, 18 Apr 2005 01:26:56 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA13638; Mon, 18 Apr 2005 01:26:55 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:26:55 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:28:44 -0700 Subject: [PATCH 2.6.12-rc2 4/11] tg3: Fix tg3_set_power_state() From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> Date: Mon, 18 Apr 2005 00:28:44 -0700 Message-ID: <1113809324.6504.48.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DB0CD294385613-01-01 Content-Type: multipart/mixed; boundary="=-g0vpx+P/5OCrNfLGDNB3" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1683 Lines: 39 --=-g0vpx+P/5OCrNfLGDNB3 Content-Type: text/plain Content-Transfer-Encoding: 7bit Fix tg3_set_power_state to drive GPIOs properly based on the TG3_FLAG_EEPROM_WRITE_PROTECT flag. Some delays are also added after D0 and D3 power state changes. Signed-off-by: Michael Chan --=-g0vpx+P/5OCrNfLGDNB3 Content-Disposition: attachment; filename=tg3-104.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; charset=utf-8; name=tg3-104.patch ZGlmZiAtTnJ1IDEwMy9kcml2ZXJzL25ldC90ZzMuYyAxMDQvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDMvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNTowMTozNy4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDQvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNjozNjoyMy4wMDAwMDAw MDAgLTA3MDANCkBAIC0xMDA1LDggKzEwMDUsMTMgQEANCiAJCXBjaV93cml0ZV9jb25maWdfd29y ZCh0cC0+cGRldiwNCiAJCQkJICAgICAgcG0gKyBQQ0lfUE1fQ1RSTCwNCiAJCQkJICAgICAgcG93 ZXJfY29udHJvbCk7DQotCQl0dzMyX2YoR1JDX0xPQ0FMX0NUUkwsIHRwLT5ncmNfbG9jYWxfY3Ry bCk7DQotCQl1ZGVsYXkoMTAwKTsNCisJCXVkZWxheSgxMDApOwkvKiBEZWxheSBhZnRlciBwb3dl ciBzdGF0ZSBjaGFuZ2UgKi8NCisNCisJCS8qIFN3aXRjaCBvdXQgb2YgVmF1eCBpZiBpdCBpcyBu b3QgYSBMT00gKi8NCisJCWlmICghKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19FRVBST01fV1JJ VEVfUFJPVCkpIHsNCisJCQl0dzMyX2YoR1JDX0xPQ0FMX0NUUkwsIHRwLT5ncmNfbG9jYWxfY3Ry bCk7DQorCQkJdWRlbGF5KDEwMCk7DQorCQl9DQogDQogCQlyZXR1cm4gMDsNCiANCkBAIC0xMTUx LDYgKzExNTYsNyBAQA0KIA0KIAkvKiBGaW5hbGx5LCBzZXQgdGhlIG5ldyBwb3dlciBzdGF0ZS4g Ki8NCiAJcGNpX3dyaXRlX2NvbmZpZ193b3JkKHRwLT5wZGV2LCBwbSArIFBDSV9QTV9DVFJMLCBw b3dlcl9jb250cm9sKTsNCisJdWRlbGF5KDEwMCk7CS8qIERlbGF5IGFmdGVyIHBvd2VyIHN0YXRl IGNoYW5nZSAqLw0KIA0KIAl0ZzNfd3JpdGVfc2lnX3Bvc3RfcmVzZXQodHAsIFJFU0VUX0tJTkRf U0hVVERPV04pOw0KIA0K --=-g0vpx+P/5OCrNfLGDNB3-- From mchan@broadcom.com Mon Apr 18 01:36:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:36:25 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8aLMZ032233 for ; Mon, 18 Apr 2005 01:36:21 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:36:01 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:35:58 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ06604; Mon, 18 Apr 2005 01:35:56 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA14315; Mon, 18 Apr 2005 01:35:56 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:35:55 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:37:44 -0700 Subject: [PATCH 2.6.12-rc2 5/11] tg3: Workaround 5752 A0 chip ID From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> Date: Mon, 18 Apr 2005 00:37:44 -0700 Message-ID: <1113809864.6504.58.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DAEFB29G377889-01-01 Content-Type: multipart/mixed; boundary="=-+vDrFsv545GHGqHxTGAh" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 3264 Lines: 60 --=-+vDrFsv545GHGqHxTGAh Content-Type: text/plain Content-Transfer-Encoding: 7bit The 5752 A0 chip ID is wrong in hardware. The simplest way to workaround it is to change it to the correct value in tp->pci_chip_rev_id. This way, it is easier to check for the ASIC_REV_5752 in the rest of the driver. Signed-off-by: Michael Chan --=-+vDrFsv545GHGqHxTGAh Content-Disposition: attachment; filename=tg3-105.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-105.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwNC9kcml2ZXJzL25ldC90ZzMuYyAxMDUvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDQvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNjozNjoyMy4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDUvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNjo1Njo0My4wMDAwMDAw MDAgLTA3MDANCkBAIC03OTUyLDYgKzc5NTIsMTIgQEANCiAJdHAtPnBjaV9jaGlwX3Jldl9pZCA9 IChtaXNjX2N0cmxfcmVnID4+DQogCQkJICAgICAgIE1JU0NfSE9TVF9DVFJMX0NISVBSRVZfU0hJ RlQpOw0KIA0KKwkvKiBXcm9uZyBjaGlwIElEIGluIDU3NTIgQTAuIFRoaXMgY29kZSBjYW4gYmUg cmVtb3ZlZCBsYXRlcg0KKwkgKiBhcyBBMCBpcyBub3QgaW4gcHJvZHVjdGlvbi4NCisJICovDQor CWlmICh0cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTc1Ml9BMF9IVykNCisJCXRw LT5wY2lfY2hpcF9yZXZfaWQgPSBDSElQUkVWX0lEXzU3NTJfQTA7DQorDQogCS8qIEluaXRpYWxp emUgbWlzYyBob3N0IGNvbnRyb2wgaW4gUENJIGJsb2NrLiAqLw0KIAl0cC0+bWlzY19ob3N0X2N0 cmwgfD0gKG1pc2NfY3RybF9yZWcgJg0KIAkJCSAgICAgICBNSVNDX0hPU1RfQ1RSTF9DSElQUkVW KTsNCkBAIC03OTY3LDggKzc5NzMsNyBAQA0KIAl0cC0+cGNpX2Jpc3QgICAgICAgICA9IChjYWNo ZWxpbmVfc3pfcmVnID4+IDI0KSAmIDB4ZmY7DQogDQogCWlmIChHRVRfQVNJQ19SRVYodHAtPnBj aV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCB8fA0KLQkgICAgR0VUX0FTSUNfUkVWKHRw LT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTJfQTAgfHwNCi0JICAgIEdFVF9BU0lD X1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzUyX0ExKQ0KKwkgICAgR0VU X0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTIpDQogCQl0cC0+ dGczX2ZsYWdzMiB8PSBURzNfRkxHMl81NzUwX1BMVVM7DQogDQogCWlmICgoR0VUX0FTSUNfUkVW KHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUpIHx8DQpkaWZmIC1OcnUgMTA0 L2RyaXZlcnMvbmV0L3RnMy5oIDEwNS9kcml2ZXJzL25ldC90ZzMuaA0KLS0tIDEwNC9kcml2ZXJz L25ldC90ZzMuaAkyMDA1LTA0LTE1IDE2OjM2OjIzLjAwMDAwMDAwMCAtMDcwMA0KKysrIDEwNS9k cml2ZXJzL25ldC90ZzMuaAkyMDA1LTA0LTE1IDE2OjU4OjI1LjAwMDAwMDAwMCAtMDcwMA0KQEAg LTEyNSw3ICsxMjUsOCBAQA0KICNkZWZpbmUgIENISVBSRVZfSURfNTc1MF9BMAkJIDB4NDAwMA0K ICNkZWZpbmUgIENISVBSRVZfSURfNTc1MF9BMQkJIDB4NDAwMQ0KICNkZWZpbmUgIENISVBSRVZf SURfNTc1MF9BMwkJIDB4NDAwMw0KLSNkZWZpbmUgIENISVBSRVZfSURfNTc1Ml9BMAkJIDB4NTAw MA0KKyNkZWZpbmUgIENISVBSRVZfSURfNTc1Ml9BMF9IVwkJIDB4NTAwMA0KKyNkZWZpbmUgIENI SVBSRVZfSURfNTc1Ml9BMAkJIDB4NjAwMA0KICNkZWZpbmUgIENISVBSRVZfSURfNTc1Ml9BMQkJ IDB4NjAwMQ0KICNkZWZpbmUgIEdFVF9BU0lDX1JFVihDSElQX1JFVl9JRCkJKChDSElQX1JFVl9J RCkgPj4gMTIpDQogI2RlZmluZSAgIEFTSUNfUkVWXzU3MDAJCQkgMHgwNw0KQEAgLTEzNCw4ICsx MzUsNyBAQA0KICNkZWZpbmUgICBBU0lDX1JFVl81NzA0CQkJIDB4MDINCiAjZGVmaW5lICAgQVNJ Q19SRVZfNTcwNQkJCSAweDAzDQogI2RlZmluZSAgIEFTSUNfUkVWXzU3NTAJCQkgMHgwNA0KLSNk ZWZpbmUgICBBU0lDX1JFVl81NzUyX0EwCQkgMHgwNQ0KLSNkZWZpbmUgICBBU0lDX1JFVl81NzUy X0ExCQkgMHgwNg0KKyNkZWZpbmUgICBBU0lDX1JFVl81NzUyCQkJIDB4MDYNCiAjZGVmaW5lICBH RVRfQ0hJUF9SRVYoQ0hJUF9SRVZfSUQpCSgoQ0hJUF9SRVZfSUQpID4+IDgpDQogI2RlZmluZSAg IENISVBSRVZfNTcwMF9BWAkJIDB4NzANCiAjZGVmaW5lICAgQ0hJUFJFVl81NzAwX0JYCQkgMHg3 MQ0K --=-+vDrFsv545GHGqHxTGAh-- From mchan@broadcom.com Mon Apr 18 01:42:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:42:05 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8g1dP000782 for ; Mon, 18 Apr 2005 01:42:01 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:39:23 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:39:37 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ07113; Mon, 18 Apr 2005 01:39:35 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA14648; Mon, 18 Apr 2005 01:39:35 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:39:34 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:41:23 -0700 Subject: [PATCH 2.6.12-rc2 6/11] tg3: Add GPIO3 for 5752 From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> Date: Mon, 18 Apr 2005 00:41:23 -0700 Message-ID: <1113810083.6504.62.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DADB1294388062-01-01 Content-Type: multipart/mixed; boundary="=-FmzRzWQNZfrGltH83NuU" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2725 Lines: 52 --=-FmzRzWQNZfrGltH83NuU Content-Type: text/plain Content-Transfer-Encoding: 7bit Add bit definitions for the new GPIO3 in 5752. GPIO3 must be driven as output when it is unused. Signed-off-by: Michael Chan --=-FmzRzWQNZfrGltH83NuU Content-Disposition: attachment; filename=tg3-106.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-106.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwNS9kcml2ZXJzL25ldC90ZzMuYyAxMDYvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDUvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNjo1Njo0My4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDYvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzoxNToyOC4wMDAwMDAw MDAgLTA3MDANCkBAIC01MzUzLDYgKzUzNTMsMTEgQEANCiANCiAJCWdwaW9fbWFzayA9IEdSQ19M Q0xDVFJMX0dQSU9fT0UwIHwgR1JDX0xDTENUUkxfR1BJT19PRTIgfA0KIAkJCSAgICBHUkNfTENM Q1RSTF9HUElPX09VVFBVVDAgfCBHUkNfTENMQ1RSTF9HUElPX09VVFBVVDI7DQorDQorCQlpZiAo R0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTIpDQorCQkJ Z3Bpb19tYXNrIHw9IEdSQ19MQ0xDVFJMX0dQSU9fT0UzIHwNCisJCQkJICAgICBHUkNfTENMQ1RS TF9HUElPX09VVFBVVDM7DQorDQogCQl0cC0+Z3JjX2xvY2FsX2N0cmwgfD0gdHIzMihHUkNfTE9D QUxfQ1RSTCkgJiBncGlvX21hc2s7DQogDQogCQkvKiBHUElPMSBtdXN0IGJlIGRyaXZlbiBoaWdo IGZvciBlZXByb20gd3JpdGUgcHJvdGVjdCAqLw0KQEAgLTgwNzcsNiArODA4MiwxMSBAQA0KIAkg ICAgKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19FRVBST01fV1JJVEVfUFJPVCkpDQogCQl0cC0+ Z3JjX2xvY2FsX2N0cmwgfD0gKEdSQ19MQ0xDVFJMX0dQSU9fT0UxIHwNCiAJCQkJICAgICAgIEdS Q19MQ0xDVFJMX0dQSU9fT1VUUFVUMSk7DQorCS8qIFVudXNlZCBHUElPMyBtdXN0IGJlIGRyaXZl biBhcyBvdXRwdXQgb24gNTc1MiBiZWNhdXNlIHRoZXJlDQorCSAqIGFyZSBubyBwdWxsLXVwIHJl c2lzdG9ycyBvbiB1bnVzZWQgR1BJTyBwaW5zLg0KKwkgKi8NCisJZWxzZSBpZiAoR0VUX0FTSUNf UkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTIpDQorCQl0cC0+Z3JjX2xv Y2FsX2N0cmwgfD0gR1JDX0xDTENUUkxfR1BJT19PRTM7DQogDQogCS8qIEZvcmNlIHRoZSBjaGlw IGludG8gRDAuICovDQogCWVyciA9IHRnM19zZXRfcG93ZXJfc3RhdGUodHAsIDApOw0KZGlmZiAt TnJ1IDEwNS9kcml2ZXJzL25ldC90ZzMuaCAxMDYvZHJpdmVycy9uZXQvdGczLmgNCi0tLSAxMDUv ZHJpdmVycy9uZXQvdGczLmgJMjAwNS0wNC0xNSAxNjo1ODoyNS4wMDAwMDAwMDAgLTA3MDANCisr KyAxMDYvZHJpdmVycy9uZXQvdGczLmgJMjAwNS0wNC0xNSAxNzoxNToyOC4wMDAwMDAwMDAgLTA3 MDANCkBAIC0xMzExLDYgKzEzMTEsOSBAQA0KICNkZWZpbmUgIEdSQ19MQ0xDVFJMX0NMRUFSSU5U CQkweDAwMDAwMDAyDQogI2RlZmluZSAgR1JDX0xDTENUUkxfU0VUSU5UCQkweDAwMDAwMDA0DQog I2RlZmluZSAgR1JDX0xDTENUUkxfSU5UX09OX0FUVE4JMHgwMDAwMDAwOA0KKyNkZWZpbmUgIEdS Q19MQ0xDVFJMX0dQSU9fSU5QVVQzCTB4MDAwMDAwMjANCisjZGVmaW5lICBHUkNfTENMQ1RSTF9H UElPX09FMwkJMHgwMDAwMDA0MA0KKyNkZWZpbmUgIEdSQ19MQ0xDVFJMX0dQSU9fT1VUUFVUMwkw eDAwMDAwMDgwDQogI2RlZmluZSAgR1JDX0xDTENUUkxfR1BJT19JTlBVVDAJMHgwMDAwMDEwMA0K ICNkZWZpbmUgIEdSQ19MQ0xDVFJMX0dQSU9fSU5QVVQxCTB4MDAwMDAyMDANCiAjZGVmaW5lICBH UkNfTENMQ1RSTF9HUElPX0lOUFVUMgkweDAwMDAwNDAwDQo= --=-FmzRzWQNZfrGltH83NuU-- From mchan@broadcom.com Mon Apr 18 01:46:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:46:18 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8kESv001475 for ; Mon, 18 Apr 2005 01:46:14 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:46:15 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:45:32 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ07925; Mon, 18 Apr 2005 01:45:31 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA15183; Mon, 18 Apr 2005 01:45:30 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:45:30 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:47:19 -0700 Subject: [PATCH 2.6.12-rc2 7/11] tg3: Add nvram detection for 5752 From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113809864.6504.58.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113809864.6504.58.camel@rh4> Date: Mon, 18 Apr 2005 00:47:19 -0700 Message-ID: <1113810439.6504.66.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DAC5D1OC378017-01-01 Content-Type: multipart/mixed; boundary="=-mPcJVK/xeMVpMCNSJb53" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 4975 Lines: 81 --=-mPcJVK/xeMVpMCNSJb53 Content-Type: text/plain Content-Transfer-Encoding: 7bit Signed-off-by: Michael Chan --=-mPcJVK/xeMVpMCNSJb53 Content-Disposition: attachment; filename=tg3-107.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-107.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwNi9kcml2ZXJzL25ldC90ZzMuYyAxMDcvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDYvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzoxNToyOC4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDcvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzozMzo1NS4wMDAwMDAw MDAgLTA3MDANCkBAIC03MDk2LDYgKzcwOTYsNjMgQEANCiAJfQ0KIH0NCiANCitzdGF0aWMgdm9p ZCBfX2RldmluaXQgdGczX2dldF81NzUyX252cmFtX2luZm8oc3RydWN0IHRnMyAqdHApDQorew0K Kwl1MzIgbnZjZmcxOw0KKw0KKwludmNmZzEgPSB0cjMyKE5WUkFNX0NGRzEpOw0KKw0KKwlzd2l0 Y2ggKG52Y2ZnMSAmIE5WUkFNX0NGRzFfNTc1MlZFTkRPUl9NQVNLKSB7DQorCQljYXNlIEZMQVNI XzU3NTJWRU5ET1JfQVRNRUxfRUVQUk9NXzY0S0haOg0KKwkJY2FzZSBGTEFTSF81NzUyVkVORE9S X0FUTUVMX0VFUFJPTV8zNzZLSFo6DQorCQkJdHAtPm52cmFtX2plZGVjbnVtID0gSkVERUNfQVRN RUw7DQorCQkJdHAtPnRnM19mbGFncyB8PSBURzNfRkxBR19OVlJBTV9CVUZGRVJFRDsNCisJCQli cmVhazsNCisJCWNhc2UgRkxBU0hfNTc1MlZFTkRPUl9BVE1FTF9GTEFTSF9CVUZGRVJFRDoNCisJ CQl0cC0+bnZyYW1famVkZWNudW0gPSBKRURFQ19BVE1FTDsNCisJCQl0cC0+dGczX2ZsYWdzIHw9 IFRHM19GTEFHX05WUkFNX0JVRkZFUkVEOw0KKwkJCXRwLT50ZzNfZmxhZ3MyIHw9IFRHM19GTEcy X0ZMQVNIOw0KKwkJCWJyZWFrOw0KKwkJY2FzZSBGTEFTSF81NzUyVkVORE9SX1NUX000NVBFMTA6 DQorCQljYXNlIEZMQVNIXzU3NTJWRU5ET1JfU1RfTTQ1UEUyMDoNCisJCWNhc2UgRkxBU0hfNTc1 MlZFTkRPUl9TVF9NNDVQRTQwOg0KKwkJCXRwLT5udnJhbV9qZWRlY251bSA9IEpFREVDX1NUOw0K KwkJCXRwLT50ZzNfZmxhZ3MgfD0gVEczX0ZMQUdfTlZSQU1fQlVGRkVSRUQ7DQorCQkJdHAtPnRn M19mbGFnczIgfD0gVEczX0ZMRzJfRkxBU0g7DQorCQkJYnJlYWs7DQorCX0NCisNCisJaWYgKHRw LT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfRkxBU0gpIHsNCisJCXN3aXRjaCAobnZjZmcxICYgTlZS QU1fQ0ZHMV81NzUyUEFHRV9TSVpFX01BU0spIHsNCisJCQljYXNlIEZMQVNIXzU3NTJQQUdFX1NJ WkVfMjU2Og0KKwkJCQl0cC0+bnZyYW1fcGFnZXNpemUgPSAyNTY7DQorCQkJCWJyZWFrOw0KKwkJ CWNhc2UgRkxBU0hfNTc1MlBBR0VfU0laRV81MTI6DQorCQkJCXRwLT5udnJhbV9wYWdlc2l6ZSA9 IDUxMjsNCisJCQkJYnJlYWs7DQorCQkJY2FzZSBGTEFTSF81NzUyUEFHRV9TSVpFXzFLOg0KKwkJ CQl0cC0+bnZyYW1fcGFnZXNpemUgPSAxMDI0Ow0KKwkJCQlicmVhazsNCisJCQljYXNlIEZMQVNI XzU3NTJQQUdFX1NJWkVfMks6DQorCQkJCXRwLT5udnJhbV9wYWdlc2l6ZSA9IDIwNDg7DQorCQkJ CWJyZWFrOw0KKwkJCWNhc2UgRkxBU0hfNTc1MlBBR0VfU0laRV80SzoNCisJCQkJdHAtPm52cmFt X3BhZ2VzaXplID0gNDA5NjsNCisJCQkJYnJlYWs7DQorCQkJY2FzZSBGTEFTSF81NzUyUEFHRV9T SVpFXzI2NDoNCisJCQkJdHAtPm52cmFtX3BhZ2VzaXplID0gMjY0Ow0KKwkJCQlicmVhazsNCisJ CX0NCisJfQ0KKwllbHNlIHsNCisJCS8qIEZvciBlZXByb20sIHNldCBwYWdlc2l6ZSB0byBtYXhp bXVtIGVlcHJvbSBzaXplICovDQorCQl0cC0+bnZyYW1fcGFnZXNpemUgPSBBVE1FTF9BVDI0QzUx Ml9DSElQX1NJWkU7DQorDQorCQludmNmZzEgJj0gfk5WUkFNX0NGRzFfQ09NUEFUX0JZUEFTUzsN CisJCXR3MzIoTlZSQU1fQ0ZHMSwgbnZjZmcxKTsNCisJfQ0KK30NCisNCiAvKiBDaGlwcyBvdGhl ciB0aGFuIDU3MDAvNTcwMSB1c2UgdGhlIE5WUkFNIGZvciBmZXRjaGluZyBpbmZvLiAqLw0KIHN0 YXRpYyB2b2lkIF9fZGV2aW5pdCB0ZzNfbnZyYW1faW5pdChzdHJ1Y3QgdGczICp0cCkNCiB7DQpA QCAtNzEyOCw3ICs3MTg1LDExIEBADQogCQkJdHczMihOVlJBTV9BQ0NFU1MsIG52YWNjZXNzIHwg QUNDRVNTX0VOQUJMRSk7DQogCQl9DQogDQotCQl0ZzNfZ2V0X252cmFtX2luZm8odHApOw0KKwkJ aWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzUyKQ0K KwkJCXRnM19nZXRfNTc1Ml9udnJhbV9pbmZvKHRwKTsNCisJCWVsc2UNCisJCQl0ZzNfZ2V0X252 cmFtX2luZm8odHApOw0KKw0KIAkJdGczX2dldF9udnJhbV9zaXplKHRwKTsNCiANCiAJCWlmICh0 cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3NTBfUExVUykgew0KZGlmZiAtTnJ1IDEwNi9kcml2 ZXJzL25ldC90ZzMuaCAxMDcvZHJpdmVycy9uZXQvdGczLmgNCi0tLSAxMDYvZHJpdmVycy9uZXQv dGczLmgJMjAwNS0wNC0xNSAxNzoxNToyOC4wMDAwMDAwMDAgLTA3MDANCisrKyAxMDcvZHJpdmVy cy9uZXQvdGczLmgJMjAwNS0wNC0xNSAxNzozMzo1NS4wMDAwMDAwMDAgLTA3MDANCkBAIC0xMzk5 LDYgKzEzOTksMjAgQEANCiAjZGVmaW5lICBGTEFTSF9WRU5ET1JfU0FJRlVOCQkgMHgwMTAwMDAw Mw0KICNkZWZpbmUgIEZMQVNIX1ZFTkRPUl9TU1RfU01BTEwJCSAweDAwMDAwMDAxDQogI2RlZmlu ZSAgRkxBU0hfVkVORE9SX1NTVF9MQVJHRQkJIDB4MDIwMDAwMDENCisjZGVmaW5lICBOVlJBTV9D RkcxXzU3NTJWRU5ET1JfTUFTSwkgMHgwM2MwMDAwMw0KKyNkZWZpbmUgIEZMQVNIXzU3NTJWRU5E T1JfQVRNRUxfRUVQUk9NXzY0S0haCSAweDAwMDAwMDAwDQorI2RlZmluZSAgRkxBU0hfNTc1MlZF TkRPUl9BVE1FTF9FRVBST01fMzc2S0haCSAweDAyMDAwMDAwDQorI2RlZmluZSAgRkxBU0hfNTc1 MlZFTkRPUl9BVE1FTF9GTEFTSF9CVUZGRVJFRAkgMHgwMjAwMDAwMw0KKyNkZWZpbmUgIEZMQVNI XzU3NTJWRU5ET1JfU1RfTTQ1UEUxMAkgMHgwMjQwMDAwMA0KKyNkZWZpbmUgIEZMQVNIXzU3NTJW RU5ET1JfU1RfTTQ1UEUyMAkgMHgwMjQwMDAwMg0KKyNkZWZpbmUgIEZMQVNIXzU3NTJWRU5ET1Jf U1RfTTQ1UEU0MAkgMHgwMjQwMDAwMQ0KKyNkZWZpbmUgIE5WUkFNX0NGRzFfNTc1MlBBR0VfU0la RV9NQVNLCSAweDcwMDAwMDAwDQorI2RlZmluZSAgRkxBU0hfNTc1MlBBR0VfU0laRV8yNTYJIDB4 MDAwMDAwMDANCisjZGVmaW5lICBGTEFTSF81NzUyUEFHRV9TSVpFXzUxMgkgMHgxMDAwMDAwMA0K KyNkZWZpbmUgIEZMQVNIXzU3NTJQQUdFX1NJWkVfMUsJCSAweDIwMDAwMDAwDQorI2RlZmluZSAg RkxBU0hfNTc1MlBBR0VfU0laRV8ySwkJIDB4MzAwMDAwMDANCisjZGVmaW5lICBGTEFTSF81NzUy UEFHRV9TSVpFXzRLCQkgMHg0MDAwMDAwMA0KKyNkZWZpbmUgIEZMQVNIXzU3NTJQQUdFX1NJWkVf MjY0CSAweDUwMDAwMDAwDQogI2RlZmluZSBOVlJBTV9DRkcyCQkJMHgwMDAwNzAxOA0KICNkZWZp bmUgTlZSQU1fQ0ZHMwkJCTB4MDAwMDcwMWMNCiAjZGVmaW5lIE5WUkFNX1NXQVJCCQkJMHgwMDAw NzAyMA0K --=-mPcJVK/xeMVpMCNSJb53-- From mchan@broadcom.com Mon Apr 18 01:52:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:52:56 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8qmFH002155 for ; Mon, 18 Apr 2005 01:52:50 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:53:14 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:52:29 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ08892; Mon, 18 Apr 2005 01:52:28 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA15696; Mon, 18 Apr 2005 01:52:28 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:52:27 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:54:16 -0700 Subject: [PATCH 2.6.12-rc2 8/11] tg3: Add nvram lock-out support for 5752 TPM From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113809864.6504.58.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113809864.6504.58.camel@rh4> Date: Mon, 18 Apr 2005 00:54:16 -0700 Message-ID: <1113810856.6504.73.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DAAF01OC379333-01-01 Content-Type: multipart/mixed; boundary="=-NpTmrV8XTLX5PeLtaae+" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 6195 Lines: 97 --=-NpTmrV8XTLX5PeLtaae+ Content-Type: text/plain Content-Transfer-Encoding: 7bit Add support for the NVRAM lock-out feature for TPM in 5752. If lock-out is enabled, certain NVRAM registers cannot be written to. Signed-off-by: Michael Chan --=-NpTmrV8XTLX5PeLtaae+ Content-Disposition: attachment; filename=tg3-108.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; charset=utf-8; name=tg3-108.patch ZGlmZiAtTnJ1IDEwNy9kcml2ZXJzL25ldC90ZzMuYyAxMDgvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDcvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzozMzo1NS4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDgvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzo0ODoyMy4wMDAwMDAw MDAgLTA3MDANCkBAIC0zNzMyLDYgKzM3MzIsMjggQEANCiB9DQogDQogLyogdHAtPmxvY2sgaXMg aGVsZC4gKi8NCitzdGF0aWMgdm9pZCB0ZzNfZW5hYmxlX252cmFtX2FjY2VzcyhzdHJ1Y3QgdGcz ICp0cCkNCit7DQorCWlmICgodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzUwX1BMVVMpICYm DQorCSAgICAhKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfUFJPVEVDVEVEX05WUkFNKSkgew0K KwkJdTMyIG52YWNjZXNzID0gdHIzMihOVlJBTV9BQ0NFU1MpOw0KKw0KKwkJdHczMihOVlJBTV9B Q0NFU1MsIG52YWNjZXNzIHwgQUNDRVNTX0VOQUJMRSk7DQorCX0NCit9DQorDQorLyogdHAtPmxv Y2sgaXMgaGVsZC4gKi8NCitzdGF0aWMgdm9pZCB0ZzNfZGlzYWJsZV9udnJhbV9hY2Nlc3Moc3Ry dWN0IHRnMyAqdHApDQorew0KKwlpZiAoKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTc1MF9Q TFVTKSAmJg0KKwkgICAgISh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1BST1RFQ1RFRF9OVlJB TSkpIHsNCisJCXUzMiBudmFjY2VzcyA9IHRyMzIoTlZSQU1fQUNDRVNTKTsNCisNCisJCXR3MzIo TlZSQU1fQUNDRVNTLCBudmFjY2VzcyAmIH5BQ0NFU1NfRU5BQkxFKTsNCisJfQ0KK30NCisNCisv KiB0cC0+bG9jayBpcyBoZWxkLiAqLw0KIHN0YXRpYyB2b2lkIHRnM193cml0ZV9zaWdfcHJlX3Jl c2V0KHN0cnVjdCB0ZzMgKnRwLCBpbnQga2luZCkNCiB7DQogCWlmICghKHRwLT50ZzNfZmxhZ3My ICYgVEczX0ZMRzJfU1VOXzU3MFgpKQ0KQEAgLTcxMDIsNiArNzEyNCwxMCBAQA0KIA0KIAludmNm ZzEgPSB0cjMyKE5WUkFNX0NGRzEpOw0KIA0KKwkvKiBOVlJBTSBwcm90ZWN0aW9uIGZvciBUUE0g Ki8NCisJaWYgKG52Y2ZnMSAmICgxIDw8IDI3KSkNCisJCXRwLT50ZzNfZmxhZ3MyIHw9IFRHM19G TEcyX1BST1RFQ1RFRF9OVlJBTTsNCisNCiAJc3dpdGNoIChudmNmZzEgJiBOVlJBTV9DRkcxXzU3 NTJWRU5ET1JfTUFTSykgew0KIAkJY2FzZSBGTEFTSF81NzUyVkVORE9SX0FUTUVMX0VFUFJPTV82 NEtIWjoNCiAJCWNhc2UgRkxBU0hfNTc1MlZFTkRPUl9BVE1FTF9FRVBST01fMzc2S0haOg0KQEAg LTcxNzksMTEgKzcyMDUsNyBAQA0KIAkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZf aWQpICE9IEFTSUNfUkVWXzU3MDEpIHsNCiAJCXRwLT50ZzNfZmxhZ3MgfD0gVEczX0ZMQUdfTlZS QU07DQogDQotCQlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzUwX1BMVVMpIHsNCi0J CQl1MzIgbnZhY2Nlc3MgPSB0cjMyKE5WUkFNX0FDQ0VTUyk7DQotDQotCQkJdHczMihOVlJBTV9B Q0NFU1MsIG52YWNjZXNzIHwgQUNDRVNTX0VOQUJMRSk7DQotCQl9DQorCQl0ZzNfZW5hYmxlX252 cmFtX2FjY2Vzcyh0cCk7DQogDQogCQlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZf aWQpID09IEFTSUNfUkVWXzU3NTIpDQogCQkJdGczX2dldF81NzUyX252cmFtX2luZm8odHApOw0K QEAgLTcxOTIsMTEgKzcyMTQsNyBAQA0KIA0KIAkJdGczX2dldF9udnJhbV9zaXplKHRwKTsNCiAN Ci0JCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3NTBfUExVUykgew0KLQkJCXUzMiBu dmFjY2VzcyA9IHRyMzIoTlZSQU1fQUNDRVNTKTsNCi0NCi0JCQl0dzMyKE5WUkFNX0FDQ0VTUywg bnZhY2Nlc3MgJiB+QUNDRVNTX0VOQUJMRSk7DQotCQl9DQorCQl0ZzNfZGlzYWJsZV9udnJhbV9h Y2Nlc3ModHApOw0KIA0KIAl9IGVsc2Ugew0KIAkJdHAtPnRnM19mbGFncyAmPSB+KFRHM19GTEFH X05WUkFNIHwgVEczX0ZMQUdfTlZSQU1fQlVGRkVSRUQpOw0KQEAgLTcyODUsMTEgKzczMDMsNyBA QA0KIA0KIAl0ZzNfbnZyYW1fbG9jayh0cCk7DQogDQotCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRH M19GTEcyXzU3NTBfUExVUykgew0KLQkJdTMyIG52YWNjZXNzID0gdHIzMihOVlJBTV9BQ0NFU1Mp Ow0KLQ0KLQkJdHczMl9mKE5WUkFNX0FDQ0VTUywgbnZhY2Nlc3MgfCBBQ0NFU1NfRU5BQkxFKTsN Ci0JfQ0KKwl0ZzNfZW5hYmxlX252cmFtX2FjY2Vzcyh0cCk7DQogDQogCXR3MzIoTlZSQU1fQURE Uiwgb2Zmc2V0KTsNCiAJcmV0ID0gdGczX252cmFtX2V4ZWNfY21kKHRwLCBOVlJBTV9DTURfUkQg fCBOVlJBTV9DTURfR08gfA0KQEAgLTczMDAsMTEgKzczMTQsNyBAQA0KIA0KIAl0ZzNfbnZyYW1f dW5sb2NrKHRwKTsNCiANCi0JaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTc1MF9QTFVT KSB7DQotCQl1MzIgbnZhY2Nlc3MgPSB0cjMyKE5WUkFNX0FDQ0VTUyk7DQotDQotCQl0dzMyX2Yo TlZSQU1fQUNDRVNTLCBudmFjY2VzcyAmIH5BQ0NFU1NfRU5BQkxFKTsNCi0JfQ0KKwl0ZzNfZGlz YWJsZV9udnJhbV9hY2Nlc3ModHApOw0KIA0KIAlyZXR1cm4gcmV0Ow0KIH0NCkBAIC03MzY3LDcg KzczNzcsNyBAQA0KIA0KIAl3aGlsZSAobGVuKSB7DQogCQlpbnQgajsNCi0JCXUzMiBwaHlfYWRk ciwgcGFnZV9vZmYsIHNpemUsIG52YWNjZXNzOw0KKwkJdTMyIHBoeV9hZGRyLCBwYWdlX29mZiwg c2l6ZTsNCiANCiAJCXBoeV9hZGRyID0gb2Zmc2V0ICYgfnBhZ2VtYXNrOw0KIAkNCkBAIC03Mzkw LDggKzc0MDAsNyBAQA0KIA0KIAkJb2Zmc2V0ID0gb2Zmc2V0ICsgKHBhZ2VzaXplIC0gcGFnZV9v ZmYpOw0KIA0KLQkJbnZhY2Nlc3MgPSB0cjMyKE5WUkFNX0FDQ0VTUyk7DQotCQl0dzMyX2YoTlZS QU1fQUNDRVNTLCBudmFjY2VzcyB8IEFDQ0VTU19FTkFCTEUpOw0KKwkJdGczX2VuYWJsZV9udnJh bV9hY2Nlc3ModHApOw0KIA0KIAkJLyoNCiAJCSAqIEJlZm9yZSB3ZSBjYW4gZXJhc2UgdGhlIGZs YXNoIHBhZ2UsIHdlIG5lZWQNCkBAIC03NTI4LDEzICs3NTM3LDEwIEBADQogDQogCQl0ZzNfbnZy YW1fbG9jayh0cCk7DQogDQotCQlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzUwX1BM VVMpIHsNCi0JCQl1MzIgbnZhY2Nlc3MgPSB0cjMyKE5WUkFNX0FDQ0VTUyk7DQotDQotCQkJdHcz MihOVlJBTV9BQ0NFU1MsIG52YWNjZXNzIHwgQUNDRVNTX0VOQUJMRSk7DQotDQorCQl0ZzNfZW5h YmxlX252cmFtX2FjY2Vzcyh0cCk7DQorCQlpZiAoKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJf NTc1MF9QTFVTKSAmJg0KKwkJICAgICEodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9QUk9URUNU RURfTlZSQU0pKQ0KIAkJCXR3MzIoTlZSQU1fV1JJVEUxLCAweDQwNik7DQotCQl9DQogDQogCQln cmNfbW9kZSA9IHRyMzIoR1JDX01PREUpOw0KIAkJdHczMihHUkNfTU9ERSwgZ3JjX21vZGUgfCBH UkNfTU9ERV9OVlJBTV9XUl9FTkFCTEUpOw0KQEAgLTc1NTMsMTEgKzc1NTksNyBAQA0KIAkJZ3Jj X21vZGUgPSB0cjMyKEdSQ19NT0RFKTsNCiAJCXR3MzIoR1JDX01PREUsIGdyY19tb2RlICYgfkdS Q19NT0RFX05WUkFNX1dSX0VOQUJMRSk7DQogDQotCQlpZiAodHAtPnRnM19mbGFnczIgJiBURzNf RkxHMl81NzUwX1BMVVMpIHsNCi0JCQl1MzIgbnZhY2Nlc3MgPSB0cjMyKE5WUkFNX0FDQ0VTUyk7 DQotDQotCQkJdHczMihOVlJBTV9BQ0NFU1MsIG52YWNjZXNzICYgfkFDQ0VTU19FTkFCTEUpOw0K LQkJfQ0KKwkJdGczX2Rpc2FibGVfbnZyYW1fYWNjZXNzKHRwKTsNCiAJCXRnM19udnJhbV91bmxv Y2sodHApOw0KIAl9DQogDQpkaWZmIC1OcnUgMTA3L2RyaXZlcnMvbmV0L3RnMy5oIDEwOC9kcml2 ZXJzL25ldC90ZzMuaA0KLS0tIDEwNy9kcml2ZXJzL25ldC90ZzMuaAkyMDA1LTA0LTE1IDE3OjMz OjU1LjAwMDAwMDAwMCAtMDcwMA0KKysrIDEwOC9kcml2ZXJzL25ldC90ZzMuaAkyMDA1LTA0LTE1 IDE3OjQ4OjIzLjAwMDAwMDAwMCAtMDcwMA0KQEAgLTIxMjIsNiArMjEyMiw3IEBADQogI2RlZmlu ZSBURzNfRkxHMl9TRVJERVNfUFJFRU1QSEFTSVMJMHgwMDAyMDAwMA0KICNkZWZpbmUgVEczX0ZM RzJfNTcwNV9QTFVTCQkweDAwMDQwMDAwDQogI2RlZmluZSBURzNfRkxHMl81NzUwX1BMVVMJCTB4 MDAwODAwMDANCisjZGVmaW5lIFRHM19GTEcyX1BST1RFQ1RFRF9OVlJBTQkweDAwMTAwMDAwDQog DQogCXUzMgkJCQlzcGxpdF9tb2RlX21heF9yZXFzOw0KICNkZWZpbmUgU1BMSVRfTU9ERV81NzA0 X01BWF9SRVEJCTMNCg== --=-NpTmrV8XTLX5PeLtaae+-- From mchan@broadcom.com Mon Apr 18 01:55:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:56:00 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8tuTE002774 for ; Mon, 18 Apr 2005 01:55:56 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:55:43 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:55:40 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ09326; Mon, 18 Apr 2005 01:55:39 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA16059; Mon, 18 Apr 2005 01:55:39 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:55:38 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:57:27 -0700 Subject: [PATCH 2.6.12-rc2 9/11] tg3: Fix bug in tg3_set_eeprom() From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113809864.6504.58.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113809864.6504.58.camel@rh4> Date: Mon, 18 Apr 2005 00:57:27 -0700 Message-ID: <1113811047.6504.78.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DA98529G381666-01-01 Content-Type: multipart/mixed; boundary="=-34ThBbzcnc+C1bparKbC" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 31 --=-34ThBbzcnc+C1bparKbC Content-Type: text/plain Content-Transfer-Encoding: 7bit Fix a bug in tg3_set_eeprom() when the length is less than 4 and the offset is not 4-byte aligned. Signed-off-by: Michael Chan --=-34ThBbzcnc+C1bparKbC Content-Disposition: attachment; filename=tg3-109.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-109.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDEwOC9kcml2ZXJzL25ldC90ZzMuYyAxMDkvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDgvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAxNzo0ODoyMy4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMDkvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAyMToyNjowMi4wMDAwMDAw MDAgLTA3MDANCkBAIC02NTYwLDEwICs2NTYwLDEyIEBADQogCQlzdGFydCA9IGNwdV90b19sZTMy KHN0YXJ0KTsNCiAJCWxlbiArPSBiX29mZnNldDsNCiAJCW9mZnNldCAmPSB+MzsNCisJCWlmIChs ZW4gPCA0KQ0KKwkJCWxlbiA9IDQ7DQogCX0NCiANCiAJb2RkX2xlbiA9IDA7DQotCWlmICgobGVu ICYgMykgJiYgKChsZW4gPiA0KSB8fCAoYl9vZmZzZXQgPT0gMCkpKSB7DQorCWlmIChsZW4gJiAz KSB7DQogCQkvKiBhZGp1c3RtZW50cyB0byBlbmQgb24gcmVxdWlyZWQgNCBieXRlIGJvdW5kYXJ5 ICovDQogCQlvZGRfbGVuID0gMTsNCiAJCWxlbiA9IChsZW4gKyAzKSAmIH4zOw0K --=-34ThBbzcnc+C1bparKbC-- From mchan@broadcom.com Mon Apr 18 01:59:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 01:59:57 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8xqti003388 for ; Mon, 18 Apr 2005 01:59:53 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 01:57:26 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 01:57:44 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ09536; Mon, 18 Apr 2005 01:57:41 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id BAA16252; Mon, 18 Apr 2005 01:57:41 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 08:57:40 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 00:59:29 -0700 Subject: [PATCH 2.6.12-rc2 10/11] tg3: Add msi support From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113809864.6504.58.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113809864.6504.58.camel@rh4> Date: Mon, 18 Apr 2005 00:59:29 -0700 Message-ID: <1113811169.6504.80.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DA9FC294391931-01-01 Content-Type: multipart/mixed; boundary="=-+OwyLnYapssM1hx625M6" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 5568 Lines: 89 --=-+OwyLnYapssM1hx625M6 Content-Type: text/plain Content-Transfer-Encoding: 7bit Add MSI support for 5751 C0 and 5752. Signed-off-by: Michael Chan --=-+OwyLnYapssM1hx625M6 Content-Disposition: attachment; filename=tg3-110.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; charset=utf-8; name=tg3-110.patch ZGlmZiAtTnJ1IDEwOS9kcml2ZXJzL25ldC90ZzMuYyAxMTAvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMDkvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAyMToyNjowMi4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMTAvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAyMToyNzoxNy4wMDAwMDAw MDAgLTA3MDANCkBAIC0yOTA3LDYgKzI5MDcsNDMgQEANCiAJcmV0dXJuIHdvcmtfZXhpc3RzOw0K IH0NCiANCisvKiBNU0kgSVNSIC0gTm8gbmVlZCB0byBjaGVjayBmb3IgaW50ZXJydXB0IHNoYXJp bmcgYW5kIG5vIG5lZWQgdG8NCisgKiBmbHVzaCBzdGF0dXMgYmxvY2sgYW5kIGludGVycnVwdCBt YWlsYm94LiBQQ0kgb3JkZXJpbmcgcnVsZXMNCisgKiBndWFyYW50ZWUgdGhhdCBNU0kgd2lsbCBh cnJpdmUgYWZ0ZXIgdGhlIHN0YXR1cyBibG9jay4NCisgKi8NCitzdGF0aWMgaXJxcmV0dXJuX3Qg dGczX21zaShpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzKQ0KK3sN CisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IGRldl9pZDsNCisJc3RydWN0IHRnMyAqdHAgPSBu ZXRkZXZfcHJpdihkZXYpOw0KKwlzdHJ1Y3QgdGczX2h3X3N0YXR1cyAqc2JsayA9IHRwLT5od19z dGF0dXM7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQorDQorCXNwaW5fbG9ja19pcnFzYXZlKCZ0 cC0+bG9jaywgZmxhZ3MpOw0KKw0KKwkvKg0KKwkgKiB3cml0aW5nIGFueSB2YWx1ZSB0byBpbnRy LW1ib3gtMCBjbGVhcnMgUENJIElOVEEjIGFuZA0KKwkgKiBjaGlwLWludGVybmFsIGludGVycnVw dCBwZW5kaW5nIGV2ZW50cy4NCisJICogd3JpdGluZyBub24temVybyB0byBpbnRyLW1ib3gtMCBh ZGRpdGlvbmFsIHRlbGxzIHRoZQ0KKwkgKiBOSUMgdG8gc3RvcCBzZW5kaW5nIHVzIGlycXMsIGVu Z2FnaW5nICJpbi1pbnRyLWhhbmRsZXIiDQorCSAqIGV2ZW50IGNvYWxlc2NpbmcuDQorCSAqLw0K Kwl0dzMyX21haWxib3goTUFJTEJPWF9JTlRFUlJVUFRfMCArIFRHM182NEJJVF9SRUdfTE9XLCAw eDAwMDAwMDAxKTsNCisJc2Jsay0+c3RhdHVzICY9IH5TRF9TVEFUVVNfVVBEQVRFRDsNCisNCisJ aWYgKGxpa2VseSh0ZzNfaGFzX3dvcmsoZGV2LCB0cCkpKQ0KKwkJbmV0aWZfcnhfc2NoZWR1bGUo ZGV2KTsJCS8qIHNjaGVkdWxlIE5BUEkgcG9sbCAqLw0KKwllbHNlIHsNCisJCS8qIG5vIHdvcmss IHJlLWVuYWJsZSBpbnRlcnJ1cHRzDQorCQkgKi8NCisJCXR3MzJfbWFpbGJveChNQUlMQk9YX0lO VEVSUlVQVF8wICsgVEczXzY0QklUX1JFR19MT1csDQorCQkJICAgICAweDAwMDAwMDAwKTsNCisJ fQ0KKw0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZ0cC0+bG9jaywgZmxhZ3MpOw0KKw0KKwly ZXR1cm4gSVJRX1JFVFZBTCgxKTsNCit9DQorDQogc3RhdGljIGlycXJldHVybl90IHRnM19pbnRl cnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLCBzdHJ1Y3QgcHRfcmVncyAqcmVncykNCiB7DQog CXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBkZXZfaWQ7DQpAQCAtMjk2NSw3ICszMDAyLDkgQEAN CiAjaWZkZWYgQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVINCiBzdGF0aWMgdm9pZCB0ZzNfcG9s bF9jb250cm9sbGVyKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0KLQl0ZzNfaW50ZXJydXB0 KGRldi0+aXJxLCBkZXYsIE5VTEwpOw0KKwlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9wcml2KGRl dik7DQorDQorCXRnM19pbnRlcnJ1cHQodHAtPnBkZXYtPmlycSwgZGV2LCBOVUxMKTsNCiB9DQog I2VuZGlmDQogDQpAQCAtNTc3OCwxMCArNTgxNywyOSBAQA0KIAlpZiAoZXJyKQ0KIAkJcmV0dXJu IGVycjsNCiANCi0JZXJyID0gcmVxdWVzdF9pcnEoZGV2LT5pcnEsIHRnM19pbnRlcnJ1cHQsDQot CQkJICBTQV9TSElSUSwgZGV2LT5uYW1lLCBkZXYpOw0KKwlpZiAoKHRwLT50ZzNfZmxhZ3MyICYg VEczX0ZMRzJfNTc1MF9QTFVTKSAmJg0KKwkgICAgKEdFVF9DSElQX1JFVih0cC0+cGNpX2NoaXBf cmV2X2lkKSAhPSBDSElQUkVWXzU3NTBfQVgpICYmDQorCSAgICAoR0VUX0NISVBfUkVWKHRwLT5w Y2lfY2hpcF9yZXZfaWQpICE9IENISVBSRVZfNTc1MF9CWCkpIHsNCisJCWlmIChwY2lfZW5hYmxl X21zaSh0cC0+cGRldikgPT0gMCkgew0KKwkJCXUzMiBtc2lfbW9kZTsNCisNCisJCQltc2lfbW9k ZSA9IHRyMzIoTVNHSU5UX01PREUpOw0KKwkJCXR3MzIoTVNHSU5UX01PREUsIG1zaV9tb2RlIHwg TVNHSU5UX01PREVfRU5BQkxFKTsNCisJCQl0cC0+dGczX2ZsYWdzMiB8PSBURzNfRkxHMl9VU0lO R19NU0k7DQorCQl9DQorCX0NCisJaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfVVNJTkdf TVNJKQ0KKwkJZXJyID0gcmVxdWVzdF9pcnEodHAtPnBkZXYtPmlycSwgdGczX21zaSwNCisJCQkJ ICAwLCBkZXYtPm5hbWUsIGRldik7DQorCWVsc2UNCisJCWVyciA9IHJlcXVlc3RfaXJxKHRwLT5w ZGV2LT5pcnEsIHRnM19pbnRlcnJ1cHQsDQorCQkJCSAgU0FfU0hJUlEsIGRldi0+bmFtZSwgZGV2 KTsNCiANCiAJaWYgKGVycikgew0KKwkJaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfVVNJ TkdfTVNJKSB7DQorCQkJcGNpX2Rpc2FibGVfbXNpKHRwLT5wZGV2KTsNCisJCQl0cC0+dGczX2Zs YWdzMiAmPSB+VEczX0ZMRzJfVVNJTkdfTVNJOw0KKwkJfQ0KIAkJdGczX2ZyZWVfY29uc2lzdGVu dCh0cCk7DQogCQlyZXR1cm4gZXJyOw0KIAl9DQpAQCAtNTgxMSw3ICs1ODY5LDExIEBADQogCXNw aW5fdW5sb2NrX2lycSgmdHAtPmxvY2spOw0KIA0KIAlpZiAoZXJyKSB7DQotCQlmcmVlX2lycShk ZXYtPmlycSwgZGV2KTsNCisJCWZyZWVfaXJxKHRwLT5wZGV2LT5pcnEsIGRldik7DQorCQlpZiAo dHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9VU0lOR19NU0kpIHsNCisJCQlwY2lfZGlzYWJsZV9t c2kodHAtPnBkZXYpOw0KKwkJCXRwLT50ZzNfZmxhZ3MyICY9IH5URzNfRkxHMl9VU0lOR19NU0k7 DQorCQl9DQogCQl0ZzNfZnJlZV9jb25zaXN0ZW50KHRwKTsNCiAJCXJldHVybiBlcnI7DQogCX0N CkBAIC02MDg2LDcgKzYxNDgsMTEgQEANCiAJc3Bpbl91bmxvY2soJnRwLT50eF9sb2NrKTsNCiAJ c3Bpbl91bmxvY2tfaXJxKCZ0cC0+bG9jayk7DQogDQotCWZyZWVfaXJxKGRldi0+aXJxLCBkZXYp Ow0KKwlmcmVlX2lycSh0cC0+cGRldi0+aXJxLCBkZXYpOw0KKwlpZiAodHAtPnRnM19mbGFnczIg JiBURzNfRkxHMl9VU0lOR19NU0kpIHsNCisJCXBjaV9kaXNhYmxlX21zaSh0cC0+cGRldik7DQor CQl0cC0+dGczX2ZsYWdzMiAmPSB+VEczX0ZMRzJfVVNJTkdfTVNJOw0KKwl9DQogDQogCW1lbWNw eSgmdHAtPm5ldF9zdGF0c19wcmV2LCB0ZzNfZ2V0X3N0YXRzKHRwLT5kZXYpLA0KIAkgICAgICAg c2l6ZW9mKHRwLT5uZXRfc3RhdHNfcHJldikpOw0KZGlmZiAtTnJ1IDEwOS9kcml2ZXJzL25ldC90 ZzMuaCAxMTAvZHJpdmVycy9uZXQvdGczLmgNCi0tLSAxMDkvZHJpdmVycy9uZXQvdGczLmgJMjAw NS0wNC0xNSAyMToyNToyNi4wMDAwMDAwMDAgLTA3MDANCisrKyAxMTAvZHJpdmVycy9uZXQvdGcz LmgJMjAwNS0wNC0xNSAyMToyNzoxNy4wMDAwMDAwMDAgLTA3MDANCkBAIC0yMTIzLDYgKzIxMjMs NyBAQA0KICNkZWZpbmUgVEczX0ZMRzJfNTcwNV9QTFVTCQkweDAwMDQwMDAwDQogI2RlZmluZSBU RzNfRkxHMl81NzUwX1BMVVMJCTB4MDAwODAwMDANCiAjZGVmaW5lIFRHM19GTEcyX1BST1RFQ1RF RF9OVlJBTQkweDAwMTAwMDAwDQorI2RlZmluZSBURzNfRkxHMl9VU0lOR19NU0kJCTB4MDAyMDAw MDANCiANCiAJdTMyCQkJCXNwbGl0X21vZGVfbWF4X3JlcXM7DQogI2RlZmluZSBTUExJVF9NT0RF XzU3MDRfTUFYX1JFUQkJMw0K --=-+OwyLnYapssM1hx625M6-- From mchan@broadcom.com Mon Apr 18 02:01:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 02:01:15 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I91AQR004426 for ; Mon, 18 Apr 2005 02:01:10 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 18 Apr 2005 02:01:40 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 18 Apr 2005 02:00:54 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id ATQ09985; Mon, 18 Apr 2005 02:00:52 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id CAA16618; Mon, 18 Apr 2005 02:00:51 -0700 (PDT) Received: from 10.7.18.136 ([10.7.18.136]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 09:00:51 +0000 Received: from rh4 by nt-irva-0741; 18 Apr 2005 01:02:40 -0700 Subject: [PATCH 2.6.12-rc2 11/11] tg3: Add msi test From: "Michael Chan" To: "John W. Linville" , davem@davemloft.net cc: netdev@oss.sgi.com In-Reply-To: <1113809864.6504.58.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> <1113809864.6504.58.camel@rh4> Date: Mon, 18 Apr 2005 01:02:40 -0700 Message-ID: <1113811360.6504.85.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E7DA8FE1OC380795-01-01 Content-Type: multipart/mixed; boundary="=-/I08wEcZ8vbjsMdzaBww" X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 6428 Lines: 100 --=-/I08wEcZ8vbjsMdzaBww Content-Type: text/plain Content-Transfer-Encoding: 7bit Add MSI test for chips that support MSI. If MSI test fails, it will switch back to INTx mode and will print a message asking the user to report the failure. Signed-off-by: Michael Chan --=-/I08wEcZ8vbjsMdzaBww Content-Disposition: attachment; filename=tg3-111.patch Content-Type: text/x-patch; charset=utf-8; name=tg3-111.patch Content-Transfer-Encoding: base64 ZGlmZiAtTnJ1IDExMC9kcml2ZXJzL25ldC90ZzMuYyAxMTEvZHJpdmVycy9uZXQvdGczLmMNCi0t LSAxMTAvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNSAyMToyNzoxNy4wMDAwMDAwMDAgLTA3 MDANCisrKyAxMTEvZHJpdmVycy9uZXQvdGczLmMJMjAwNS0wNC0xNyAyMzoxMTowNy4wMDAwMDAw MDAgLTA3MDANCkBAIC0yOTk2LDYgKzI5OTYsMjIgQEANCiAJcmV0dXJuIElSUV9SRVRWQUwoaGFu ZGxlZCk7DQogfQ0KIA0KKy8qIElTUiBmb3IgaW50ZXJydXB0IHRlc3QgKi8NCitzdGF0aWMgaXJx cmV0dXJuX3QgdGczX3Rlc3RfaXNyKGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisJCXN0cnVjdCBw dF9yZWdzICpyZWdzKQ0KK3sNCisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IGRldl9pZDsNCisJ c3RydWN0IHRnMyAqdHAgPSBuZXRkZXZfcHJpdihkZXYpOw0KKwlzdHJ1Y3QgdGczX2h3X3N0YXR1 cyAqc2JsayA9IHRwLT5od19zdGF0dXM7DQorDQorCWlmIChzYmxrLT5zdGF0dXMgJiBTRF9TVEFU VVNfVVBEQVRFRCkgew0KKwkJdHczMl9tYWlsYm94KE1BSUxCT1hfSU5URVJSVVBUXzAgKyBURzNf NjRCSVRfUkVHX0xPVywNCisJCQkgICAgIDB4MDAwMDAwMDEpOw0KKwkJcmV0dXJuIElSUV9SRVRW QUwoMSk7DQorCX0NCisJcmV0dXJuIElSUV9SRVRWQUwoMCk7DQorfQ0KKw0KIHN0YXRpYyBpbnQg dGczX2luaXRfaHcoc3RydWN0IHRnMyAqKTsNCiBzdGF0aWMgaW50IHRnM19oYWx0KHN0cnVjdCB0 ZzMgKik7DQogDQpAQCAtNTc5Niw2ICs1ODEyLDExOCBAQA0KIAlhZGRfdGltZXIoJnRwLT50aW1l cik7DQogfQ0KIA0KK3N0YXRpYyBpbnQgdGczX3Rlc3RfaW50ZXJydXB0KHN0cnVjdCB0ZzMgKnRw KQ0KK3sNCisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IHRwLT5kZXY7DQorCWludCBlcnIsIGk7 DQorCXUzMiBpbnRfbWJveCA9IDA7DQorDQorCXRnM19kaXNhYmxlX2ludHModHApOw0KKw0KKwlm cmVlX2lycSh0cC0+cGRldi0+aXJxLCBkZXYpOw0KKw0KKwllcnIgPSByZXF1ZXN0X2lycSh0cC0+ cGRldi0+aXJxLCB0ZzNfdGVzdF9pc3IsDQorCQkJICBTQV9TSElSUSwgZGV2LT5uYW1lLCBkZXYp Ow0KKwlpZiAoZXJyKQ0KKwkJcmV0dXJuIGVycjsNCisNCisJdGczX2VuYWJsZV9pbnRzKHRwKTsN CisNCisJdHczMl9mKEhPU1RDQ19NT0RFLCB0cC0+Y29hbGVzY2VfbW9kZSB8IEhPU1RDQ19NT0RF X0VOQUJMRSB8DQorCSAgICAgICBIT1NUQ0NfTU9ERV9OT1cpOw0KKw0KKwlmb3IgKGkgPSAwOyBp IDwgNTsgaSsrKSB7DQorCQlpbnRfbWJveCA9IHRyMzIoTUFJTEJPWF9JTlRFUlJVUFRfMCArIFRH M182NEJJVF9SRUdfTE9XKTsNCisJCWlmIChpbnRfbWJveCAhPSAwKQ0KKwkJCWJyZWFrOw0KKwkJ bXNsZWVwKDEwKTsNCisJfQ0KKw0KKwl0ZzNfZGlzYWJsZV9pbnRzKHRwKTsNCisNCisJZnJlZV9p cnEodHAtPnBkZXYtPmlycSwgZGV2KTsNCisJDQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19G TEcyX1VTSU5HX01TSSkNCisJCWVyciA9IHJlcXVlc3RfaXJxKHRwLT5wZGV2LT5pcnEsIHRnM19t c2ksDQorCQkJCSAgMCwgZGV2LT5uYW1lLCBkZXYpOw0KKwllbHNlDQorCQllcnIgPSByZXF1ZXN0 X2lycSh0cC0+cGRldi0+aXJxLCB0ZzNfaW50ZXJydXB0LA0KKwkJCQkgIFNBX1NISVJRLCBkZXYt Pm5hbWUsIGRldik7DQorDQorCWlmIChlcnIpDQorCQlyZXR1cm4gZXJyOw0KKw0KKwlpZiAoaW50 X21ib3ggIT0gMCkNCisJCXJldHVybiAwOw0KKw0KKwlyZXR1cm4gLUVJTzsNCit9DQorDQorLyog UmV0dXJucyAwIGlmIE1TSSB0ZXN0IHN1Y2NlZWRzIG9yIE1TSSB0ZXN0IGZhaWxzIGFuZCBJTlR4 IG1vZGUgaXMNCisgKiBzdWNjZXNzZnVsbHkgcmVzdG9yZWQNCisgKi8NCitzdGF0aWMgaW50IHRn M190ZXN0X21zaShzdHJ1Y3QgdGczICp0cCkNCit7DQorCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYg PSB0cC0+ZGV2Ow0KKwlpbnQgZXJyOw0KKwl1MTYgcGNpX2NtZDsNCisNCisJaWYgKCEodHAtPnRn M19mbGFnczIgJiBURzNfRkxHMl9VU0lOR19NU0kpKQ0KKwkJcmV0dXJuIDA7DQorDQorCS8qIFR1 cm4gb2ZmIFNFUlIgcmVwb3J0aW5nIGluIGNhc2UgTVNJIHRlcm1pbmF0ZXMgd2l0aCBNYXN0ZXIN CisJICogQWJvcnQuDQorCSAqLw0KKwlwY2lfcmVhZF9jb25maWdfd29yZCh0cC0+cGRldiwgUENJ X0NPTU1BTkQsICZwY2lfY21kKTsNCisJcGNpX3dyaXRlX2NvbmZpZ193b3JkKHRwLT5wZGV2LCBQ Q0lfQ09NTUFORCwNCisJCQkgICAgICBwY2lfY21kICYgflBDSV9DT01NQU5EX1NFUlIpOw0KKw0K KwllcnIgPSB0ZzNfdGVzdF9pbnRlcnJ1cHQodHApOw0KKw0KKwlwY2lfd3JpdGVfY29uZmlnX3dv cmQodHAtPnBkZXYsIFBDSV9DT01NQU5ELCBwY2lfY21kKTsNCisNCisJaWYgKCFlcnIpDQorCQly ZXR1cm4gMDsNCisNCisJLyogb3RoZXIgZmFpbHVyZXMgKi8NCisJaWYgKGVyciAhPSAtRUlPKQ0K KwkJcmV0dXJuIGVycjsNCisNCisJLyogTVNJIHRlc3QgZmFpbGVkLCBnbyBiYWNrIHRvIElOVHgg bW9kZSAqLw0KKwlwcmludGsoS0VSTl9XQVJOSU5HIFBGWCAiJXM6IE5vIGludGVycnVwdCB3YXMg Z2VuZXJhdGVkIHVzaW5nIE1TSSwgIg0KKwkgICAgICAgInN3aXRjaGluZyB0byBJTlR4IG1vZGUu IFBsZWFzZSByZXBvcnQgdGhpcyBmYWlsdXJlIHRvICINCisJICAgICAgICJ0aGUgUENJIG1haW50 YWluZXIgYW5kIGluY2x1ZGUgc3lzdGVtIGNoaXBzZXQgaW5mb3JtYXRpb24uXG4iLA0KKwkJICAg ICAgIHRwLT5kZXYtPm5hbWUpOw0KKw0KKwlmcmVlX2lycSh0cC0+cGRldi0+aXJxLCBkZXYpOw0K KwlwY2lfZGlzYWJsZV9tc2kodHAtPnBkZXYpOw0KKw0KKwl0cC0+dGczX2ZsYWdzMiAmPSB+VEcz X0ZMRzJfVVNJTkdfTVNJOw0KKw0KKwllcnIgPSByZXF1ZXN0X2lycSh0cC0+cGRldi0+aXJxLCB0 ZzNfaW50ZXJydXB0LA0KKwkJCSAgU0FfU0hJUlEsIGRldi0+bmFtZSwgZGV2KTsNCisNCisJaWYg KGVycikNCisJCXJldHVybiBlcnI7DQorDQorCS8qIE5lZWQgdG8gcmVzZXQgdGhlIGNoaXAgYmVj YXVzZSB0aGUgTVNJIGN5Y2xlIG1heSBoYXZlIHRlcm1pbmF0ZWQNCisJICogd2l0aCBNYXN0ZXIg QWJvcnQuDQorCSAqLw0KKwlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7DQorCXNwaW5fbG9jaygm dHAtPnR4X2xvY2spOw0KKw0KKwl0ZzNfaGFsdCh0cCk7DQorCWVyciA9IHRnM19pbml0X2h3KHRw KTsNCisNCisJc3Bpbl91bmxvY2soJnRwLT50eF9sb2NrKTsNCisJc3Bpbl91bmxvY2tfaXJxKCZ0 cC0+bG9jayk7DQorDQorCWlmIChlcnIpDQorCQlmcmVlX2lycSh0cC0+cGRldi0+aXJxLCBkZXYp Ow0KKw0KKwlyZXR1cm4gZXJyOw0KK30NCisNCiBzdGF0aWMgaW50IHRnM19vcGVuKHN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpDQogew0KIAlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9wcml2KGRldik7 DQpAQCAtNTg2MCw5ICs1OTg4LDYgQEANCiAJCXRwLT50aW1lci5leHBpcmVzID0gamlmZmllcyAr IHRwLT50aW1lcl9vZmZzZXQ7DQogCQl0cC0+dGltZXIuZGF0YSA9ICh1bnNpZ25lZCBsb25nKSB0 cDsNCiAJCXRwLT50aW1lci5mdW5jdGlvbiA9IHRnM190aW1lcjsNCi0JCWFkZF90aW1lcigmdHAt PnRpbWVyKTsNCi0NCi0JCXRwLT50ZzNfZmxhZ3MgfD0gVEczX0ZMQUdfSU5JVF9DT01QTEVURTsN CiAJfQ0KIA0KIAlzcGluX3VubG9jaygmdHAtPnR4X2xvY2spOw0KQEAgLTU4NzgsOSArNjAwMywz MiBAQA0KIAkJcmV0dXJuIGVycjsNCiAJfQ0KIA0KKwlpZiAodHAtPnRnM19mbGFnczIgJiBURzNf RkxHMl9VU0lOR19NU0kpIHsNCisJCWVyciA9IHRnM190ZXN0X21zaSh0cCk7DQorCQlpZiAoZXJy KSB7DQorCQkJc3Bpbl9sb2NrX2lycSgmdHAtPmxvY2spOw0KKwkJCXNwaW5fbG9jaygmdHAtPnR4 X2xvY2spOw0KKw0KKwkJCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1VTSU5HX01TSSkg ew0KKwkJCQlwY2lfZGlzYWJsZV9tc2kodHAtPnBkZXYpOw0KKwkJCQl0cC0+dGczX2ZsYWdzMiAm PSB+VEczX0ZMRzJfVVNJTkdfTVNJOw0KKwkJCX0NCisJCQl0ZzNfaGFsdCh0cCk7DQorCQkJdGcz X2ZyZWVfcmluZ3ModHApOw0KKwkJCXRnM19mcmVlX2NvbnNpc3RlbnQodHApOw0KKw0KKwkJCXNw aW5fdW5sb2NrKCZ0cC0+dHhfbG9jayk7DQorCQkJc3Bpbl91bmxvY2tfaXJxKCZ0cC0+bG9jayk7 DQorDQorCQkJcmV0dXJuIGVycjsNCisJCX0NCisJfQ0KKw0KIAlzcGluX2xvY2tfaXJxKCZ0cC0+ bG9jayk7DQogCXNwaW5fbG9jaygmdHAtPnR4X2xvY2spOw0KIA0KKwlhZGRfdGltZXIoJnRwLT50 aW1lcik7DQorCXRwLT50ZzNfZmxhZ3MgfD0gVEczX0ZMQUdfSU5JVF9DT01QTEVURTsNCiAJdGcz X2VuYWJsZV9pbnRzKHRwKTsNCiANCiAJc3Bpbl91bmxvY2soJnRwLT50eF9sb2NrKTsNCg== --=-/I08wEcZ8vbjsMdzaBww-- From tgraf@suug.ch Mon Apr 18 03:16:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 03:17:04 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IAGvm1011391 for ; Mon, 18 Apr 2005 03:16:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 927871C0EB; Mon, 18 Apr 2005 12:17:11 +0200 (CEST) Date: Mon, 18 Apr 2005 12:17:11 +0200 From: Thomas Graf To: Herbert Xu Cc: fmp@palmen.homeip.net, netdev@oss.sgi.com Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Message-ID: <20050418101711.GP4114@postel.suug.ch> References: <20050411125113.GL26731@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 435 Lines: 11 * Herbert Xu 2005-04-18 12:07 > Thomas Graf wrote: > > > > OK, I think the problem is a few missing dev_hold() when the net_device > > handle is assigned to routes, probes, etc. > > Indeed. Here is a patch that adds the references that are held by > the routes. Thanks for taking over Herbert, I simply didn't have the time lately. The patch looks perfectly fine to me. From parklee_sel@yahoo.com Mon Apr 18 03:44:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 03:44:58 -0700 (PDT) Received: from web51501.mail.yahoo.com (web51501.mail.yahoo.com [206.190.38.193]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3IAioIT012852 for ; Mon, 18 Apr 2005 03:44:51 -0700 Received: (qmail 70405 invoked by uid 60001); 18 Apr 2005 10:44:45 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=nCj94AWDFZ1AW6QdUWMc0j2VM/yfwnEkqVov8x4P6fKjKRXBw6gkYEKNrB1OZs/qF1hU4044nAArwACUQy6qbPbiKbwj2NuuAC0+dLQJImuzbKp/8h6soT0vsBYlwOL4pMson5DjJm9YhzRT2Qa8HDRITeVuy1zIPANGEV6FIyM= ; Message-ID: <20050418104445.70403.qmail@web51501.mail.yahoo.com> Received: from [221.15.137.175] by web51501.mail.yahoo.com via HTTP; Mon, 18 Apr 2005 03:44:45 PDT Date: Mon, 18 Apr 2005 03:44:45 -0700 (PDT) From: Park Lee Subject: Does a forwarded packet has a local socket with it? To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 284 Lines: 19 Hi, Can anyone tell me that: Does a forwarded packet has a corresponding local socket with it? Thanks a lot Best Regards, Park Lee __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From hadi@cyberus.ca Mon Apr 18 05:03:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 05:03:32 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IC3SII021870 for ; Mon, 18 Apr 2005 05:03:28 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DNUyL-0003It-6M for netdev@oss.sgi.com; Mon, 18 Apr 2005 08:03:25 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DNUyI-00069p-T3; Mon, 18 Apr 2005 08:03:23 -0400 Subject: Re: Does a forwarded packet has a local socket with it? From: jamal Reply-To: hadi@cyberus.ca To: Park Lee Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20050418104445.70403.qmail@web51501.mail.yahoo.com> References: <20050418104445.70403.qmail@web51501.mail.yahoo.com> Content-Type: text/plain Organization: unknown Date: Mon, 18 Apr 2005 08:03:19 -0400 Message-Id: <1113825799.7419.66.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1809 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: 414 Lines: 28 simple answer: no cheers, jamal On Mon, 2005-18-04 at 03:44 -0700, Park Lee wrote: > Hi, > > Can anyone tell me that: > > Does a forwarded packet has a corresponding local > socket with it? > > Thanks a lot > > > Best Regards, > Park Lee > > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > http://mobile.yahoo.com/maildemo > > From hadi@cyberus.ca Mon Apr 18 05:15:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 05:15:09 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ICF3hv022968 for ; Mon, 18 Apr 2005 05:15:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DNV9Y-0002m2-GQ for netdev@oss.sgi.com; Mon, 18 Apr 2005 08:15:00 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DNV9W-0007Pb-RY; Mon, 18 Apr 2005 08:14:59 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: "Brandeburg, Jesse" Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: unknown Date: Mon, 18 Apr 2005 08:14:55 -0400 Message-Id: <1113826496.7419.78.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1810 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: 1097 Lines: 30 Jesse, I doubt your problem has to do with interrupt rates. If you say the CPU is "fast" - then the problem is elsewhere. A fast machine that cant handle 77K interupt/sec would be a pathetic one. It could be the PCI IO rate which such a fast system shouldnt have issues handling. You say it can process upto two packets/interupt -so thats pretty fast. Actually it could be the e100 issue - try replacing the NIC with e1000 and repeat your tests and see if you observe the same issues. If you are doing the netperf tests then collect netstat -s output; /proc/net/softnet_stat is another useful stat to look at. cheers, jamal On Sun, 2005-17-04 at 23:11 -0700, Brandeburg, Jesse wrote: > _Summary_ > As the part owner of the e100 driver, this issue has been nagging at me > for a while. NAPI seems to be able to swamp a system with interrupts > and context switches. In this case the system does not respond to > having zero cpu cycles available by polling more, as I figured it would. > This was mostly based on observation, but I included some quick data > gathering for this mail. > From alan@lxorguk.ukuu.org.uk Mon Apr 18 05:57:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 05:58:01 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ICvuvv024895 for ; Mon, 18 Apr 2005 05:57:56 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j3ICtEdW014944; Mon, 18 Apr 2005 13:55:15 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j3ICtBEA014943; Mon, 18 Apr 2005 13:55:11 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.6 patch] drivers/net/wan/: possible cleanups From: Alan Cox To: Adrian Bunk Cc: netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20050417234738.GY3625@stusta.de> References: <20050327143418.GE4285@stusta.de> <1111941516.14877.325.camel@localhost.localdomain> <20050414232028.GD20400@stusta.de> <1113587392.11155.33.camel@localhost.localdomain> <20050417234738.GY3625@stusta.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1113828904.17058.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Apr 2005 13:55:06 +0100 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 695 Lines: 20 On Llu, 2005-04-18 at 00:47, Adrian Bunk wrote: > Are there any external drivers using these exports, and if there are, > why aren't they in the kernel? Its a standard API > If there aren't and someone will at some time in the future need them, > re-adding the exports will be trivial. Really, you will spotaneously magically make them appear in old kernels that end users have just like that ? Your argument doesn't hold water. Its an API for drivers so that people can add 85x30 card drivers using DMA in this fashion. Its an API so they can add them to *EXISTING* kernels without users being forced to recompile/wait for the vendor to update their tree/upgrade to a new release. Alan From hadi@cyberus.ca Mon Apr 18 06:14:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 06:14:42 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IDEWG0026068 for ; Mon, 18 Apr 2005 06:14:35 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DNW57-0004tk-Fw for netdev@oss.sgi.com; Mon, 18 Apr 2005 09:14:29 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DNW54-0007FT-HZ; Mon, 18 Apr 2005 09:14:26 -0400 Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) From: jamal Reply-To: hadi@cyberus.ca To: Wang Jian Cc: netdev In-Reply-To: <20050413131916.030F.LARK@linux.net.cn> References: <20050407203631.02CF.LARK@linux.net.cn> <1112964208.1088.226.camel@jzny.localdomain> <20050413131916.030F.LARK@linux.net.cn> Content-Type: text/plain Organization: unknown Date: Mon, 18 Apr 2005 09:14:23 -0400 Message-Id: <1113830063.26757.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1812 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: 4984 Lines: 148 Wang Jian, On Wed, 2005-13-04 at 13:45 +0800, Wang Jian wrote: > Hi jamal, > > Sorry for the late reply. I am occupied by other things and just have > time back to this topic. > Well, apologies from here as well - i missed responding on time. > On 08 Apr 2005 08:43:28 -0400, jamal wrote: > > > > The reclassification or #1 will best be left to the user. This is not > > hard to do. > > I scan through other code and find no easy way to redirect non-handled > traffic to another class. Can you give me some hint on that? > There are two constructs at the classifier level: the first one is "reclassify" which basically asks the classification activity to restart. Another one is the " continue" construct which basically asks for the classification to continue where the last one ended. Does this explanation help? > > > > Ok, stop calling it per-flow-queue then ;-> You should call it > > per-flow-rate-guarantee. > > I have renamed it to frg (flow rate guarantee) per your suggestion. > After the above reclassification is done, I will post new patch here. > > I will extend the concept of flow to include GRE, so pptp VPN can be > supported. There are other 'flows' to consider. > I think you should start by decoupling the classification away from your qdisc. > > Sharing is not a big challenge - and should be policy driven. > > HTB and CBQ both support it. I am not sure about HFSC. > > > > Still, I am not clear if you understand me. How it works for this > purpose: > > guarantee and only guarantee rate * n when there are n flows? > > When there only 1 flow, guarantee only rate * 1 > When there only 2 flows, guarantee only rate * 2 > ... > and so on > sure and at some point you exceed available bandwidth. You can over-provision of course. > If always guarantee rate * limit, then the excessive guaranteed rate can > be abused. > I didnt follow this. > But if always guarantee only rate * 1, then it is not enough. > I also didnt follow this. Lets say you have 8 flows; each to be guaranteed 100Kbps. Lets say your wire rate is only 1Mbps. Then you create policies so that each gets 100Kbps. If they all use their quota you still have 200Kbps to play with. You could then say that out of that 200Kps, 100kbps is to be shared amongst the 8 flows if they exceed their allocated 100Kbps(sharing) and the other 100kbps is for best effort traffic. In this case, each flow is _guaranteed_ 100Kbps and upto 100Kbps from shared quota if no-one else is using that shared quota. If multi flows are using the shared 100Kbps then, its given out on first come basis. "Guaranteed" in this case means it is _reserved_ i.e if flow #3 is not using its allocation, flow #2 cant use it. Ok, so now tell me where you and i are differing on semantics? Is the above what you are also saying? > > So it seems you want by all means to avoid entering something that > > will take forever to list. Did i understand this correctly? > > Yes. It is special purpose but general enough. I think it's worthy of > adding a new qdisc for it to avoid the dirty long listing part. > I am not sure about the "general enough" part. You need to know what is happening at any instance in time if this is to be useful. So that information for listing should be available - you may wish not to display it unless someone asks for verbose output. > > > > We can probably avoid insisting on dynamically creating classes maybe. > > You can rate control before you enqueue and we can use fwmark perhaps. > > Earlier i also asked whether policing will suffice. Heres an example > > (maybe dated syntax, but concept still valid) that shows sharing using > > policers: > > http://www.cyberus.ca/~hadi/patches/action/README > > I will look at it later. > Please do so we can have a synchronized discussion. > If we can do it with one thing, we should avoid creating 1000 things. > The policy way works but is dirty. yes, but that hiding can be hidden at user space for example. There are several levels of verbosity if you insist: - See nothing - just see info which says "at the moment we have 234 classes dynamically created" - get a full listing for each of 234 classes and their attributes. - get a full listing for each 234 class and their attributes as well as stats. > > I would think the number 1000 should be related to hash of flow header, > > no? In which case there should be no collision unless the hash of ftp > > and http are 1000. > > > > To save netfilter rule matching work, if the CONNMARK is set, then it > will be used to set nfmark. > > If a CONNMARK is already set on this http stream, it will be kept. Then > if you redefine 1:1000 as another meaning, then this http carrying > 1:1000 will be mis-classified. > your policy management/scripts are then responsible to make sure everything is synchronized between iptables and tc. Once we have the tracker action, this would only need to be doen via tc. cheers, jamal From parklee_sel@yahoo.com Mon Apr 18 07:03:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 07:03:59 -0700 (PDT) Received: from web51509.mail.yahoo.com (web51509.mail.yahoo.com [206.190.38.201]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3IE3r0h001781 for ; Mon, 18 Apr 2005 07:03:53 -0700 Received: (qmail 33644 invoked by uid 60001); 18 Apr 2005 14:03:48 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=vMOL9SsWhJe4C5ywawWRqtW5hY76yTE/opZ3Ggzsd+bxKTuUzXGJGxfE+L6pYk1X5lc7Oe3cFSsv3NdpimmVOeC/SkeCMNhB1kzCvdo0TdFWGrk9At/0UbhYat8xSU9+BhoOWHcMz0KukW1zQyOjF0m4K6kAP0ftpQrp4xm5Q3s= ; Message-ID: <20050418140348.33642.qmail@web51509.mail.yahoo.com> Received: from [221.15.137.175] by web51509.mail.yahoo.com via HTTP; Mon, 18 Apr 2005 07:03:47 PDT Date: Mon, 18 Apr 2005 07:03:47 -0700 (PDT) From: Park Lee Subject: Re: Does a forwarded packet has a local socket with it? To: jamal Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 559 Lines: 24 On Mon, 18 Apr 2005 at 08:03, jamal wrote: > simple answer: no Thank you very much. Still, Does a forwarded packet also have no any kernel socket with it? i.e. Is a forwarded packet not associated with any socket at all? When the forwarded packet arrived at its destination machine, is there any socket associated with the packet on the destination machine? Thanks again. Best Regards, Park Lee __________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide From arnaldo.melo@gmail.com Mon Apr 18 07:48:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 07:48:26 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IEmIZ3003608 for ; Mon, 18 Apr 2005 07:48:19 -0700 Received: by zproxy.gmail.com with SMTP id 8so422187nzo for ; Mon, 18 Apr 2005 07:48:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GtLvPIkqB5DQIL2GUCVU7NxKUB9fwrQY0lA8giZOk1wDNeZ/QrGADeJUsUCA2qRIjxC1eZeO2wG94GquIRzQeSvsyJAINdVnNwkpTE0LIHwr7/zGC1tMx1AKTYh1hiZf0DZk55ZcOEwVIigIVFurGmOz1THFjNQijLIfd6KOVas= Received: by 10.36.12.3 with SMTP id 3mr375471nzl; Mon, 18 Apr 2005 07:48:13 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Mon, 18 Apr 2005 07:48:13 -0700 (PDT) Message-ID: <39e6f6c705041807481bb715d6@mail.gmail.com> Date: Mon, 18 Apr 2005 11:48:13 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Herbert Xu Subject: Re: Fw: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11 Cc: Thomas Graf , fmp@palmen.homeip.net, netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050418080902.GA5675@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125113.GL26731@postel.suug.ch> <20050418080902.GA5675@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3IEmIZ3003608 X-archive-position: 1814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 868 Lines: 20 On 4/18/05, Herbert Xu wrote: > On Mon, Apr 18, 2005 at 12:07:49PM +1000, Herbert Xu wrote: > > > > Indeed. Here is a patch that adds the references that are held by > > the routes. > > BTW, there are other problems in the appletalk stack that should > be fixed too. For instance, the route entries and skb's there don't > hold a reference to the device that they point to. So if anyone is > going to spend time on appletalk then they should have a look at them. Appletalk is known to be in need of a major reworking, I haven't had time so far to devote to it even being listed as "MAINTAINER" of such stuff, perhaps I should send a patch dropping maintainership. After I'm satisfied with DCCP I may well revisit Appletalk to use the skills I got/new infrastructure I put in place while working on DCCP, time will tell. - Arnaldo From tgraf@suug.ch Mon Apr 18 07:50:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 07:50:17 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IEoB06003984 for ; Mon, 18 Apr 2005 07:50:11 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 4B6A81C0EB; Mon, 18 Apr 2005 16:50:24 +0200 (CEST) Date: Mon, 18 Apr 2005 16:50:24 +0200 From: Thomas Graf To: jamal Cc: Wang Jian , netdev Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Message-ID: <20050418145024.GS4114@postel.suug.ch> References: <20050407203631.02CF.LARK@linux.net.cn> <1112964208.1088.226.camel@jzny.localdomain> <20050413131916.030F.LARK@linux.net.cn> <1113830063.26757.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113830063.26757.15.camel@localhost.localdomain> X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5387 Lines: 147 Sorry for entering this discussion so late. * jamal <1113830063.26757.15.camel@localhost.localdomain> 2005-04-18 09:14 > I think you should start by decoupling the classification away from your > qdisc. Here are my thoughts on per flow queueing, actually the name "classification controlled queues" is be more accurate. First of all the whole problem must be divided into two parts: 1) queueing with per flow specific queueing parameters, i.e. the flow serves a certain purpose and is known by static parameters. 2) queueing with generic parameters, i.e. the purpose of a flow is solely to be fair, there is no difference between each flow. Both these cases can be handled with the current set of qdiscs and classificiation tools but often a combination of both is needed and that's where my thought begins: We use tc_classid to describe a flow but also to describe its assignment to the corresponding flow group (n flows are grouped together into a group to define a namespace, generally at the level of a qdisc). The tc_classid can be set via actions, either by using a generic action that creates a flowid out of the common tuple or by providing an own simple-action for customization, e.g. one could construct tc_classid ::= nfmark << 16 + hash(flowid) tc_classid is interpreted by either one of the existing qdiscs for static assignment or a new qdisc named "alloctor" The purpose of the allocator is to create qdiscs on demand, destroy them after they expired and to act as a muxer to enqueue into the dynamic leaf qdiscs. The alloactor can be configured to interpet the MSB 16bits of tc_classid as a flow group id and enqueue the skb to the corresponding clasfull qdisc with matches TC_H_MAJ_MASK bits. The following is in attempt to convert my scribbling on paper into ASCII: Use Case 1: Per flow queues using TBF 2. +-----------+ +------------+ +->| cls_basic |->| act_flowid | | +-----------+ +------------+ 1. +---------------+ | --------->| sch_allocator |<-------------+ +---------------+ 3. tc_classid= |4. +-----------+---------+- - - - - - | | | | +-----+ +-----+ +-----+ + - - + | TBF | | TBF | | TBF | | TBF | +-----+ +-----+ +-----+ + - - + sch_alloctor configuration: - no flow group map - default policy: allocate TBF for every tc_classid && enqueue to new qdisc - default template: tbf add rtnetlink message - default deletion template: tbf del rtnetlink message cls_basic configuration: - always true act_flowid configuration: - default: generate flowid hash and store in tc_classid Use Case 2: Flow groups 3. +---------+ +->| em_meta | | +---------+ +----+ | | v 4. 2. +-----------+ +-----------------+ +->| cls_basic |->| act_cust_flowid | | +-----------+ +-----------------+ 1. +-----------------+ | --------->| sch_allocator_1 |<--------------+ +-----------------+ 5. tc_classid=(nfmark<<16)+(flowid&0xFF) |6. +-----------+---+----------------+ | 11:/12: | 13: | *: +-----+ +-----------------+ +---------+ | HTB | | sch_allocator_2 | | default | +-----+ +-----------------+ +---------+ | | | +-------+- - - - | | | | | +-----+ +-----+ + - - + | | TBF | | TBF | | TBF | | +-----+ +-----+ + - - + | | +------------------+ | +----------+--------------+ | | +------------+ +------------+ | Class 20:1 | | Class 20:2 | +------------+ +------------+ | | +---------+- - - - - ..... | | | +-------+ +-------+ +- - - -+ | Class | | Class | | Class | +-------+ +-------+ +- - - -+ sch_alloctor_1 configuration: - flow group map: [11:] create class HTB parent 20:1 && enqueue to 20: [12:] create class HTB parent 20:2 && enqueue to 20: [13:] enqueue to sch_allocator_2 - default policy: enqueue to default qdisc sch_allocator_2 configuration: - no flow group map - default policy: allocate TBF for every tc_classid && enqueue to new qdisc - default template: tbf add rtnetlink message - default deletion template: tbf del rtnetlink message cls_basic configuration: - always true em_meta configuration: - filter out unknown nfmarks act_cust_flowid configuration: - (nfmark<<16)+(flowid&0xff) So basically what sch_allocator does is look at tc_classid, lookup the corresponding flow in the flow map or use the default action, execute the action, i.e. process the netlink message via a worker thread, rewrite tc_classid if needed, manage the created qdiscs/classes, account their last activity and destroy them eventually after no activity for a certain configurable time by executing the corresponding deletion netlink message. Thoughts? From Robert.Olsson@data.slu.se Mon Apr 18 08:36:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 08:36:18 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IFaC5l009181 for ; Mon, 18 Apr 2005 08:36:12 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3IFa8vs005466 for ; Mon, 18 Apr 2005 17:36:08 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 512ADEE1F1; Mon, 18 Apr 2005 17:36:08 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16995.54248.296368.769248@robur.slu.se> Date: Mon, 18 Apr 2005 17:36:08 +0200 To: "Brandeburg, Jesse" Cc: Subject: NAPI, e100, and system performance problem In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1816 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: 1939 Lines: 41 Brandeburg, Jesse writes: > _Summary_ > As the part owner of the e100 driver, this issue has been nagging at me > for a while. NAPI seems to be able to swamp a system with interrupts > and context switches. In this case the system does not respond to > having zero cpu cycles available by polling more, as I figured it would. > This was mostly based on observation, but I included some quick data > gathering for this mail. Hello! Well to sort out some things. NAPI address just the balance between irq and softirq's nothing else, In the balance between userland and sofirq's we pray that sofirq's should behave well. In some cases these are deferred to ksoftirqd to balance softirq/user. > With the current e100 driver in NAPI mode the adapter can generate > upwards of 36000 interrupts a second from only receiving 77000 > packets/second (pktgen traffic) You have a very fast CPU and slow device. Interrupt ISR handles two packets etc. Same for NAPI/non-NAPI path. Not bad really. Probably you had interrupt delay w. non-NAPI so the interrupt rate was a bit lower this OK w, NAPI too if you like it. > Is there any way we can configure how soon or often to be polled > (called)? For 100Mb speeds at worst we can get about one 64 byte packet > every 9us (if I did my math right) and since the processors don't take > that long to schedule NAPI, process a packet and handle an interrupt, we > just overload the system with interrupts going into and out of napi > mode. In this case I only have one adapter getting scheduled. Interrupt delay is the most straight forward... You can play with some driver timer. Balance timer and the RX ring size so it does not overflow and register for poll when the timer func have receive packets. You would see no interrupts at all... Could be fun it feel like sub-optimizing. No I think at these levels interrupts are our friends. Cheers. --ro From lark@linux.net.cn Mon Apr 18 09:02:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 09:02:08 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IG1tAn010542 for ; Mon, 18 Apr 2005 09:01:59 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 5FF4C3F99B; Tue, 19 Apr 2005 00:01:53 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 16508-01-3; Tue, 19 Apr 2005 00:01:49 +0800 (CST) Received: from [192.168.0.120] (unknown [61.48.104.234]) by mx.linux.net.cn (Postfix) with ESMTP id 1D9653F787; Tue, 19 Apr 2005 00:01:49 +0800 (CST) Date: Tue, 19 Apr 2005 00:01:48 +0800 From: Wang Jian To: hadi@cyberus.ca Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Cc: netdev In-Reply-To: <1113830063.26757.15.camel@localhost.localdomain> References: <20050413131916.030F.LARK@linux.net.cn> <1113830063.26757.15.camel@localhost.localdomain> Message-Id: <20050418214446.0389.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 6663 Lines: 167 Hi jamal, > > On 08 Apr 2005 08:43:28 -0400, jamal wrote: > > > > > > > > The reclassification or #1 will best be left to the user. This is not > > > hard to do. > > > > I scan through other code and find no easy way to redirect non-handled > > traffic to another class. Can you give me some hint on that? > > > > There are two constructs at the classifier level: the first one is > "reclassify" which basically asks the classification activity to > restart. Another one is the " continue" construct which basically asks > for the classification to continue where the last one ended. > Does this explanation help? > I will look into this afterwards. But I don't think this helps because FRG is not at classifier level. > > I will extend the concept of flow to include GRE, so pptp VPN can be > > supported. There are other 'flows' to consider. > > > > I think you should start by decoupling the classification away from your > qdisc. Actually, I am not very sure if FRG does do classification at the moment. Because FRG is a quick hack from looking at SFQ and FIFO, I am still not sure whether classification is what I think it is. There is so little documentation on how to write tc code :( FRG does things the same way as SFQ, the only difference is the flow tracking algorithm. So IMHO, my current code doesn't do classification at all. Am I wrong? > > Lets say you have 8 flows; each to be guaranteed 100Kbps. Lets say your > wire rate is only 1Mbps. > > Then you create policies so that each gets 100Kbps. If they all use > their quota you still have 200Kbps to play with. You could then say that > out of that 200Kps, 100kbps is to be shared amongst the 8 flows if they > exceed their allocated 100Kbps(sharing) and the other 100kbps is for > best effort traffic. > In this case, each flow is _guaranteed_ 100Kbps and upto 100Kbps from > shared quota if no-one else is using that shared quota. > If multi flows are using the shared 100Kbps then, its given out on first > come basis. "Guaranteed" in this case means it is _reserved_ i.e if flow > #3 is not using its allocation, flow #2 cant use it. > > Ok, so now tell me where you and i are differing on semantics? > Is the above what you are also saying? In the above, you still didn't mention "fewer flows than expected" case. This is what FRG wants to address. Also, "guaranteed" has difference semantics. For FRG, there are two rates: guaranteed and ceiled. 1. guaranteed rate is in the sense of "if you need so much, I will provide so much; but if you need not so much, others can use the spared" 2. ceiled rate is in the sense of "you can't exceed this much whenever and whatever" The guaranteed and ceiled rate take effects on a per flow basis, not on a group basis. So, if currently there is only one flow, FRG will only have 1*100kbps guaranteed, and have a ceil of 1*ceil kbps. Other traffic not managed by FRG can takes from 1Mbps - 1*ceil to 1Mbps - 1*100kbps bandwidth. This makes bandwidth to be used in more efficient way than _reserved_. This is "fewer flows than expected" case. But for the grouped quota, 1 flow can take upto 8*100kbps bandwidth, and more from the left 200kbps on the first comes first served basis. HTB/CBQ provides grouped quota. Why the difference? Because in the sense of per flow guarantee, it is supposed that if guaranteed rate is met, the flow will work well in most cases, and the available extra bandwidth ( ceil - guarantted_rate) merely is protection against possible jitter. A flow is hard limited below ceil, which prevents a flow hog the bandwidth. Of course, one htb class with rate + ceil per flow can do the same thing. And I think one policy perl flow can do the same thing too. The dynamic class or policy we discussed before can also work it out. But see below. > > > > So it seems you want by all means to avoid entering something that > > > will take forever to list. Did i understand this correctly? > > > > Yes. It is special purpose but general enough. I think it's worthy of > > adding a new qdisc for it to avoid the dirty long listing part. > > > > I am not sure about the "general enough" part. You need to know what is > happening at any instance in time if this is to be useful. So that > information for listing should be available - you may wish not to > display it unless someone asks for verbose output. > > > > > > > We can probably avoid insisting on dynamically creating classes maybe. > > > You can rate control before you enqueue and we can use fwmark perhaps. > > > Earlier i also asked whether policing will suffice. Heres an example > > > (maybe dated syntax, but concept still valid) that shows sharing using > > > policers: > > > http://www.cyberus.ca/~hadi/patches/action/README > > > > I will look at it later. > > > > Please do so we can have a synchronized discussion. > I have read it now. Considering the purpose why FRG is created, I didn't see it is useful, because it is still on "grouped" basis but not "flow" basis. > > > If we can do it with one thing, we should avoid creating 1000 things. > > The policy way works but is dirty. > > yes, but that hiding can be hidden at user space for example. > There are several levels of verbosity if you insist: > - See nothing > - just see info which says "at the moment we have 234 classes > dynamically created" > - get a full listing for each of 234 classes and their attributes. > - get a full listing for each 234 class and their attributes as well as > stats. Basically, the divergency between our opinions is not whether and how we can do it in that way, but why we should do it in that way. Current FRG implementation doesn't need its own filter. A FRG queue processes packets from its parent (leaf) class, which defines flow criteria. Internally, a FRG queue distinguishes and tracks flows, and do rate guarantee and ceil by manipulating packets over a single queue. The implementation is simple and clean, and does work as expected. It also simplify user space management. So the question is: why we should use a complex implementation which is also complicated in userspace (considering dynamic classid allocation), but not use a simple implementation which is also simple for userspace? > > your policy management/scripts are then responsible to make sure > everything is synchronized between iptables and tc. This is necessary, but this can range from simple to complex. Unfortunately, dynamic class/policy goes to the complex end. > Once we have the tracker action, this would only need to be doen via tc. > Is there any document about the tracker action? -- lark From Robert.Olsson@data.slu.se Mon Apr 18 09:06:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 09:06:30 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IG6OIr011445 for ; Mon, 18 Apr 2005 09:06:25 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3IG6NeW009483; Mon, 18 Apr 2005 18:06:23 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 69FDBEE1F1; Mon, 18 Apr 2005 18:06:23 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16995.56063.402097.475330@robur.slu.se> Date: Mon, 18 Apr 2005 18:06:23 +0200 To: Andre Tomt Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: FIB alternative fib_hash2.c In-Reply-To: <4260D2EB.6070400@tomt.net> References: <16991.54602.218744.163816@robur.slu.se> <425FFA54.9070106@tomt.net> <16992.48513.102876.620927@robur.slu.se> <4260D2EB.6070400@tomt.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1818 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: 2107 Lines: 55 Andre Tomt writes: > > 168 kpps vs 316 kpps on this box so quite substantial improvement and if > > you can merge local and main table you get even more. Well to honest we > > can merge tables do this current FIB too. > If its not too much trouble I would apriciate it. Well we get into FIB details we have to be careful with numbers as looking up different prefixes is quite different. I.e if the matching route is /32 we find in the first zone compare to if we have to search through all zones to match /0 at last. HASH2 has other worst cases. So the rDoS numbers may be more useful... Anyway to bomb you with numbers FIB/24 313 kpps FIB/0 264 kpps HASH2/24 305 kpps HASH2/0 296 kpps local and main are not merged. FIB 123 kroutes Single flow at 880 kpps we match /24 prefix --- T-put 313 kpps Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3564282 8405409 8405409 6435718 5 0 0 0 BRU eth1 1500 0 6 0 0 0 3564294 0 0 0 BRU FIB 123 kroutes single flow at 880 kpps we match /0 prefix --- T-put 264 kpps Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 2676826 8789144 8789144 7323321 95 0 0 0 BRU eth1 1500 0 4 0 0 0 2676688 0 0 0 BRU -------------------------------------------------------------------------------- HASH2 123kroutes single flow at 880 kpps we match /24 prefix --- T-put 305 kpps Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3470186 8453021 8453021 6529814 5 0 0 0 BRU eth1 1500 0 4 0 0 0 3470195 0 0 0 BRU HASH2 123kroutes single flow at 880 kpps we match /0 prefix --- T-put 296 kpps Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3373610 8479473 8479473 6626522 96 0 0 0 BRU eth1 1500 0 4 0 0 0 3373487 0 0 0 BRU Cheers. --ro From pbellino@mrv.com Mon Apr 18 09:42:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 09:42:21 -0700 (PDT) Received: from mailman.xyplex.com (mailman.xyplex.com [140.179.176.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IGgEZF013106 for ; Mon, 18 Apr 2005 09:42:15 -0700 Received: from ltnmail.xyplex.com (ltnmail.xyplex.com [140.179.176.25]) by mailman.xyplex.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29972 for ; Mon, 18 Apr 2005 12:42:45 -0400 (EDT) Received: by ltnmail.xyplex.com with Internet Mail Service (5.5.2653.19) id <29LJP2WD>; Mon, 18 Apr 2005 12:27:38 -0400 Message-ID: <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> From: "Bellino, Phil" To: netdev@oss.sgi.com Subject: 2.6.11 kernel, PPC, and IPv6 Date: Mon, 18 Apr 2005 12:27:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pbellino@mrv.com Precedence: bulk X-list: netdev Content-Length: 1213 Lines: 36 > Hello, > I do not know if this email is appropriate for this mailing list, but I > thought I would give it a try. > > Is there anyone out there who is using(or attempting to use) IPv6 with > PowerPC and a 2.6.11 kernel with whom I could email directly with some > specific questions? > > One of my questions is at boot time, my eth0 device does not have it's > link-local address. I must issue an "ifconfig eth0 down" and then an > "ifconfig eth0 up" to get this work work. > > Also, it does not auto-configure the info for a link-global prefix/address > that is provided by the router announcements. > > There are PCs in my network on i686 athlons, i386 running 2.6.5 kernels > that do in fact handle the above IPv6 correctly. > > I do understand that there are IPv6 mailing list and I do belong to them, > but thus far no one has been able to assist me in these issues. > > I apologize if this is not the correct forum for these types of questions. > > Thank you, > Phil Bellino > > ============================ > Phil Bellino > MRV Communications, Inc. > Boston Product Division > 295 Foster St. > Littleton,MA 01460 > Tel: (978)952-4807 > Email: pbellino@mrv.com > ============================ > From akepner@sgi.com Mon Apr 18 09:57:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 09:57:41 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IGvWm1014199 for ; Mon, 18 Apr 2005 09:57:32 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j3IIbLVI017420 for ; Mon, 18 Apr 2005 11:37:31 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-49.corp.sgi.com [134.15.0.49]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3IGualV15739636; Mon, 18 Apr 2005 09:56:38 -0700 (PDT) Date: Mon, 18 Apr 2005 09:55:40 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "Brandeburg, Jesse" cc: netdev@oss.sgi.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 1234 Lines: 36 On Sun, 17 Apr 2005, Brandeburg, Jesse wrote: > ...... > _conclusion_ > > Is there any way we can configure how soon or often to be polled > (called)? For 100Mb speeds at worst we can get about one 64 byte packet > every 9us (if I did my math right) and since the processors don't take > that long to schedule NAPI, process a packet and handle an interrupt, we > just overload the system with interrupts going into and out of napi > mode. In this case I only have one adapter getting scheduled. > I'll just chime in to say that I've seen similar behavior, (but with a very different system.) The problem with NAPI is (quoting a co-worker) that it relies on an "accident of timing". If the CPU speed, time to complete a PIO, and the inter- packet arrival time are "just so", then a system (or at least one of its CPUs) can be kept very busy even when it's not receiving data from the network at a particularly high rate. The simple feedback mechanism used by NAPI is good at balancing latency and throughput, but it doesn't have any way of recognizing when system resources are being poorly utilized. It would be nice if interrupt coalesence could be used by NAPI (or maybe by NAPI_2 ?) in this sort of situation. -- Arthur From ralf@linux-mips.org Mon Apr 18 10:10:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 10:10:31 -0700 (PDT) Received: from ftp.linux-mips.org (mail.linux-mips.org [62.254.210.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IHAQAc015239 for ; Mon, 18 Apr 2005 10:10:27 -0700 Received: (from localhost user: 'ralf' uid#501 fake: STDIN (ralf@semper-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org id ; Mon, 18 Apr 2005 18:10:24 +0100 Date: Mon, 18 Apr 2005 18:10:24 +0100 From: Ralf Baechle To: netdev@oss.sgi.com Subject: ADMIN: Netdev downtime Message-ID: <20050418171024.GA13894@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 152 Lines: 5 Tomorrow around 8:00 UTC we're planning to replace the hardware of oss.sgi.com with a new machine which will result in a few hours of downtime. Ralf From yoshfuji@linux-ipv6.org Mon Apr 18 10:12:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 10:12:31 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IHCP1P015700 for ; Mon, 18 Apr 2005 10:12:26 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 92B8233CC2; Tue, 19 Apr 2005 02:14:47 +0900 (JST) Date: Tue, 19 Apr 2005 02:14:41 +0900 (JST) Message-Id: <20050419.021441.50994203.yoshfuji@linux-ipv6.org> To: pbellino@mrv.com Cc: netdev@oss.sgi.com Subject: Re: 2.6.11 kernel, PPC, and IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> References: <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> 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-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1822 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: 778 Lines: 17 In article <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> (at Mon, 18 Apr 2005 12:27:31 -0400), "Bellino, Phil" says: > > Is there anyone out there who is using(or attempting to use) IPv6 with > > PowerPC and a 2.6.11 kernel with whom I could email directly with some > > specific questions? > > > > One of my questions is at boot time, my eth0 device does not have it's > > link-local address. I must issue an "ifconfig eth0 down" and then an > > "ifconfig eth0 up" to get this work work. > > > > Also, it does not auto-configure the info for a link-global prefix/address > > that is provided by the router announcements. 2.6.12-rcs seem to work fine on my x86 and ultrasparc at least. I'm trying to build on my ppc as well. --yoshfuji From lark@linux.net.cn Mon Apr 18 11:01:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 11:01:45 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3II1RZb022294 for ; Mon, 18 Apr 2005 11:01:29 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 94F013F866; Tue, 19 Apr 2005 02:01:26 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 27572-03-3; Tue, 19 Apr 2005 02:01:21 +0800 (CST) Received: from [192.168.0.120] (unknown [61.48.104.234]) by mx.linux.net.cn (Postfix) with ESMTP id 7CA483F787; Tue, 19 Apr 2005 02:01:21 +0800 (CST) Date: Tue, 19 Apr 2005 02:01:21 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Cc: jamal , netdev In-Reply-To: <20050418145024.GS4114@postel.suug.ch> References: <1113830063.26757.15.camel@localhost.localdomain> <20050418145024.GS4114@postel.suug.ch> Message-Id: <20050419012147.038F.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 1823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 7313 Lines: 198 Hi Thomas Graf, In your big piture, 1. the dynamic allocated classids prepresent streams (I avoid using flow here ntentionally) 2. the dynamic created TBFs are mapped 1:1 to classids, to provide rate control Let's simplify it to 1. namespace represent streams 2. rate controls for every name in the namespace (1:1 map) The consideration: 1. there is no necessity that namespace must be classid space. 2. considering the resemblance of streams (they usually are the same application), the rate control can be simplified. TBF or HTB is overkill. 3. grouped rate control method is not suitable for single stream. 4. fairness on streams, and total guarantee ( rate * n) can guarantee n streams very well 5. per stream rate limit and total limit ( rate * n * 1.xx ) make sense for bandwidth efficiency. 6. precisely counting of streams is necessary (when streams is more than expected, existing streams are guaranteed, new streams are not guaranteed, so at least some will work, not all don't work) What FRG does: 1. the namespace is conntracks of streams; 2. rate control algorithm is very simple, based on the token bucket; 3. grouped rate control (HTB) is only used to do total guarantee 4. provides fairness on streams, and there is m * rate guarantee for dynamic m streams; 5. per stream rate limit, total limit ( rate * max_streams * 1.05) 6. precisely counting of streams, and guarantees existing max_streams stream. FRG is created for VoIP like applications. It can be used to meet per stream guarantee and prevent over provision. On Mon, 18 Apr 2005 16:50:24 +0200, Thomas Graf wrote: > Sorry for entering this discussion so late. > > * jamal <1113830063.26757.15.camel@localhost.localdomain> 2005-04-18 09:14 > > I think you should start by decoupling the classification away from your > > qdisc. > > Here are my thoughts on per flow queueing, actually the name > "classification controlled queues" is be more accurate. > > First of all the whole problem must be divided into two parts: > > 1) queueing with per flow specific queueing parameters, i.e. the flow > serves a certain purpose and is known by static parameters. > 2) queueing with generic parameters, i.e. the purpose of a flow > is solely to be fair, there is no difference between each flow. > > Both these cases can be handled with the current set of qdiscs > and classificiation tools but often a combination of both is needed > and that's where my thought begins: > > We use tc_classid to describe a flow but also to describe its > assignment to the corresponding flow group (n flows are grouped > together into a group to define a namespace, generally at the > level of a qdisc). > > The tc_classid can be set via actions, either by using a generic > action that creates a flowid out of the common tuple or by > providing an own simple-action for customization, e.g. one could > construct tc_classid ::= nfmark << 16 + hash(flowid) > > tc_classid is interpreted by either one of the existing qdiscs > for static assignment or a new qdisc named "alloctor" > > The purpose of the allocator is to create qdiscs on demand, > destroy them after they expired and to act as a muxer to enqueue > into the dynamic leaf qdiscs. The alloactor can be configured to > interpet the MSB 16bits of tc_classid as a flow group id and > enqueue the skb to the corresponding clasfull qdisc with matches > TC_H_MAJ_MASK bits. > > The following is in attempt to convert my scribbling on paper > into ASCII: > > > Use Case 1: Per flow queues using TBF > > 2. +-----------+ +------------+ > +->| cls_basic |->| act_flowid | > | +-----------+ +------------+ > 1. +---------------+ | > --------->| sch_allocator |<-------------+ > +---------------+ 3. tc_classid= > |4. > +-----------+---------+- - - - - - > | | | | > +-----+ +-----+ +-----+ + - - + > | TBF | | TBF | | TBF | | TBF | > +-----+ +-----+ +-----+ + - - + > > > sch_alloctor configuration: > - no flow group map > - default policy: allocate TBF for every tc_classid && enqueue to new qdisc > - default template: tbf add rtnetlink message > - default deletion template: tbf del rtnetlink message > > cls_basic configuration: > - always true > > act_flowid configuration: > - default: generate flowid hash and store in tc_classid > > > Use Case 2: Flow groups > > 3. +---------+ > +->| em_meta | > | +---------+ > +----+ | > | v 4. > 2. +-----------+ +-----------------+ > +->| cls_basic |->| act_cust_flowid | > | +-----------+ +-----------------+ > 1. +-----------------+ | > --------->| sch_allocator_1 |<--------------+ > +-----------------+ 5. tc_classid=(nfmark<<16)+(flowid&0xFF) > |6. > +-----------+---+----------------+ > | 11:/12: | 13: | *: > +-----+ +-----------------+ +---------+ > | HTB | | sch_allocator_2 | | default | > +-----+ +-----------------+ +---------+ > | | > | +-------+- - - - > | | | | > | +-----+ +-----+ + - - + > | | TBF | | TBF | | TBF | > | +-----+ +-----+ + - - + > | > | > +------------------+ > | > +----------+--------------+ > | | > +------------+ +------------+ > | Class 20:1 | | Class 20:2 | > +------------+ +------------+ > | | > +---------+- - - - - ..... > | | | > +-------+ +-------+ +- - - -+ > | Class | | Class | | Class | > +-------+ +-------+ +- - - -+ > > > sch_alloctor_1 configuration: > - flow group map: > [11:] create class HTB parent 20:1 && enqueue to 20: > [12:] create class HTB parent 20:2 && enqueue to 20: > [13:] enqueue to sch_allocator_2 > - default policy: enqueue to default qdisc > > sch_allocator_2 configuration: > - no flow group map > - default policy: allocate TBF for every tc_classid && enqueue to new qdisc > - default template: tbf add rtnetlink message > - default deletion template: tbf del rtnetlink message > > cls_basic configuration: > - always true > > em_meta configuration: > - filter out unknown nfmarks > > act_cust_flowid configuration: > - (nfmark<<16)+(flowid&0xff) > > > So basically what sch_allocator does is look at tc_classid, lookup > the corresponding flow in the flow map or use the default action, > execute the action, i.e. process the netlink message via a worker > thread, rewrite tc_classid if needed, manage the created qdiscs/classes, > account their last activity and destroy them eventually after no > activity for a certain configurable time by executing the corresponding > deletion netlink message. > > Thoughts? -- lark From masouds@masoud.ir Mon Apr 18 11:04:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 11:04:05 -0700 (PDT) Received: from deimos.masoud.ir (CPE000625dddb50-CM000a73996061.cpe.net.cable.rogers.com [70.28.15.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3II3wcN022970 for ; Mon, 18 Apr 2005 11:04:00 -0700 Received: from masouds1.oeone.com (firewall.oeone.com [216.191.248.101]) (authenticated bits=0) by deimos.masoud.ir (8.13.4/8.13.3) with ESMTP id j3II3pO0029840 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 18 Apr 2005 14:03:52 -0400 (EDT) Subject: Re: Does a forwarded packet has a local socket with it? From: Masoud Sharbiani Reply-To: masouds@masoud.ir To: Park Lee Cc: jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20050418140348.33642.qmail@web51509.mail.yahoo.com> References: <20050418140348.33642.qmail@web51509.mail.yahoo.com> Content-Type: text/plain Date: Mon, 18 Apr 2005 14:06:15 -0400 Message-Id: <1113847575.19942.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: masouds@masoud.ir Precedence: bulk X-list: netdev Content-Length: 659 Lines: 32 On Mon, 2005-04-18 at 07:03 -0700, Park Lee wrote: > On Mon, 18 Apr 2005 at 08:03, jamal wrote: > > simple answer: no > > Thank you very much. > > Still, Does a forwarded packet also have no any kernel > socket with it? i.e. Is a forwarded packet not > associated with any socket at all? > No. > When the forwarded packet arrived at its destination > machine, is there any socket associated with the > packet on the destination machine? It better be :-) Otherwise, it could be ignored or just refused (as in connection refused). > > Thanks again. > > Best Regards, > Park Lee > > > cheers, Masoud -- Masoud Sharbiani From nhorman@redhat.com Mon Apr 18 11:04:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 11:04:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3II45ln022999 for ; Mon, 18 Apr 2005 11:04:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3II43Uf009894; Mon, 18 Apr 2005 14:04:03 -0400 Received: from hmsendeavour.rdu.redhat.com (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3II43O26593; Mon, 18 Apr 2005 14:04:03 -0400 Received: from hmsendeavour.rdu.redhat.com (localhost.localdomain [127.0.0.1]) by hmsendeavour.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id j3II43Jd003789; Mon, 18 Apr 2005 14:04:03 -0400 Received: (from nhorman@localhost) by hmsendeavour.rdu.redhat.com (8.13.1/8.13.1/Submit) id j3II436f003788; Mon, 18 Apr 2005 14:04:03 -0400 Date: Mon, 18 Apr 2005 14:04:03 -0400 From: Neil Horman To: Park Lee Cc: jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Does a forwarded packet has a local socket with it? Message-ID: <20050418180403.GD31824@hmsendeavour.rdu.redhat.com> References: <20050418140348.33642.qmail@web51509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050418140348.33642.qmail@web51509.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 43 On Mon, Apr 18, 2005 at 07:03:47AM -0700, Park Lee wrote: > On Mon, 18 Apr 2005 at 08:03, jamal wrote: > > simple answer: no > > Thank you very much. > > Still, Does a forwarded packet also have no any kernel > socket with it? i.e. Is a forwarded packet not > associated with any socket at all? Not on the fowarding machine, no. There is no need for a socket, since a socket just defines an endpoint for a connection, or a data source or sink. A device that forwards a packet has no need to define a socket, since its not sourcing or sinking data, its just forwarding it. > > When the forwarded packet arrived at its destination > machine, is there any socket associated with the > packet on the destination machine? > Sure, at the originating host, and at the receiving host. Neil > Thanks again. > > Best Regards, > Park Lee > > > > __________________________________ > Do you Yahoo!? > Plan great trips with Yahoo! Travel: Now over 17,000 guides! > http://travel.yahoo.com/p-travelguide > -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From tgraf@suug.ch Mon Apr 18 11:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 11:40:28 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IIeHJ7025376 for ; Mon, 18 Apr 2005 11:40:18 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id E97AB1C0EB; Mon, 18 Apr 2005 20:40:29 +0200 (CEST) Date: Mon, 18 Apr 2005 20:40:29 +0200 From: Thomas Graf To: Wang Jian Cc: jamal , netdev Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Message-ID: <20050418184029.GV4114@postel.suug.ch> References: <1113830063.26757.15.camel@localhost.localdomain> <20050418145024.GS4114@postel.suug.ch> <20050419012147.038F.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419012147.038F.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3608 Lines: 101 * Wang Jian <20050419012147.038F.LARK@linux.net.cn> 2005-04-19 02:01 > In your big piture, > > 1. the dynamic allocated classids prepresent streams (I avoid using flow > here ntentionally) > 2. the dynamic created TBFs are mapped 1:1 to classids, to provide rate > control > > Let's simplify it to > > 1. namespace represent streams > 2. rate controls for every name in the namespace (1:1 map) This is only true for use 1 where the allocator creates indepdendent qdiscs. Look at use case 2 where a major classid of 11: and 12: create htb class siblings, this even allows to divided one big flow namespaces into various group but still respecting global policies. > 1. there is no necessity that namespace must be classid space. Agreed. > 2. considering the resemblance of streams (they usually are the same > application), the rate control can be simplified. TBF or HTB is overkill. Argueable. > 3. grouped rate control method is not suitable for single stream. I'm not sure what you mean with this. > 4. fairness on streams, and total guarantee ( rate * n) can guarantee n > streams very well Agreed, we can put this into the allocator by letting the user specify limits and run a rate estimator. > 5. per stream rate limit and total limit ( rate * n * 1.xx ) make sense > for bandwidth efficiency. Agreed, make the allocator create HTB classes and you can have it. > 6. precisely counting of streams is necessary (when streams is more than > expected, existing streams are guaranteed, new streams are not > guaranteed, so at least some will work, not all don't work) Also agreed, I did not lose too many thoughts on this yet but it's not hard to implement. > What FRG does: > > 1. the namespace is conntracks of streams; > 2. rate control algorithm is very simple, based on the token bucket; > 3. grouped rate control (HTB) is only used to do total guarantee > 4. provides fairness on streams, and there is m * rate guarantee for > dynamic m streams; > 5. per stream rate limit, total limit ( rate * max_streams * 1.05) > 6. precisely counting of streams, and guarantees existing max_streams > stream. I understand all of your arguments but I would like to, if possible, avoid to add yet another quite specific qdisc which could have been implemented in a generic way for everyone to use. Your FRG basically does what the alloctor + classifier + action + qdiscs can do but it is orientied at one specific use case. Let's analyze your enqueue() 1) perflow_is_valid() // BTW, I think you have a typo in there, 2 times TCP ;-> Should be done in the classifier with ematches: ... ematch meta(PROTOCOL eq IP) AND (cmp(ip_proto eq TCP) OR cmp(ip_proto eq UDP) ..) 2) perflow_(fill|find|new)_tuple() Should be done in the classifier as an action 3) qsch->q.qlen >= q->qlen Must be done in the qdisc after classification so this would go into the allocator. 4) flow->timer Must be handled by the alloctor 5) rate limiting IMHO: Should be done in separate qdiscs Advantages? - What happens if you want to allow yet another protocol in your flow? You have to change sources etc. - Protocol specific flow hashing? No problem, replace the action. - ... The only disadvantage I can see is a possible performance bottleneck but this must be proved first by numbers. So basically the direction we want to go is to strict separate the classification from the queueing to allow the user to customize everything by replacing small components. It might be worth to read up on the discussion on "ematch" and "action" over the last 3 months. Cheers, Thomas From Robert.Olsson@data.slu.se Mon Apr 18 12:34:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 12:35:02 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IJYuQe031751 for ; Mon, 18 Apr 2005 12:34:57 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3IJYn0h004680; Mon, 18 Apr 2005 21:34:50 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id E979EEE1F1; Mon, 18 Apr 2005 21:34:49 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.3033.886236.664281@robur.slu.se> Date: Mon, 18 Apr 2005 21:34:49 +0200 To: Arthur Kepner Cc: "Brandeburg, Jesse" , netdev@oss.sgi.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1827 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: 1561 Lines: 41 Arthur Kepner writes: > > On Sun, 17 Apr 2005, Brandeburg, Jesse wrote: > > > ...... > > _conclusion_ > > > > Is there any way we can configure how soon or often to be polled > > (called)? For 100Mb speeds at worst we can get about one 64 byte packet > > every 9us (if I did my math right) and since the processors don't take > > that long to schedule NAPI, process a packet and handle an interrupt, we > > just overload the system with interrupts going into and out of napi > > mode. In this case I only have one adapter getting scheduled. > > > > I'll just chime in to say that I've seen similar behavior, > (but with a very different system.) > > The problem with NAPI is (quoting a co-worker) that it > relies on an "accident of timing". > > If the CPU speed, time to complete a PIO, and the inter- > packet arrival time are "just so", then a system (or at > least one of its CPUs) can be kept very busy even when > it's not receiving data from the network at a particularly > high rate. > > The simple feedback mechanism used by NAPI is good at > balancing latency and throughput, but it doesn't have > any way of recognizing when system resources are being > poorly utilized. It would be nice if interrupt coalesence > could be used by NAPI (or maybe by NAPI_2 ?) in this sort > of situation. Well there is nothing that prohibits interrupt coalescing use with NAPI as is. Matter of there are many drivers using this i.e e1000 and tulip. You trade latency for more packets per interrupt. Cheers. --ro From hadi@cyberus.ca Mon Apr 18 13:26:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 13:26:21 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IKQFX0002034 for ; Mon, 18 Apr 2005 13:26:15 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DNcoq-0002Vt-46 for netdev@oss.sgi.com; Mon, 18 Apr 2005 14:26:08 -0600 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DNcot-0006EI-82; Mon, 18 Apr 2005 16:26:11 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Arthur Kepner Cc: "Brandeburg, Jesse" , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: unknown Date: Mon, 18 Apr 2005 16:26:07 -0400 Message-Id: <1113855967.7436.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1828 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: 2615 Lines: 68 On Mon, 2005-18-04 at 09:55 -0700, Arthur Kepner wrote: > On Sun, 17 Apr 2005, Brandeburg, Jesse wrote: > > > ...... > > _conclusion_ > > > > Is there any way we can configure how soon or often to be polled > > (called)? For 100Mb speeds at worst we can get about one 64 byte packet > > every 9us (if I did my math right) and since the processors don't take > > that long to schedule NAPI, process a packet and handle an interrupt, we > > just overload the system with interrupts going into and out of napi > > mode. In this case I only have one adapter getting scheduled. > > > > I'll just chime in to say that I've seen similar behavior, > (but with a very different system.) > It would _help_ a great deal if people collect data and post. What was this other system? Was it running e100 as well? etc etc > The problem with NAPI is (quoting a co-worker) that it > relies on an "accident of timing". > geez, that almost sounds like an insult. spank your coworker for me with something sharp (i hope s/he doesnt enjoy it) > If the CPU speed, time to complete a PIO, and the inter- > packet arrival time are "just so", then a system (or at > least one of its CPUs) can be kept very busy even when > it's not receiving data from the network at a particularly > high rate. > again, it would help if you actually provided data - this sounds like hand waving to me. The only known thing we are aware of is that if you have slow PIO at low packet rates you will chew more CPU - the reason is simple: if you do 1 packet per interupt you will have one more IO per packet than if you didnt use NAPI; at about 2.5 packets or so you start benefiting from the amortization of IO. This issue has been discussed many many times at netdev. There has been no good reason thus far to complicate things by "fixing" it. Go to MSI capable NICs if you are really concerned. > The simple feedback mechanism used by NAPI is good at > balancing latency and throughput, but it doesn't have > any way of recognizing when system resources are being > poorly utilized. How do you recognize when system resources are being poorly utilized? If you know the answer to that then you need to fix things at the softirq scheduling level - not at NAPI (that would be the wrong spot) > It would be nice if interrupt coalesence > could be used by NAPI (or maybe by NAPI_2 ?) in this sort > of situation. > You can add coalescing as is doable by e1000 for example - but that shouldnt solve the problem you allude to - that of "system resources are being poorly utilized" . cheers, jamal PS:- if you want to help please post data. From greearb@candelatech.com Mon Apr 18 14:37:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 14:37:31 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ILbNvu005649 for ; Mon, 18 Apr 2005 14:37:23 -0700 Received: from [71.112.202.130] (pool-71-112-202-130.sttlwa.dsl-w.verizon.net [71.112.202.130]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3IM5NGf028732 for ; Mon, 18 Apr 2005 15:05:24 -0700 Message-ID: <42642892.2040300@candelatech.com> Date: Mon, 18 Apr 2005 14:37:22 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: local_bh_enable & hard_start_xmit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1829 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: 1598 Lines: 51 This pertains to kernel 2.6.11. I seem to have backed myself into a corner with network devices and locking...again. I have a thread that grabs a read lock with read_lock_irqsave, loops through a list, making calls to dev->hard_start_xmit. Before today, I was not messing with local_bh_enable/disable, and I was seeing badness messages due to this call path: Badness in local_bh_enable at kernel/softirq.c:140 [] local_bh_enable+0x92/0xa0 [] dev_queue_xmit+0x165/0x280 [] get_offset_pmtmr+0x14/0xcb0 [] vlan_dev_hwaccel_hard_start_xmit+0x62/0x70 [8021q] [] do_task+0x642/0x61e0 [wanlink] ... The warning is due to this line: void local_bh_enable(void) { WARN_ON(irqs_disabled()); So, I decided to wrap my calls to dev->hard_start_xmit with local_bh_disable/enable. That does not actually fix my problem because I still have the read-lock acquired. I am going to try putting the disable/enable outside of that, but then I will be potentially disabling the bh for a long time. So, two questions: 1) Why is it bad to have interrupts disabled when calling the local_bh_enable() method? 2) Should there be a hard requirement that one must never have IRQs disabled when calling dev->hard_start_xmit (this requirement seems to currently be in effect because VLANs can call dev_queue_xmit from their hard_start_xmit method, and it appears that dev_queue_xmit must not be called with IRQs disabled). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bunk@stusta.de Mon Apr 18 14:44:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 14:44:30 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3ILiKm5006426 for ; Mon, 18 Apr 2005 14:44:20 -0700 Received: (qmail 32231 invoked from network); 18 Apr 2005 21:44:14 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 18 Apr 2005 21:44:14 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 82754BB564; Mon, 18 Apr 2005 23:44:13 +0200 (CEST) Date: Mon, 18 Apr 2005 23:44:13 +0200 From: Adrian Bunk To: Alan Cox Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: [2.6 patch] drivers/net/wan/: possible cleanups Message-ID: <20050418214413.GD5489@stusta.de> References: <20050327143418.GE4285@stusta.de> <1111941516.14877.325.camel@localhost.localdomain> <20050414232028.GD20400@stusta.de> <1113587392.11155.33.camel@localhost.localdomain> <20050417234738.GY3625@stusta.de> <1113828904.17058.21.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113828904.17058.21.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 30701 Lines: 977 On Mon, Apr 18, 2005 at 01:55:06PM +0100, Alan Cox wrote: > On Llu, 2005-04-18 at 00:47, Adrian Bunk wrote: > > Are there any external drivers using these exports, and if there are, > > why aren't they in the kernel? > > Its a standard API > > > If there aren't and someone will at some time in the future need them, > > re-adding the exports will be trivial. > > Really, you will spotaneously magically make them appear in old kernels > that end users have just like that ? > > Your argument doesn't hold water. Its an API for drivers so that people > can add 85x30 card drivers using DMA in this fashion. Its an API so they > can add them to *EXISTING* kernels without users being forced to > recompile/wait for the vendor to update their tree/upgrade to a new > release. OK, updated patch below. > Alan cu Adrian <-- snip --> This patch contains possible cleanups including the following: - make needlessly global code static - #if 0 the following unused global function: - sdladrv.c: sdla_intde - remove the following unused global variable: - lmc_media.c: lmc_t1_cables - remove the following unneeded EXPORT_SYMBOL's: - cycx_drv.c: cycx_inten - sdladrv.c: sdla_inten - sdladrv.c: sdla_intde - sdladrv.c: sdla_intack - sdladrv.c: sdla_intr - syncppp.c: sppp_input - syncppp.c: sppp_change_mtu Signed-off-by: Adrian Bunk --- drivers/net/wan/cycx_drv.c | 7 +- drivers/net/wan/cycx_main.c | 2 drivers/net/wan/dscc4.c | 14 ++--- drivers/net/wan/farsync.c | 24 ++++---- drivers/net/wan/hdlc_fr.c | 2 drivers/net/wan/lmc/lmc_debug.c | 10 +-- drivers/net/wan/lmc/lmc_media.c | 8 -- drivers/net/wan/pc300.h | 16 ----- drivers/net/wan/pc300_drv.c | 87 ++++++++++++++++---------------- drivers/net/wan/pc300_tty.c | 18 +++--- drivers/net/wan/sdla.c | 20 +++---- drivers/net/wan/sdladrv.c | 16 ++--- drivers/net/wan/syncppp.c | 10 +-- include/linux/cycx_drv.h | 1 include/linux/sdladrv.h | 4 - include/net/syncppp.h | 1 16 files changed, 101 insertions(+), 139 deletions(-) --- linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h.old 2005-02-16 19:14:39.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h 2005-02-16 19:14:46.000000000 +0100 @@ -60,6 +60,5 @@ extern int cycx_poke(struct cycx_hw *hw, u32 addr, void *buf, u32 len); extern int cycx_exec(void __iomem *addr); -extern void cycx_inten(struct cycx_hw *hw); extern void cycx_intr(struct cycx_hw *hw); #endif /* _CYCX_DRV_H */ --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c.old 2005-02-16 19:14:55.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c 2005-02-16 19:15:35.000000000 +0100 @@ -110,7 +110,7 @@ * < 0 error. * Context: process */ -int __init cycx_drv_init(void) +static int __init cycx_drv_init(void) { printk(KERN_INFO "%s v%u.%u %s\n", fullname, MOD_VERSION, MOD_RELEASE, copyright); @@ -120,7 +120,7 @@ /* Module 'remove' entry point. * o release all remaining system resources */ -void cycx_drv_cleanup(void) +static void cycx_drv_cleanup(void) { } @@ -185,8 +185,7 @@ } /* Enable interrupt generation. */ -EXPORT_SYMBOL(cycx_inten); -void cycx_inten(struct cycx_hw *hw) +static void cycx_inten(struct cycx_hw *hw) { writeb(0, hw->dpmbase); } --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c.old 2005-02-16 19:46:47.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c 2005-02-16 19:47:00.000000000 +0100 @@ -103,7 +103,7 @@ * < 0 error. * Context: process */ -int __init cycx_init(void) +static int __init cycx_init(void) { int cnt, err = -ENOMEM; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c.old 2005-02-16 23:57:37.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c 2005-02-17 00:00:26.000000000 +0100 @@ -74,11 +74,11 @@ /* * Modules parameters and associated varaibles */ -int fst_txq_low = FST_LOW_WATER_MARK; -int fst_txq_high = FST_HIGH_WATER_MARK; -int fst_max_reads = 7; -int fst_excluded_cards = 0; -int fst_excluded_list[FST_MAX_CARDS]; +static int fst_txq_low = FST_LOW_WATER_MARK; +static int fst_txq_high = FST_HIGH_WATER_MARK; +static int fst_max_reads = 7; +static int fst_excluded_cards = 0; +static int fst_excluded_list[FST_MAX_CARDS]; module_param(fst_txq_low, int, 0); module_param(fst_txq_high, int, 0); @@ -572,13 +572,13 @@ static void fst_process_tx_work_q(unsigned long work_q); static void fst_process_int_work_q(unsigned long work_q); -DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0); -DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0); +static DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0); +static DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0); -struct fst_card_info *fst_card_array[FST_MAX_CARDS]; -spinlock_t fst_work_q_lock; -u64 fst_work_txq; -u64 fst_work_intq; +static struct fst_card_info *fst_card_array[FST_MAX_CARDS]; +static spinlock_t fst_work_q_lock; +static u64 fst_work_txq; +static u64 fst_work_intq; static void fst_q_work_item(u64 * queue, int card_index) @@ -1498,7 +1498,7 @@ * The interrupt service routine * Dev_id is our fst_card_info pointer */ -irqreturn_t +static irqreturn_t fst_intr(int irq, void *dev_id, struct pt_regs *regs) { struct fst_card_info *card; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c.old 2005-02-17 00:00:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c 2005-02-17 00:00:46.000000000 +0100 @@ -347,7 +347,7 @@ -int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { pvc_device *pvc = dev_to_pvc(dev); fr_proto_pvc_info info; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c.old 2005-02-17 00:02:29.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c 2005-02-17 00:02:47.000000000 +0100 @@ -48,14 +48,6 @@ */ /* - * For lack of a better place, put the SSI cable stuff here. - */ -char *lmc_t1_cables[] = { - "V.10/RS423", "EIA530A", "reserved", "X.21", "V.35", - "EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL -}; - -/* * protocol independent method. */ static void lmc_set_protocol (lmc_softc_t * const, lmc_ctl_t *); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h.old 2005-02-17 00:03:07.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h 2005-02-17 00:55:23.000000000 +0100 @@ -472,24 +472,8 @@ #ifdef __KERNEL__ /* Function Prototypes */ -int dma_buf_write(pc300_t *, int, ucchar *, int); -int dma_buf_read(pc300_t *, int, struct sk_buff *); void tx_dma_start(pc300_t *, int); -void rx_dma_start(pc300_t *, int); -void tx_dma_stop(pc300_t *, int); -void rx_dma_stop(pc300_t *, int); -int cpc_queue_xmit(struct sk_buff *, struct net_device *); -void cpc_net_rx(struct net_device *); -void cpc_sca_status(pc300_t *, int); -int cpc_change_mtu(struct net_device *, int); -int cpc_ioctl(struct net_device *, struct ifreq *, int); -int ch_config(pc300dev_t *); -int rx_config(pc300dev_t *); -int tx_config(pc300dev_t *); -void cpc_opench(pc300dev_t *); -void cpc_closech(pc300dev_t *); int cpc_open(struct net_device *dev); -int cpc_close(struct net_device *dev); int cpc_set_media(hdlc_device *, int); #endif /* __KERNEL__ */ --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c.old 2005-02-17 00:03:20.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c 2005-02-17 00:14:10.000000000 +0100 @@ -291,6 +291,7 @@ static void plx_init(pc300_t *); static void cpc_trace(struct net_device *, struct sk_buff *, char); static int cpc_attach(struct net_device *, unsigned short, unsigned short); +static int cpc_close(struct net_device *dev); #ifdef CONFIG_PC300_MLPPP void cpc_tty_init(pc300dev_t * dev); @@ -437,7 +438,7 @@ printk("\n"); } -int dma_get_rx_frame_size(pc300_t * card, int ch) +static int dma_get_rx_frame_size(pc300_t * card, int ch) { volatile pcsca_bd_t __iomem *ptdescr; ucshort first_bd = card->chan[ch].rx_first_bd; @@ -462,7 +463,7 @@ * dma_buf_write: writes a frame to the Tx DMA buffers * NOTE: this function writes one frame at a time. */ -int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len) +static int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len) { int i, nchar; volatile pcsca_bd_t __iomem *ptdescr; @@ -503,7 +504,7 @@ * dma_buf_read: reads a frame from the Rx DMA buffers * NOTE: this function reads one frame at a time. */ -int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb) +static int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb) { int nchar; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -560,7 +561,7 @@ return (rcvd); } -void tx_dma_stop(pc300_t * card, int ch) +static void tx_dma_stop(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; ucchar drr_ena_bit = 1 << (5 + 2 * ch); @@ -571,7 +572,7 @@ cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit); } -void rx_dma_stop(pc300_t * card, int ch) +static void rx_dma_stop(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; ucchar drr_ena_bit = 1 << (4 + 2 * ch); @@ -582,7 +583,7 @@ cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit); } -void rx_dma_start(pc300_t * card, int ch) +static void rx_dma_start(pc300_t * card, int ch) { void __iomem *scabase = card->hw.scabase; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -607,7 +608,7 @@ /*************************/ /*** FALC Routines ***/ /*************************/ -void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd) +static void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd) { void __iomem *falcbase = card->hw.falcbase; unsigned long i = 0; @@ -622,7 +623,7 @@ cpc_writeb(falcbase + F_REG(CMDR, ch), cmd); } -void falc_intr_enable(pc300_t * card, int ch) +static void falc_intr_enable(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -672,7 +673,7 @@ } } -void falc_open_timeslot(pc300_t * card, int ch, int timeslot) +static void falc_open_timeslot(pc300_t * card, int ch, int timeslot) { void __iomem *falcbase = card->hw.falcbase; ucchar tshf = card->chan[ch].falc.offset; @@ -688,7 +689,7 @@ (0x80 >> (timeslot & 0x07))); } -void falc_close_timeslot(pc300_t * card, int ch, int timeslot) +static void falc_close_timeslot(pc300_t * card, int ch, int timeslot) { void __iomem *falcbase = card->hw.falcbase; ucchar tshf = card->chan[ch].falc.offset; @@ -704,7 +705,7 @@ ~(0x80 >> (timeslot & 0x07))); } -void falc_close_all_timeslots(pc300_t * card, int ch) +static void falc_close_all_timeslots(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -726,7 +727,7 @@ } } -void falc_open_all_timeslots(pc300_t * card, int ch) +static void falc_open_all_timeslots(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -758,7 +759,7 @@ } } -void falc_init_timeslot(pc300_t * card, int ch) +static void falc_init_timeslot(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -776,7 +777,7 @@ } } -void falc_enable_comm(pc300_t * card, int ch) +static void falc_enable_comm(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -792,7 +793,7 @@ ~((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch))); } -void falc_disable_comm(pc300_t * card, int ch) +static void falc_disable_comm(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -806,7 +807,7 @@ ((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch))); } -void falc_init_t1(pc300_t * card, int ch) +static void falc_init_t1(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -975,7 +976,7 @@ falc_close_all_timeslots(card, ch); } -void falc_init_e1(pc300_t * card, int ch) +static void falc_init_e1(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1155,7 +1156,7 @@ falc_close_all_timeslots(card, ch); } -void falc_init_hdlc(pc300_t * card, int ch) +static void falc_init_hdlc(pc300_t * card, int ch) { void __iomem *falcbase = card->hw.falcbase; pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; @@ -1181,7 +1182,7 @@ falc_intr_enable(card, ch); } -void te_config(pc300_t * card, int ch) +static void te_config(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1241,7 +1242,7 @@ CPC_UNLOCK(card, flags); } -void falc_check_status(pc300_t * card, int ch, unsigned char frs0) +static void falc_check_status(pc300_t * card, int ch, unsigned char frs0) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1397,7 +1398,7 @@ } } -void falc_update_stats(pc300_t * card, int ch) +static void falc_update_stats(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1450,7 +1451,7 @@ * the synchronizer and then sent to the system interface. *---------------------------------------------------------------------------- */ -void falc_remote_loop(pc300_t * card, int ch, int loop_on) +static void falc_remote_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1495,7 +1496,7 @@ * coding must be identical. *---------------------------------------------------------------------------- */ -void falc_local_loop(pc300_t * card, int ch, int loop_on) +static void falc_local_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -1522,7 +1523,7 @@ * looped. They are originated by the FALC-LH transmitter. *---------------------------------------------------------------------------- */ -void falc_payload_loop(pc300_t * card, int ch, int loop_on) +static void falc_payload_loop(pc300_t * card, int ch, int loop_on) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1576,7 +1577,7 @@ * Description: Turns XLU bit off in the proper register *---------------------------------------------------------------------------- */ -void turn_off_xlu(pc300_t * card, int ch) +static void turn_off_xlu(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1597,7 +1598,7 @@ * Description: Turns XLD bit off in the proper register *---------------------------------------------------------------------------- */ -void turn_off_xld(pc300_t * card, int ch) +static void turn_off_xld(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1619,7 +1620,7 @@ * to generate a LOOP activation code over a T1/E1 line. *---------------------------------------------------------------------------- */ -void falc_generate_loop_up_code(pc300_t * card, int ch) +static void falc_generate_loop_up_code(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1652,7 +1653,7 @@ * to generate a LOOP deactivation code over a T1/E1 line. *---------------------------------------------------------------------------- */ -void falc_generate_loop_down_code(pc300_t * card, int ch) +static void falc_generate_loop_down_code(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1682,7 +1683,7 @@ * it on the reception side. *---------------------------------------------------------------------------- */ -void falc_pattern_test(pc300_t * card, int ch, unsigned int activate) +static void falc_pattern_test(pc300_t * card, int ch, unsigned int activate) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -1729,7 +1730,7 @@ * Description: This routine returns the bit error counter value *---------------------------------------------------------------------------- */ -ucshort falc_pattern_test_error(pc300_t * card, int ch) +static ucshort falc_pattern_test_error(pc300_t * card, int ch) { pc300ch_t *chan = (pc300ch_t *) & card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -1769,7 +1770,7 @@ netif_rx(skb); } -void cpc_tx_timeout(struct net_device *dev) +static void cpc_tx_timeout(struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -1797,7 +1798,7 @@ netif_wake_queue(dev); } -int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev) +static int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -1880,7 +1881,7 @@ return 0; } -void cpc_net_rx(struct net_device *dev) +static void cpc_net_rx(struct net_device *dev) { pc300dev_t *d = (pc300dev_t *) dev->priv; pc300ch_t *chan = (pc300ch_t *) d->chan; @@ -2403,7 +2404,7 @@ return IRQ_HANDLED; } -void cpc_sca_status(pc300_t * card, int ch) +static void cpc_sca_status(pc300_t * card, int ch) { ucchar ilar; void __iomem *scabase = card->hw.scabase; @@ -2495,7 +2496,7 @@ } } -void cpc_falc_status(pc300_t * card, int ch) +static void cpc_falc_status(pc300_t * card, int ch) { pc300ch_t *chan = &card->chan[ch]; falc_t *pfalc = (falc_t *) & chan->falc; @@ -2523,7 +2524,7 @@ CPC_UNLOCK(card, flags); } -int cpc_change_mtu(struct net_device *dev, int new_mtu) +static int cpc_change_mtu(struct net_device *dev, int new_mtu) { if ((new_mtu < 128) || (new_mtu > PC300_DEF_MTU)) return -EINVAL; @@ -2531,7 +2532,7 @@ return 0; } -int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { hdlc_device *hdlc = dev_to_hdlc(dev); pc300dev_t *d = (pc300dev_t *) dev->priv; @@ -2856,7 +2857,7 @@ } } -int ch_config(pc300dev_t * d) +static int ch_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300chconf_t *conf = (pc300chconf_t *) & chan->conf; @@ -3004,7 +3005,7 @@ return 0; } -int rx_config(pc300dev_t * d) +static int rx_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3035,7 +3036,7 @@ return 0; } -int tx_config(pc300dev_t * d) +static int tx_config(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3098,7 +3099,7 @@ return 0; } -void cpc_opench(pc300dev_t * d) +static void cpc_opench(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3116,7 +3117,7 @@ cpc_readb(scabase + M_REG(CTL, ch)) & ~(CTL_RTS | CTL_DTR)); } -void cpc_closech(pc300dev_t * d) +static void cpc_closech(pc300dev_t * d) { pc300ch_t *chan = (pc300ch_t *) d->chan; pc300_t *card = (pc300_t *) chan->card; @@ -3173,7 +3174,7 @@ return 0; } -int cpc_close(struct net_device *dev) +static int cpc_close(struct net_device *dev) { hdlc_device *hdlc = dev_to_hdlc(dev); pc300dev_t *d = (pc300dev_t *) dev->priv; --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c.old 2005-02-17 00:15:50.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c 2005-02-17 00:17:56.000000000 +0100 @@ -182,7 +182,7 @@ return(byte); } -void sdla_stop(struct net_device *dev) +static void sdla_stop(struct net_device *dev) { struct frad_local *flp; @@ -209,7 +209,7 @@ } } -void sdla_start(struct net_device *dev) +static void sdla_start(struct net_device *dev) { struct frad_local *flp; @@ -247,7 +247,7 @@ * ***************************************************/ -int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2) +static int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2) { unsigned long start, done, now; char resp, *temp; @@ -505,7 +505,7 @@ static int sdla_reconfig(struct net_device *dev); -int sdla_activate(struct net_device *slave, struct net_device *master) +static int sdla_activate(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -527,7 +527,7 @@ return(0); } -int sdla_deactivate(struct net_device *slave, struct net_device *master) +static int sdla_deactivate(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -549,7 +549,7 @@ return(0); } -int sdla_assoc(struct net_device *slave, struct net_device *master) +static int sdla_assoc(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -585,7 +585,7 @@ return(0); } -int sdla_deassoc(struct net_device *slave, struct net_device *master) +static int sdla_deassoc(struct net_device *slave, struct net_device *master) { struct frad_local *flp; int i; @@ -613,7 +613,7 @@ return(0); } -int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get) +static int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get) { struct frad_local *flp; struct dlci_local *dlp; @@ -1324,7 +1324,7 @@ return(0); } -int sdla_change_mtu(struct net_device *dev, int new_mtu) +static int sdla_change_mtu(struct net_device *dev, int new_mtu) { struct frad_local *flp; @@ -1337,7 +1337,7 @@ return(-EOPNOTSUPP); } -int sdla_set_config(struct net_device *dev, struct ifmap *map) +static int sdla_set_config(struct net_device *dev, struct ifmap *map) { struct frad_local *flp; int i; --- linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h.old 2005-02-17 00:18:15.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h 2005-02-17 00:19:47.000000000 +0100 @@ -52,12 +52,8 @@ extern int sdla_setup (sdlahw_t* hw, void* sfm, unsigned len); extern int sdla_down (sdlahw_t* hw); -extern int sdla_inten (sdlahw_t* hw); -extern int sdla_intde (sdlahw_t* hw); -extern int sdla_intack (sdlahw_t* hw); extern void S514_intack (sdlahw_t* hw, u32 int_status); extern void read_S514_int_stat (sdlahw_t* hw, u32* int_status); -extern int sdla_intr (sdlahw_t* hw); extern int sdla_mapmem (sdlahw_t* hw, unsigned long addr); extern int sdla_peek (sdlahw_t* hw, unsigned long addr, void* buf, unsigned len); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c.old 2005-02-17 00:18:30.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c 2005-02-17 00:20:04.000000000 +0100 @@ -642,9 +642,7 @@ * Enable interrupt generation. */ -EXPORT_SYMBOL(sdla_inten); - -int sdla_inten (sdlahw_t* hw) +static int sdla_inten (sdlahw_t* hw) { unsigned port = hw->port; int tmp, i; @@ -698,8 +696,7 @@ * Disable interrupt generation. */ -EXPORT_SYMBOL(sdla_intde); - +#if 0 int sdla_intde (sdlahw_t* hw) { unsigned port = hw->port; @@ -748,14 +745,13 @@ } return 0; } +#endif /* 0 */ /*============================================================================ * Acknowledge SDLA hardware interrupt. */ -EXPORT_SYMBOL(sdla_intack); - -int sdla_intack (sdlahw_t* hw) +static int sdla_intack (sdlahw_t* hw) { unsigned port = hw->port; int tmp; @@ -827,8 +823,7 @@ * Generate an interrupt to adapter's CPU. */ -EXPORT_SYMBOL(sdla_intr); - +#if 0 int sdla_intr (sdlahw_t* hw) { unsigned port = hw->port; @@ -863,6 +858,7 @@ } return 0; } +#endif /* 0 */ /*============================================================================ * Execute Adapter Command. --- linux-2.6.11-rc3-mm2-full/include/net/syncppp.h.old 2005-02-17 00:20:19.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/net/syncppp.h 2005-02-17 00:20:25.000000000 +0100 @@ -86,7 +86,6 @@ void sppp_attach (struct ppp_device *pd); void sppp_detach (struct net_device *dev); -void sppp_input (struct net_device *dev, struct sk_buff *m); int sppp_do_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd); struct sk_buff *sppp_dequeue (struct net_device *dev); int sppp_isempty (struct net_device *dev); --- linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c.old 2005-02-17 00:20:36.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c 2005-02-17 00:21:37.000000000 +0100 @@ -221,7 +221,7 @@ * here. */ -void sppp_input (struct net_device *dev, struct sk_buff *skb) +static void sppp_input (struct net_device *dev, struct sk_buff *skb) { struct ppp_header *h; struct sppp *sp = (struct sppp *)sppp_of(dev); @@ -355,8 +355,6 @@ return; } -EXPORT_SYMBOL(sppp_input); - /* * Handle transmit packets. */ @@ -990,7 +988,7 @@ * the mtu is out of range. */ -int sppp_change_mtu(struct net_device *dev, int new_mtu) +static int sppp_change_mtu(struct net_device *dev, int new_mtu) { if(new_mtu<128||new_mtu>PPP_MTU||(dev->flags&IFF_UP)) return -EINVAL; @@ -998,8 +996,6 @@ return 0; } -EXPORT_SYMBOL(sppp_change_mtu); - /** * sppp_do_ioctl - Ioctl handler for ppp/hdlc * @dev: Device subject to ioctl @@ -1455,7 +1451,7 @@ return 0; } -struct packet_type sppp_packet_type = { +static struct packet_type sppp_packet_type = { .type = __constant_htons(ETH_P_WAN_PPP), .func = sppp_rcv, }; --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c.old 2005-04-18 22:42:50.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c 2005-04-18 22:44:32.000000000 +0200 @@ -8,10 +8,10 @@ /* * Prints out len, max to 80 octets using printk, 20 per line */ -void lmcConsoleLog(char *type, unsigned char *ucData, int iLen) -{ #ifdef DEBUG #ifdef LMC_PACKET_LOG +void lmcConsoleLog(char *type, unsigned char *ucData, int iLen) +{ int iNewLine = 1; char str[80], *pstr; @@ -43,26 +43,24 @@ } sprintf(pstr, "\n"); printk(str); +} #endif #endif -} #ifdef DEBUG u_int32_t lmcEventLogIndex = 0; u_int32_t lmcEventLogBuf[LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS]; -#endif void lmcEventLog (u_int32_t EventNum, u_int32_t arg2, u_int32_t arg3) { -#ifdef DEBUG lmcEventLogBuf[lmcEventLogIndex++] = EventNum; lmcEventLogBuf[lmcEventLogIndex++] = arg2; lmcEventLogBuf[lmcEventLogIndex++] = arg3; lmcEventLogBuf[lmcEventLogIndex++] = jiffies; lmcEventLogIndex &= (LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS) - 1; -#endif } +#endif /* DEBUG */ void lmc_trace(struct net_device *dev, char *msg){ #ifdef LMC_TRACE --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c.old 2005-04-18 22:45:21.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c 2005-04-18 22:46:51.000000000 +0200 @@ -112,10 +112,10 @@ static struct tty_driver serial_drv; /* local variables */ -st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS]; +static st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS]; -int cpc_tty_cnt=0; /* number of intrfaces configured with MLPPP */ -int cpc_tty_unreg_flag = 0; +static int cpc_tty_cnt = 0; /* number of intrfaces configured with MLPPP */ +static int cpc_tty_unreg_flag = 0; /* TTY functions prototype */ static int cpc_tty_open(struct tty_struct *tty, struct file *flip); @@ -132,9 +132,9 @@ static void cpc_tty_signal_off(pc300dev_t *pc300dev, unsigned char); static void cpc_tty_signal_on(pc300dev_t *pc300dev, unsigned char); -int pc300_tiocmset(struct tty_struct *, struct file *, - unsigned int, unsigned int); -int pc300_tiocmget(struct tty_struct *, struct file *); +static int pc300_tiocmset(struct tty_struct *, struct file *, + unsigned int, unsigned int); +static int pc300_tiocmget(struct tty_struct *, struct file *); /* functions called by PC300 driver */ void cpc_tty_init(pc300dev_t *dev); @@ -540,8 +540,8 @@ return(0); } -int pc300_tiocmset(struct tty_struct *tty, struct file *file, - unsigned int set, unsigned int clear) +static int pc300_tiocmset(struct tty_struct *tty, struct file *file, + unsigned int set, unsigned int clear) { st_cpc_tty_area *cpc_tty; @@ -567,7 +567,7 @@ return 0; } -int pc300_tiocmget(struct tty_struct *tty, struct file *file) +static int pc300_tiocmget(struct tty_struct *tty, struct file *file) { unsigned int result; unsigned char status; --- linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c.old 2005-04-18 23:16:49.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c 2005-04-18 23:18:21.000000000 +0200 @@ -446,8 +446,8 @@ return readl(dpriv->base_addr + CH0FTDA + dpriv->dev_id*4) == dpriv->ltda; } -int state_check(u32 state, struct dscc4_dev_priv *dpriv, struct net_device *dev, - const char *msg) +static int state_check(u32 state, struct dscc4_dev_priv *dpriv, + struct net_device *dev, const char *msg) { int ret = 0; @@ -466,8 +466,9 @@ return ret; } -void dscc4_tx_print(struct net_device *dev, struct dscc4_dev_priv *dpriv, - char *msg) +static void dscc4_tx_print(struct net_device *dev, + struct dscc4_dev_priv *dpriv, + char *msg) { printk(KERN_DEBUG "%s: tx_current=%02d tx_dirty=%02d (%s)\n", dev->name, dpriv->tx_current, dpriv->tx_dirty, msg); @@ -507,7 +508,8 @@ } } -inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv, struct net_device *dev) +static inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv, + struct net_device *dev) { unsigned int dirty = dpriv->rx_dirty%RX_RING_SIZE; struct RxFD *rx_fd = dpriv->rx_fd + dirty; @@ -1894,7 +1896,7 @@ * It failed and locked solid. Thus the introduction of a dummy skb. * Problem is acknowledged in errata sheet DS5. Joy :o/ */ -struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv) +static struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv) { struct sk_buff *skb; From davem@davemloft.net Mon Apr 18 15:20:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 15:20:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IMKBaM008417 for ; Mon, 18 Apr 2005 15:20:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DNeVZ-00012H-00; Mon, 18 Apr 2005 15:14:21 -0700 Date: Mon, 18 Apr 2005 15:14:21 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit Message-Id: <20050418151421.41a8f64a.davem@davemloft.net> In-Reply-To: <42642892.2040300@candelatech.com> References: <42642892.2040300@candelatech.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1375 Lines: 32 On Mon, 18 Apr 2005 14:37:22 -0700 Ben Greear wrote: > So, two questions: > > 1) Why is it bad to have interrupts disabled when calling > the local_bh_enable() method? Because it creates a deadlock. You can always take hard IRQ disabling locks inside of BH disabling ones, but _never_ the other way around. local_bh_enable() potentially runs BH handlers, and this must occur with hard IRQs enabled. > 2) Should there be a hard requirement that one must never have IRQs disabled > when calling dev->hard_start_xmit (this requirement seems to currently > be in effect because VLANs can call dev_queue_xmit from their hard_start_xmit > method, and it appears that dev_queue_xmit must not be called with IRQs disabled). Yes, it is another true requirement. I even tried to disable hard IRQs during ->hard_start_xmit() to fix a LLTX locking bug and it totally broke things. There are ->hard_start_xmit() routines for very slow devices which expect that jiffies continues to increment via timer interrupts so that they can timeout feeding bytes to the chip properly. Also, again with slow devices, it is expected that hard IRQs are enabled so that your serial ports don't overrun. In general, it's anti-social to IRQ response time sensitive devices in the machine to disable hard IRQs for any non-trivial stretch of code. From greearb@candelatech.com Mon Apr 18 15:59:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 15:59:12 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IMx6rr010474 for ; Mon, 18 Apr 2005 15:59:07 -0700 Received: from [71.112.202.130] (pool-71-112-202-130.sttlwa.dsl-w.verizon.net [71.112.202.130]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3INR6Gf029665; Mon, 18 Apr 2005 16:27:07 -0700 Message-ID: <42643BB9.6050705@candelatech.com> Date: Mon, 18 Apr 2005 15:59:05 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> In-Reply-To: <20050418151421.41a8f64a.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1832 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: 1807 Lines: 49 David S. Miller wrote: > On Mon, 18 Apr 2005 14:37:22 -0700 > Ben Greear wrote: > > >>So, two questions: >> >>1) Why is it bad to have interrupts disabled when calling >> the local_bh_enable() method? > > > Because it creates a deadlock. You can always take hard IRQ disabling > locks inside of BH disabling ones, but _never_ the other way around. > > local_bh_enable() potentially runs BH handlers, and this must occur with > hard IRQs enabled. Ok. It would be great if this explanation was in comments near the warning in the code. The dev_start_xmit code in dev.c could also have a note mentioning that it must never be called with IRQs disabled. >>2) Should there be a hard requirement that one must never have IRQs disabled >> when calling dev->hard_start_xmit (this requirement seems to currently >> be in effect because VLANs can call dev_queue_xmit from their hard_start_xmit >> method, and it appears that dev_queue_xmit must not be called with IRQs disabled). > > > Yes, it is another true requirement. This would be a good addition to the Documentation/networking/netdevices.txt file, or maybe to the dev.c file somewhere (I haven't found an complete list of locking notes, though the comments in the dev.c file and the netdevices.txt file are a big help.) I should be able to fix my particular problem by using reference counting and breaking up my big loop into smaller work units. I assume that it is fine to nest calls to local_bh_enable/disable? (This seems to be required since you are supposed to have bh disabled when calling hard_start_xmit, but hard_start_xmit can call dev_queue_xmit which disables the bh again...) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Mon Apr 18 16:07:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 16:07:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IN7aKW011270 for ; Mon, 18 Apr 2005 16:07:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DNfFU-0001K7-00; Mon, 18 Apr 2005 16:01:48 -0700 Date: Mon, 18 Apr 2005 16:01:47 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit Message-Id: <20050418160147.6fd7ac9a.davem@davemloft.net> In-Reply-To: <42643BB9.6050705@candelatech.com> References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> <42643BB9.6050705@candelatech.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 812 Lines: 18 On Mon, 18 Apr 2005 15:59:05 -0700 Ben Greear wrote: > This would be a good addition to the Documentation/networking/netdevices.txt > file, or maybe to the dev.c file somewhere (I haven't found an complete list of > locking notes, though the comments in the dev.c file and the netdevices.txt file > are a big help.) So write the patch to add such comments. It would have taken the same amount of typing as writing that paragraph saying how great an addition this would be. :) > I assume that it is fine to nest calls to local_bh_enable/disable? (This > seems to be required since you are supposed to have bh disabled when > calling hard_start_xmit, but hard_start_xmit can call dev_queue_xmit which > disables the bh again...) Yes, this is legal, BH disabling does nest properly. From greearb@candelatech.com Mon Apr 18 16:17:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 16:17:39 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3INHYHF012044 for ; Mon, 18 Apr 2005 16:17:34 -0700 Received: from [71.112.202.130] (pool-71-112-202-130.sttlwa.dsl-w.verizon.net [71.112.202.130]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3INjYGf029873; Mon, 18 Apr 2005 16:45:34 -0700 Message-ID: <4264400C.40004@candelatech.com> Date: Mon, 18 Apr 2005 16:17:32 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> <42643BB9.6050705@candelatech.com> <20050418160147.6fd7ac9a.davem@davemloft.net> In-Reply-To: <20050418160147.6fd7ac9a.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1834 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: 767 Lines: 26 David S. Miller wrote: > On Mon, 18 Apr 2005 15:59:05 -0700 > Ben Greear wrote: > > >>This would be a good addition to the Documentation/networking/netdevices.txt >>file, or maybe to the dev.c file somewhere (I haven't found an complete list of >>locking notes, though the comments in the dev.c file and the netdevices.txt file >>are a big help.) > > > So write the patch to add such comments. It would have taken the > same amount of typing as writing that paragraph saying how great an > addition this would be. :) I figured it would be quicker for you to paste the paragraph than to apply my patch :) I'll send one over directly. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Mon Apr 18 17:24:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 17:25:00 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J0OsbQ018028 for ; Mon, 18 Apr 2005 17:24:54 -0700 Received: from [71.112.202.130] (pool-71-112-202-130.sttlwa.dsl-w.verizon.net [71.112.202.130]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3J0qsGf030567; Mon, 18 Apr 2005 17:52:55 -0700 Message-ID: <42644FD4.3030200@candelatech.com> Date: Mon, 18 Apr 2005 17:24:52 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> <42643BB9.6050705@candelatech.com> <20050418160147.6fd7ac9a.davem@davemloft.net> In-Reply-To: <20050418160147.6fd7ac9a.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1835 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: 2191 Lines: 51 David S. Miller wrote: > So write the patch to add such comments. It would have taken the > same amount of typing as writing that paragraph saying how great an > addition this would be. :) Signed-off-by: Ben Greear --- linux-2.6.11/Documentation/networking/netdevices.txt 2005-03-01 23:37:50.000000000 -0800+++ linux-2.6.11.p4s/Documentation/networking/netdevices.txt 2005-04-18 16:59:43.000000000 -0700@@ -51,6 +51,8 @@ set_multicast_list Context: BHs disabled Notes: netif_queue_stopped() is guaranteed false + Interrupts must be enabled when calling hard_start_xmit. + (Interrupts must also be enabled when enabling the BH handler.) Return codes: o NETDEV_TX_OK everything ok. o NETDEV_TX_BUSY Cannot transmit packet, try later Second patch: [greear@lanforge-nx 2.6]$ diff -u linux-2.6.11/net/core/dev.c linux-2.6.11.mostly-clean/net/core/dev.c --- linux-2.6.11/net/core/dev.c 2005-03-01 23:38:09.000000000 -0800 +++ linux-2.6.11.mostly-clean/net/core/dev.c 2005-04-18 17:23:21.767951600 -0700 @@ -1214,6 +1214,19 @@ * A negative errno code is returned on a failure. A success does not * guarantee the frame will be transmitted as it may be dropped due * to congestion or traffic shaping. + * + * ----------------------------------------------------------------------------------- + * I notice this method can also return errors from the queue disciplines, + * including NET_XMIT_DROP, which is a positive value. So, errors can also + * be positive. + * + * Regardless of the return value, the skb is consumed, so it is currently + * difficult to retry a send to this method. (You can bump the ref count + * before sending to hold a reference for retry if you are careful.) + * + * When calling this method, interrupts MUST be enabled. This is because + * the BH enable code must have IRQs enabled so that it will not deadlock. + * --BLG */ int dev_queue_xmit(struct sk_buff *skb) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bunk@stusta.de Mon Apr 18 17:36:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 17:36:48 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J0agbS019462 for ; Mon, 18 Apr 2005 17:36:42 -0700 Received: (qmail 4753 invoked from network); 19 Apr 2005 00:36:36 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 00:36:36 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id D6F06C73AA; Tue, 19 Apr 2005 02:36:35 +0200 (CEST) Date: Tue, 19 Apr 2005 02:36:35 +0200 From: Adrian Bunk To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/ne3210.c: cleanups Message-ID: <20050419003635.GF5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1228 Lines: 48 This patch contains the following cleanups: - make two needlessly global functions static - kill an ancient version variable Signed-off-by: Adrian Bunk --- drivers/net/ne3210.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c.old 2005-02-16 16:09:39.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c 2005-02-21 15:10:02.000000000 +0100 @@ -26,9 +26,6 @@ Updated to EISA probing API 5/2003 by Marc Zyngier. */ -static const char *version = - "ne3210.c: Driver revision v0.03, 30/09/98\n"; - #include #include #include @@ -197,7 +194,7 @@ ei_status.priv = phys_mem; if (ei_debug > 0) - printk(version); + printk("ne3210 loaded.\n"); ei_status.reset_8390 = &ne3210_reset_8390; ei_status.block_input = &ne3210_block_input; @@ -359,12 +356,12 @@ MODULE_DESCRIPTION("NE3210 EISA Ethernet driver"); MODULE_LICENSE("GPL"); -int ne3210_init(void) +static int ne3210_init(void) { return eisa_driver_register (&ne3210_eisa_driver); } -void ne3210_cleanup(void) +static void ne3210_cleanup(void) { eisa_driver_unregister (&ne3210_eisa_driver); } From bunk@stusta.de Mon Apr 18 17:36:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 17:37:00 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J0arTB019482 for ; Mon, 18 Apr 2005 17:36:53 -0700 Received: (qmail 4759 invoked from network); 19 Apr 2005 00:36:47 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 19 Apr 2005 00:36:47 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 0E305C73AA; Tue, 19 Apr 2005 02:36:46 +0200 (CEST) Date: Tue, 19 Apr 2005 02:36:46 +0200 From: Adrian Bunk To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/seeq8005.c: cleanups Message-ID: <20050419003646.GG5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2131 Lines: 80 This patch contains the following cleanups: - make the needlessly global function seeq8005_init static - kill an ancient version variable - remove some outdated Emacs settings Signed-off-by: Adrian Bunk --- This patch was already sent on: - 21 Feb 2005 drivers/net/seeq8005.c | 23 ++--------------------- 1 files changed, 2 insertions(+), 21 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c.old 2005-02-16 18:18:56.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c 2005-02-21 15:19:11.000000000 +0100 @@ -12,12 +12,6 @@ This file is a network device driver for the SEEQ 8005 chipset and the Linux operating system. -*/ - -static const char version[] = - "seeq8005.c:v1.00 8/07/95 Hamish Coleman (hamish@zot.apana.org.au)\n"; - -/* Sources: SEEQ 8005 databook @@ -91,7 +85,7 @@ /* Example routines you must write ;->. */ #define tx_done(dev) (inw(SEEQ_STATUS) & SEEQSTAT_TX_ON) static void hardware_send_packet(struct net_device *dev, char *buf, int length); -extern void seeq8005_init(struct net_device *dev, int startp); +static void seeq8005_init(struct net_device *dev, int startp); static inline void wait_for_buffer(struct net_device *dev); @@ -150,7 +144,6 @@ static int __init seeq8005_probe1(struct net_device *dev, int ioaddr) { - static unsigned version_printed; int i,j; unsigned char SA_prom[32]; int old_cfg1; @@ -291,9 +284,6 @@ } #endif - if (net_debug && version_printed++ == 0) - printk(version); - printk("%s: %s found at %#3x, ", dev->name, "seeq8005", ioaddr); /* Fill in the 'dev' fields. */ @@ -637,7 +627,7 @@ #endif } -void seeq8005_init(struct net_device *dev, int startp) +static void seeq8005_init(struct net_device *dev, int startp) { struct net_local *lp = netdev_priv(dev); int ioaddr = dev->base_addr; @@ -758,12 +748,3 @@ } #endif /* MODULE */ - -/* - * Local variables: - * compile-command: "gcc -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototypes -O6 -m486 -c skeleton.c" - * version-control: t - * kept-new-versions: 5 - * tab-width: 4 - * End: - */ From shemminger@osdl.org Mon Apr 18 18:01:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 18:01:23 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J11GHV021139 for ; Mon, 18 Apr 2005 18:01:17 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3J116s4017494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 18 Apr 2005 18:01:09 -0700 Date: Tue, 19 Apr 2005 11:00:18 +1000 From: Stephen Hemminger To: netdev@oss.sgi.com Subject: Fw: [Bug 3998] ARP issues after RC1 Message-ID: <20050419110018.25baf191@localhost.localdomain> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1838 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: 1629 Lines: 42 Begin forwarded message: Date: Mon, 18 Apr 2005 05:39:42 -0700 From: bugme-daemon@osdl.org To: shemminger@osdl.org Subject: [Bug 3998] ARP issues after RC1 http://bugme.osdl.org/show_bug.cgi?id=3998 ---------- Distribution: Redhat 9.0 Hardware Environment: Intel/IWill MBs. Intel e1000 and Broadcom tg3 network modules. Problem Description: After upgrading to 2.4.28, we having issues where hosts are unreachable and we are getting entries in the ARP tables. After the entry has cleared, the host will become reachable. This is most noticible upon startup, where netfs (nfs mounts), yp, and ntp fail, as they cannot reach their corresponding servers. This is happening on multiple machines, with different MBs and network interfaces, all running RedHat 9.0. 2.4.27, using the same .config had no such issues. After compiling all the pre and rc patches, it seems that the offending change occurred between rc1 and rc2. Steps to reproduce: 1. Install RH9, workstation install. 2. Configure NFS mounts in /etc/fstab, chkconfig netfs on. 3. Configure NTP, chkconfig ntp on. 4. Configure YP, chkconfig ypbind on. 5. Compile 2.4.28 using .config below 6. Reboot using 2.4.28. Upon boot, the services above will fail, as they cannot reach their servers. 7. Once up, log in as root and type arp -a. There will be entries for the unreachable hosts. 8. Compile 2.4.28-rc1, using the same .config. 9. Reboot using 2.4.28-rc1. All the previously failing services will start up with no issues. 10. Compile 2.4.28-rc2, using the same .config. 11. Reboot using 2.4.28-rc2. The services will fail once again. From shemminger@osdl.org Mon Apr 18 18:07:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 18:07:56 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J17nHJ021877 for ; Mon, 18 Apr 2005 18:07:49 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3J17Qs4018005 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 Apr 2005 18:07:32 -0700 Date: Tue, 19 Apr 2005 11:06:39 +1000 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen Message-ID: <20050419110639.47767113@localhost.localdomain> In-Reply-To: <42628300.9010007@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1839 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: 516 Lines: 12 On Sun, 17 Apr 2005 17:38:40 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Would this work better.? It just increases qlen by +/- 1 on enqueue, dequeue. > > It also allows < 1ms delays if there is enough traffic going through. > > It looks better, but with duplication there can still be an increment > of 2 in netem_enqueue(). There may be no sane way to do duplication without that. Other ways like injecting packets again at top of queue with a thread/tasklet seem rather gross From yoshfuji@wide.ad.jp Mon Apr 18 18:12:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 18:12:54 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J1Ciqf022568 for ; Mon, 18 Apr 2005 18:12:48 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id F181433CC2; Tue, 19 Apr 2005 10:15:06 +0900 (JST) Date: Tue, 19 Apr 2005 10:15:01 +0900 (JST) Message-Id: <20050419.101501.36911974.yoshfuji@wide.ad.jp> To: pbellino@mrv.com Cc: netdev@oss.sgi.com Subject: Re: 2.6.11 kernel, PPC, and IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050419.021441.50994203.yoshfuji@linux-ipv6.org> References: <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> <20050419.021441.50994203.yoshfuji@linux-ipv6.org> 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-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 827 Lines: 17 In article <20050419.021441.50994203.yoshfuji@linux-ipv6.org> (at Tue, 19 Apr 2005 02:14:41 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <19EE6EC66973A5408FBE4CB7772F6F0A0289942D@ltnmail.xyplex.com> (at Mon, 18 Apr 2005 12:27:31 -0400), "Bellino, Phil" says: : > > > One of my questions is at boot time, my eth0 device does not have it's > > > link-local address. I must issue an "ifconfig eth0 down" and then an > > > "ifconfig eth0 up" to get this work work. > > > > > > Also, it does not auto-configure the info for a link-global prefix/address > > > that is provided by the router announcements. > > 2.6.12-rcs seem to work fine on my x86 and ultrasparc at least. > I'm trying to build on my ppc as well. It seems to work fine on my ppc. --yoshfuji From bunk@stusta.de Mon Apr 18 18:29:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 18:29:54 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J1TfLj023457 for ; Mon, 18 Apr 2005 18:29:42 -0700 Received: (qmail 5808 invoked from network); 19 Apr 2005 01:29:36 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 01:29:36 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 72F9BBB58E; Tue, 19 Apr 2005 03:29:35 +0200 (CEST) Date: Tue, 19 Apr 2005 03:29:35 +0200 From: Adrian Bunk To: Benjamin LaHaise Cc: jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] kill include/linux/eeprom.h Message-ID: <20050419012935.GQ5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 6051 Lines: 256 This patch kills include/linux/eeprom.h . Rationale: - it's only used by one single driver - most of this file are non-inline and non-static functions (sic) This patch moves all required contents of this file into ns83820.c and removes include/linux/eeprom.h (and makes setup_ee_mem_bitbanger static). If you think eeprom.h should be used more extensively, please consider: - the code has to be moved from the header file to a .c file - the currently empty write function has to be implemented - even ns83820.c used only one of the 7 functions in eeprom.h Noone did any of these during the more than 3 years eeprom.h already exists... Signed-off-by: Adrian Bunk --- This patch was already sent on: - 17 Feb 2005 drivers/net/ns83820.c | 49 +++++++++++++- include/linux/eeprom.h | 136 ----------------------------------------- 2 files changed, 44 insertions(+), 141 deletions(-) --- linux-2.6.11-rc3-mm2-full/include/linux/eeprom.h 2004-12-24 22:33:49.000000000 +0100 +++ /dev/null 2004-11-25 03:16:25.000000000 +0100 @@ -1,136 +0,0 @@ -/* credit winbond-840.c - */ -#include -struct eeprom_ops { - void (*set_cs)(void *ee); - void (*clear_cs)(void *ee); -}; - -#define EEPOL_EEDI 0x01 -#define EEPOL_EEDO 0x02 -#define EEPOL_EECLK 0x04 -#define EEPOL_EESEL 0x08 - -struct eeprom { - void *dev; - struct eeprom_ops *ops; - - void __iomem * addr; - - unsigned ee_addr_bits; - - unsigned eesel; - unsigned eeclk; - unsigned eedo; - unsigned eedi; - unsigned polarity; - unsigned ee_state; - - spinlock_t *lock; - u32 *cache; -}; - - -u8 eeprom_readb(struct eeprom *ee, unsigned address); -void eeprom_read(struct eeprom *ee, unsigned address, u8 *bytes, - unsigned count); -void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data); -void eeprom_write(struct eeprom *ee, unsigned address, u8 *bytes, - unsigned count); - -/* The EEPROM commands include the alway-set leading bit. */ -enum EEPROM_Cmds { - EE_WriteCmd=(5 << 6), EE_ReadCmd=(6 << 6), EE_EraseCmd=(7 << 6), -}; - -void setup_ee_mem_bitbanger(struct eeprom *ee, void __iomem *memaddr, int eesel_bit, int eeclk_bit, int eedo_bit, int eedi_bit, unsigned polarity) -{ - ee->addr = memaddr; - ee->eesel = 1 << eesel_bit; - ee->eeclk = 1 << eeclk_bit; - ee->eedo = 1 << eedo_bit; - ee->eedi = 1 << eedi_bit; - - ee->polarity = polarity; - - *ee->cache = readl(ee->addr); -} - -/* foo. put this in a .c file */ -static inline void eeprom_update(struct eeprom *ee, u32 mask, int pol) -{ - unsigned long flags; - u32 data; - - spin_lock_irqsave(ee->lock, flags); - data = *ee->cache; - - data &= ~mask; - if (pol) - data |= mask; - - *ee->cache = data; -//printk("update: %08x\n", data); - writel(data, ee->addr); - spin_unlock_irqrestore(ee->lock, flags); -} - -void eeprom_clk_lo(struct eeprom *ee) -{ - int pol = !!(ee->polarity & EEPOL_EECLK); - - eeprom_update(ee, ee->eeclk, pol); - udelay(2); -} - -void eeprom_clk_hi(struct eeprom *ee) -{ - int pol = !!(ee->polarity & EEPOL_EECLK); - - eeprom_update(ee, ee->eeclk, !pol); - udelay(2); -} - -void eeprom_send_addr(struct eeprom *ee, unsigned address) -{ - int pol = !!(ee->polarity & EEPOL_EEDI); - unsigned i; - address |= 6 << 6; - - /* Shift the read command bits out. */ - for (i=0; i<11; i++) { - eeprom_update(ee, ee->eedi, ((address >> 10) & 1) ^ pol); - address <<= 1; - eeprom_clk_hi(ee); - eeprom_clk_lo(ee); - } - eeprom_update(ee, ee->eedi, pol); -} - -u16 eeprom_readw(struct eeprom *ee, unsigned address) -{ - unsigned i; - u16 res = 0; - - eeprom_clk_lo(ee); - eeprom_update(ee, ee->eesel, 1 ^ !!(ee->polarity & EEPOL_EESEL)); - eeprom_send_addr(ee, address); - - for (i=0; i<16; i++) { - u32 data; - eeprom_clk_hi(ee); - res <<= 1; - data = readl(ee->addr); -//printk("eeprom_readw: %08x\n", data); - res |= !!(data & ee->eedo) ^ !!(ee->polarity & EEPOL_EEDO); - eeprom_clk_lo(ee); - } - eeprom_update(ee, ee->eesel, 0 ^ !!(ee->polarity & EEPOL_EESEL)); - - return res; -} - - -void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data) -{ -} --- linux-2.6.11-rc3-mm2-full/drivers/net/ns83820.c.old 2005-02-16 17:52:43.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/ns83820.c 2005-02-16 18:05:26.000000000 +0100 @@ -107,7 +107,6 @@ #include #include /* for iph */ #include /* for IPPROTO_... */ -#include #include #include #include @@ -422,6 +421,35 @@ #define DESC_SIZE 8 /* Should be cache line sized */ +struct eeprom_ops { + void (*set_cs)(void *ee); + void (*clear_cs)(void *ee); +}; + +#define EEPOL_EEDI 0x01 +#define EEPOL_EEDO 0x02 +#define EEPOL_EECLK 0x04 +#define EEPOL_EESEL 0x08 + +struct eeprom { + void *dev; + struct eeprom_ops *ops; + + void __iomem * addr; + + unsigned ee_addr_bits; + + unsigned eesel; + unsigned eeclk; + unsigned eedo; + unsigned eedi; + unsigned polarity; + unsigned ee_state; + + spinlock_t *lock; + u32 *cache; +}; + struct rx_info { spinlock_t lock; int up; @@ -481,6 +509,21 @@ struct timer_list tx_watchdog; }; +static void setup_ee_mem_bitbanger(struct eeprom *ee, void __iomem *memaddr, + int eesel_bit, int eeclk_bit, int eedo_bit, + int eedi_bit, unsigned polarity) +{ + ee->addr = memaddr; + ee->eesel = 1 << eesel_bit; + ee->eeclk = 1 << eeclk_bit; + ee->eedo = 1 << eedo_bit; + ee->eedi = 1 << eedi_bit; + + ee->polarity = polarity; + + *ee->cache = readl(ee->addr); +} + static inline struct ns83820 *PRIV(struct net_device *dev) { return netdev_priv(dev); @@ -1568,15 +1611,11 @@ unsigned i; for (i=0; i<3; i++) { u32 data; -#if 0 /* I've left this in as an example of how to use eeprom.h */ - data = eeprom_readw(&dev->ee, 0xa + 2 - i); -#else /* Read from the perfect match memory: this is loaded by * the chip from the EEPROM via the EELOAD self test. */ writel(i*2, dev->base + RFCR); data = readl(dev->base + RFDR); -#endif *mac++ = data; *mac++ = data >> 8; } From bunk@stusta.de Mon Apr 18 19:03:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:03:27 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J23Ig7024907 for ; Mon, 18 Apr 2005 19:03:19 -0700 Received: (qmail 6388 invoked from network); 19 Apr 2005 02:03:13 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 02:03:13 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A0D8ABB58E; Tue, 19 Apr 2005 04:03:12 +0200 (CEST) Date: Tue, 19 Apr 2005 04:03:12 +0200 From: Adrian Bunk To: Andrew Morton , jkmaline@cc.hut.fi Cc: linux-kernel@vger.kernel.org, hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: 2.6.12-rc2-mm3: hostap: do not #include .c files Message-ID: <20050419020312.GR5489@stusta.de> References: <20050411012532.58593bc1.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411012532.58593bc1.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1256 Lines: 35 On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote: >... > All 819 patches: >... > bk-netdev.patch >... drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_ap.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_info.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_ioctl.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_proc.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_rx.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_tx.c" drivers/net/wireless/hostap/hostap_cs.c:#include "hostap_hw.c" drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_download.c" drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_callback.c" drivers/net/wireless/hostap/hostap_pci.c:#include "hostap_hw.c" drivers/net/wireless/hostap/hostap_plx.c:#include "hostap_hw.c" Please do not #include .c files. A proper separation in a .c file and a header file is the better solution. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From herbert@gondor.apana.org.au Mon Apr 18 19:13:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:13:53 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J2DiKB026010 for ; Mon, 18 Apr 2005 19:13:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DNiEs-00016O-00; Tue, 19 Apr 2005 12:13:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DNiEQ-00010X-00; Tue, 19 Apr 2005 12:12:54 +1000 From: Herbert Xu To: shemminger@osdl.org (Stephen Hemminger) Subject: Re: Fw: [Bug 3998] ARP issues after RC1 Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <20050419110018.25baf191@localhost.localdomain> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 19 Apr 2005 12:12:54 +1000 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 473 Lines: 11 Stephen Hemminger wrote: > > Problem Description: After upgrading to 2.4.28, we having issues where hosts are Some important fixes have been put in after the release 2.4.28. Please make sure that this can still be reproduced with 2.4.30. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jm@jm.kir.nu Mon Apr 18 19:15:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:15:12 -0700 (PDT) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J2F4KQ026267 for ; Mon, 18 Apr 2005 19:15:05 -0700 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DNiEA-0005g6-E3; Mon, 18 Apr 2005 19:12:38 -0700 Date: Mon, 18 Apr 2005 19:12:38 -0700 From: Jouni Malinen To: Adrian Bunk Cc: Andrew Morton , linux-kernel@vger.kernel.org, hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.12-rc2-mm3: hostap: do not #include .c files Message-ID: <20050419021238.GG8267@jm.kir.nu> Mail-Followup-To: Adrian Bunk , Andrew Morton , linux-kernel@vger.kernel.org, hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com References: <20050411012532.58593bc1.akpm@osdl.org> <20050419020312.GR5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419020312.GR5489@stusta.de> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 612 Lines: 18 On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote: > drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c" > Please do not #include .c files. A tested patch would be appreciated.. ;-) > A proper separation in a .c file and a header file is the better > solution. Agreed and this is on my to-do list, but not very high on it. Some of these would be relatively easy to fix, but the hardware specific ones (different register offsets for PC Card/PLX/PCI) would require quite a bit of changes to get rid of this. -- Jouni Malinen PGP id EFC895FA From bunk@stusta.de Mon Apr 18 19:36:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:37:05 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J2avaw028661 for ; Mon, 18 Apr 2005 19:36:58 -0700 Received: (qmail 6842 invoked from network); 19 Apr 2005 02:36:51 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 02:36:51 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id C8C65BB58E; Tue, 19 Apr 2005 04:36:50 +0200 (CEST) Date: Tue, 19 Apr 2005 04:36:50 +0200 From: Adrian Bunk To: acme@conectiva.com.br Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/appletalk/: make 2 firmware images static const Message-ID: <20050419023650.GS5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1183 Lines: 33 This patch makes two needlessly global fimware images static const. Signed-off-by: Adrian Bunk --- drivers/net/appletalk/cops_ffdrv.h | 2 +- drivers/net/appletalk/cops_ltdrv.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ffdrv.h.old 2005-04-19 03:02:05.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ffdrv.h 2005-04-19 03:02:15.000000000 +0200 @@ -28,7 +28,7 @@ #ifdef CONFIG_COPS_DAYNA -unsigned char ffdrv_code[] = { +static const unsigned char ffdrv_code[] = { 58,3,0,50,228,149,33,255,255,34,226,149, 249,17,40,152,33,202,154,183,237,82,77,68, 11,107,98,19,54,0,237,176,175,50,80,0, --- linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ltdrv.h.old 2005-04-19 03:02:27.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ltdrv.h 2005-04-19 03:02:34.000000000 +0200 @@ -27,7 +27,7 @@ #ifdef CONFIG_COPS_TANGENT -unsigned char ltdrv_code[] = { +static const unsigned char ltdrv_code[] = { 58,3,0,50,148,10,33,143,15,62,85,119, 190,32,9,62,170,119,190,32,3,35,24,241, 34,146,10,249,17,150,10,33,143,15,183,237, From bunk@stusta.de Mon Apr 18 19:38:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:38:51 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J2ckm0029043 for ; Mon, 18 Apr 2005 19:38:46 -0700 Received: (qmail 6867 invoked from network); 19 Apr 2005 02:38:40 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 19 Apr 2005 02:38:40 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 3AFEBBB58E; Tue, 19 Apr 2005 04:38:40 +0200 (CEST) Date: Tue, 19 Apr 2005 04:38:40 +0200 From: Adrian Bunk To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2,6 patch] drivers/net/arcnet/capmode.c: make a struct static Message-ID: <20050419023840.GT5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 461 Lines: 16 This patch makes a needlessly global struct static. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c.old 2005-04-19 03:03:23.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c 2005-04-19 03:03:53.000000000 +0200 @@ -48,7 +48,7 @@ static int ack_tx(struct net_device *dev, int acked); -struct ArcProto capmode_proto = +static struct ArcProto capmode_proto = { 'r', XMTU, From bunk@stusta.de Mon Apr 18 19:40:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:40:19 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J2eDq3029761 for ; Mon, 18 Apr 2005 19:40:14 -0700 Received: (qmail 6888 invoked from network); 19 Apr 2005 02:40:08 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 02:40:08 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id AE416BB58E; Tue, 19 Apr 2005 04:40:07 +0200 (CEST) Date: Tue, 19 Apr 2005 04:40:07 +0200 From: Adrian Bunk To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/hamradio/: cleanups Message-ID: <20050419024007.GU5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1234 Lines: 43 This patch contains the following cleanups: - mkiss.c: make a needlessly global variable static - dmascc.c: remove the unused global function dmascc_setup Signed-off-by: Adrian Bunk --- drivers/net/hamradio/dmascc.c | 10 ---------- drivers/net/hamradio/mkiss.c | 2 +- 2 files changed, 1 insertion(+), 11 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/dmascc.c.old 2005-04-19 03:04:36.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/dmascc.c 2005-04-19 03:04:57.000000000 +0200 @@ -311,16 +311,6 @@ } } -#ifndef MODULE -void __init dmascc_setup(char *str, int *ints) -{ - int i; - - for (i = 0; i < MAX_NUM_DEVS && i < ints[0]; i++) - io[i] = ints[i + 1]; -} -#endif - static int __init dmascc_init(void) { int h, i, j, n; --- linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/mkiss.c.old 2005-04-19 03:05:20.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/mkiss.c 2005-04-19 03:05:30.000000000 +0200 @@ -65,7 +65,7 @@ static ax25_ctrl_t **ax25_ctrls; -int ax25_maxdev = AX25_MAXDEV; /* Can be overridden with insmod! */ +static int ax25_maxdev = AX25_MAXDEV; /* Can be overridden with insmod! */ static struct tty_ldisc ax_ldisc; From bunk@stusta.de Mon Apr 18 19:41:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:41:47 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J2fdXt030354 for ; Mon, 18 Apr 2005 19:41:40 -0700 Received: (qmail 6918 invoked from network); 19 Apr 2005 02:41:34 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 19 Apr 2005 02:41:34 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 95D24BB58E; Tue, 19 Apr 2005 04:41:33 +0200 (CEST) Date: Tue, 19 Apr 2005 04:41:33 +0200 From: Adrian Bunk To: irda-users@lists.sourceforge.net Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/irda/irport.c: cleanups Message-ID: <20050419024133.GV5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 43 This patch contains the following cleanups: - make a needlessly global function static - remove the unneeded global function irport_probe Signed-off-by: Adrian Bunk --- drivers/net/irda/irport.c | 15 +-------------- 1 files changed, 1 insertion(+), 14 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/irda/irport.c.old 2005-04-19 03:06:12.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/irda/irport.c 2005-04-19 03:06:45.000000000 +0200 @@ -286,19 +286,6 @@ } /* - * Function irport_probe (void) - * - * Start IO port - * - */ -int irport_probe(int iobase) -{ - IRDA_DEBUG(4, "%s(), iobase=%#x\n", __FUNCTION__, iobase); - - return 0; -} - -/* * Function irport_get_fcr (speed) * * Compute value of fcr @@ -383,7 +370,7 @@ * we cannot use schedule_timeout() when we are in interrupt context * */ -int __irport_change_speed(struct irda_task *task) +static int __irport_change_speed(struct irda_task *task) { struct irport_cb *self; __u32 speed = (__u32) task->param; From bunk@stusta.de Mon Apr 18 19:45:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 19:45:15 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J2j81B031096 for ; Mon, 18 Apr 2005 19:45:09 -0700 Received: (qmail 7027 invoked from network); 19 Apr 2005 02:45:03 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 19 Apr 2005 02:45:03 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id ACA3CBB58E; Tue, 19 Apr 2005 04:45:02 +0200 (CEST) Date: Tue, 19 Apr 2005 04:45:02 +0200 From: Adrian Bunk To: mikep@linuxtr.net Cc: linux-tr@linuxtr.net, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/tokenring/: cleanups Message-ID: <20050419024502.GX5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 12361 Lines: 310 This patch contains the follwing cleanups: - make needlessly global code static - remove obsolete Emacs settings Signed-off-by: Adrian Bunk --- drivers/net/pcmcia/ibmtr_cs.c | 3 -- drivers/net/tokenring/3c359.c | 3 +- drivers/net/tokenring/3c359_microcode.h | 2 - drivers/net/tokenring/abyss.c | 11 --------- drivers/net/tokenring/ibmtr.c | 28 ++++++++++++------------ drivers/net/tokenring/madgemc.c | 14 ------------ drivers/net/tokenring/proteon.c | 11 --------- drivers/net/tokenring/skisa.c | 11 --------- drivers/net/tokenring/smctr.c | 2 - drivers/net/tokenring/smctr_firmware.h | 2 - drivers/net/tokenring/tms380tr.c | 13 ----------- drivers/net/tokenring/tmspci.c | 11 --------- 12 files changed, 21 insertions(+), 90 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/ibmtr.c.old 2005-04-19 03:11:34.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/ibmtr.c 2005-04-19 03:41:47.000000000 +0200 @@ -151,7 +151,7 @@ /* this allows displaying full adapter information */ -char *channel_def[] __devinitdata = { "ISA", "MCA", "ISA P&P" }; +static char *channel_def[] __devinitdata = { "ISA", "MCA", "ISA P&P" }; static char pcchannelid[] __devinitdata = { 0x05, 0x00, 0x04, 0x09, @@ -171,7 +171,7 @@ 0x03, 0x08, 0x02, 0x00 }; -char __devinit *adapter_def(char type) +static char __devinit *adapter_def(char type) { switch (type) { case 0xF: return "PC Adapter | PC Adapter II | Adapter/A"; @@ -184,7 +184,7 @@ #define TRC_INIT 0x01 /* Trace initialization & PROBEs */ #define TRC_INITV 0x02 /* verbose init trace points */ -unsigned char ibmtr_debug_trace = 0; +static unsigned char ibmtr_debug_trace = 0; static int ibmtr_probe(struct net_device *dev); static int ibmtr_probe1(struct net_device *dev, int ioaddr); @@ -192,20 +192,20 @@ static int trdev_init(struct net_device *dev); static int tok_open(struct net_device *dev); static int tok_init_card(struct net_device *dev); -void tok_open_adapter(unsigned long dev_addr); +static void tok_open_adapter(unsigned long dev_addr); static void open_sap(unsigned char type, struct net_device *dev); static void tok_set_multicast_list(struct net_device *dev); static int tok_send_packet(struct sk_buff *skb, struct net_device *dev); static int tok_close(struct net_device *dev); -irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs); +static irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs); static void initial_tok_int(struct net_device *dev); static void tr_tx(struct net_device *dev); static void tr_rx(struct net_device *dev); -void ibmtr_reset_timer(struct timer_list*tmr,struct net_device *dev); +static void ibmtr_reset_timer(struct timer_list*tmr,struct net_device *dev); static void tok_rerun(unsigned long dev_addr); -void ibmtr_readlog(struct net_device *dev); +static void ibmtr_readlog(struct net_device *dev); static struct net_device_stats *tok_get_stats(struct net_device *dev); -int ibmtr_change_mtu(struct net_device *dev, int mtu); +static int ibmtr_change_mtu(struct net_device *dev, int mtu); static void find_turbo_adapters(int *iolist); static int ibmtr_portlist[IBMTR_MAX_ADAPTERS+1] __devinitdata = { @@ -928,7 +928,7 @@ #define DLC_MAX_SAP_OFST 32 #define DLC_MAX_STA_OFST 33 -void tok_open_adapter(unsigned long dev_addr) +static void tok_open_adapter(unsigned long dev_addr) { struct net_device *dev = (struct net_device *) dev_addr; struct tok_info *ti; @@ -1099,7 +1099,7 @@ return ti->sram_virt + index; } -void dir_open_adapter (struct net_device *dev) +static void dir_open_adapter (struct net_device *dev) { struct tok_info *ti = (struct tok_info *) dev->priv; unsigned char ret_code; @@ -1172,7 +1172,7 @@ /******************************************************************************/ -irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs) +static irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs) { unsigned char status; /* unsigned char status_even ; */ @@ -1840,7 +1840,7 @@ /*****************************************************************************/ -void ibmtr_reset_timer(struct timer_list *tmr, struct net_device *dev) +static void ibmtr_reset_timer(struct timer_list *tmr, struct net_device *dev) { tmr->expires = jiffies + TR_RETRY_INTERVAL; tmr->data = (unsigned long) dev; @@ -1872,7 +1872,7 @@ /*****************************************************************************/ -void ibmtr_readlog(struct net_device *dev) +static void ibmtr_readlog(struct net_device *dev) { struct tok_info *ti; @@ -1905,7 +1905,7 @@ /*****************************************************************************/ -int ibmtr_change_mtu(struct net_device *dev, int mtu) +static int ibmtr_change_mtu(struct net_device *dev, int mtu) { struct tok_info *ti = (struct tok_info *) dev->priv; --- linux-2.6.12-rc2-mm3-full/drivers/net/pcmcia/ibmtr_cs.c.old 2005-04-19 03:42:01.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/pcmcia/ibmtr_cs.c 2005-04-19 03:42:10.000000000 +0200 @@ -119,9 +119,6 @@ static dev_link_t *dev_list; -extern int ibmtr_probe_card(struct net_device *dev); -extern irqreturn_t tok_interrupt (int irq, void *dev_id, struct pt_regs *regs); - /*====================================================================*/ typedef struct ibmtr_dev_t { --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/3c359_microcode.h.old 2005-04-19 03:43:09.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/3c359_microcode.h 2005-04-19 03:43:16.000000000 +0200 @@ -22,7 +22,7 @@ static int mc_size = 24880 ; -u8 microcode[] = { +static const u8 microcode[] = { 0xfe,0x3a,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/3c359.c.old 2005-04-19 03:43:31.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/3c359.c 2005-04-19 03:43:48.000000000 +0200 @@ -276,7 +276,8 @@ return ; } -int __devinit xl_probe(struct pci_dev *pdev, const struct pci_device_id *ent) +static int __devinit xl_probe(struct pci_dev *pdev, + const struct pci_device_id *ent) { struct net_device *dev ; struct xl_private *xl_priv ; --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/madgemc.c.old 2005-04-19 03:44:09.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/madgemc.c 2005-04-19 03:47:40.000000000 +0200 @@ -625,7 +625,7 @@ /* * Disable the board, and put back into power-up state. */ -void madgemc_chipset_close(struct net_device *dev) +static void madgemc_chipset_close(struct net_device *dev) { /* disable interrupts */ madgemc_setint(dev, 0); @@ -786,15 +786,3 @@ MODULE_LICENSE("GPL"); - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c madgemc.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c madgemc.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ - --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/smctr_firmware.h.old 2005-04-19 03:44:52.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/smctr_firmware.h 2005-04-19 03:45:00.000000000 +0200 @@ -21,7 +21,7 @@ #if defined(CONFIG_SMCTR) || defined(CONFIG_SMCTR_MODULE) -unsigned char smctr_code[] = { +static const unsigned char smctr_code[] = { 0x0BC, 0x01D, 0x012, 0x03B, 0x063, 0x0B4, 0x0E9, 0x000, 0x000, 0x01F, 0x000, 0x001, 0x001, 0x000, 0x002, 0x005, 0x001, 0x000, 0x006, 0x003, 0x001, 0x000, 0x004, 0x009, --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/smctr.c.old 2005-04-19 03:45:13.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/smctr.c 2005-04-19 03:45:20.000000000 +0200 @@ -77,7 +77,7 @@ /* SMC Name of the Adapter. */ static char smctr_name[] = "SMC TokenCard"; -char *smctr_model = "Unknown"; +static char *smctr_model = "Unknown"; /* Use 0 for production, 1 for verification, 2 for debug, and * 3 for very verbose debug. --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/tms380tr.c.old 2005-04-19 03:45:43.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/tms380tr.c 2005-04-19 03:46:24.000000000 +0200 @@ -2379,7 +2379,7 @@ EXPORT_SYMBOL(tmsdev_term); EXPORT_SYMBOL(tms380tr_wait); -struct module *TMS380_module = NULL; +static struct module *TMS380_module = NULL; int init_module(void) { @@ -2397,14 +2397,3 @@ MODULE_LICENSE("GPL"); - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c tms380tr.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c tms380tr.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/tmspci.c.old 2005-04-19 03:46:38.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/tmspci.c 2005-04-19 03:46:48.000000000 +0200 @@ -254,14 +254,3 @@ module_init(tms_pci_init); module_exit(tms_pci_rmmod); - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c tmspci.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c tmspci.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/skisa.c.old 2005-04-19 03:46:56.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/skisa.c 2005-04-19 03:47:06.000000000 +0200 @@ -429,14 +429,3 @@ } #endif /* MODULE */ - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c skisa.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c skisa.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/proteon.c.old 2005-04-19 03:47:15.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/proteon.c 2005-04-19 03:47:27.000000000 +0200 @@ -419,14 +419,3 @@ } #endif /* MODULE */ - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c proteon.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c proteon.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ --- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/abyss.c.old 2005-04-19 03:47:48.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/abyss.c 2005-04-19 03:47:53.000000000 +0200 @@ -468,14 +468,3 @@ module_init(abyss_init); module_exit(abyss_rmmod); - -/* - * Local variables: - * compile-command: "gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c abyss.c" - * alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/tokenring/ -c abyss.c" - * c-set-style "K&R" - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ From acme@ghostprotocols.net Mon Apr 18 21:59:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 21:59:30 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J4xMFg007379 for ; Mon, 18 Apr 2005 21:59:24 -0700 Received: from [200.103.136.131] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DNkrM-0001NP-00; Tue, 19 Apr 2005 02:01:16 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id A5CE21462D; Tue, 19 Apr 2005 01:59:14 -0300 (BRT) Date: Tue, 19 Apr 2005 01:59:14 -0300 To: davem@davemloft.net Cc: netdev@oss.sgi.com, Andrew Morton Subject: [PATCH][SOCK] on failure free the sock from the right place Message-ID: <20050419045914.GD9433@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i From: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@ghostprotocols.net Precedence: bulk X-list: netdev Content-Length: 889 Lines: 41 Hi Dave, Please apply. Best Regards, - Arnaldo ------------------------------------------------------------------------ Author: acme Date: 2005-04-19 01:53:49 -0300 (Tue, 19 Apr 2005) New Revision: 68 Modified: trunk/net/core/sock.c Log: [SOCK] on failure free the sock from the right place Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Modified: trunk/net/core/sock.c =================================================================== --- trunk/net/core/sock.c 2005-04-19 02:32:15 UTC (rev 67) +++ trunk/net/core/sock.c 2005-04-19 04:53:49 UTC (rev 68) @@ -642,7 +642,10 @@ } if (security_sk_alloc(sk, family, priority)) { - kmem_cache_free(slab, sk); + if (slab != NULL) + kmem_cache_free(slab, sk); + else + kfree(sk); sk = NULL; } else __module_get(prot->owner); From itn780@yahoo.com Mon Apr 18 22:55:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 22:55:49 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J5tgA4009504 for ; Mon, 18 Apr 2005 22:55:42 -0700 Received: from unknown (HELO ?192.168.0.250?) (itn780@24.7.113.184 with plain) by smtp016.mail.yahoo.com with SMTP; 19 Apr 2005 05:55:42 -0000 Message-ID: <42649D50.3020103@yahoo.com> Date: Mon, 18 Apr 2005 22:55:28 -0700 From: Alex Aizman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [ANNOUNCE] Linux-iSCSI High-Performance Initiator: iscsi_tcp.h Content-Type: multipart/mixed; boundary="------------010907000305040105070201" X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itn780@yahoo.com Precedence: bulk X-list: netdev Content-Length: 9079 Lines: 305 This is a multi-part message in MIME format. --------------010907000305040105070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached: iscsi_tcp.h. The corresponding source file (iscsi_tcp.c) was sent in the previous e-mail. Again, it'd be great to get this code reviewed. Thanks! --------------010907000305040105070201 Content-Type: text/plain; name="iscsi_tcp.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iscsi_tcp.h" /* * iSCSI Initiator TCP Transport * Copyright (C) 2004 Dmitry Yusupov, Alex Aizman * maintained by open-iscsi@@googlegroups.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published * by the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * See the file COPYING included with this distribution for more details. */ #ifndef ISCSI_TCP_H #define ISCSI_TCP_H #include /* Session's states */ #define ISCSI_STATE_FREE 1 #define ISCSI_STATE_LOGGED_IN 2 #define ISCSI_STATE_FAILED 3 #define ISCSI_STATE_TERMINATE 4 /* Connection's states */ #define ISCSI_CNX_INITIAL_STAGE 0 #define ISCSI_CNX_STARTED 1 #define ISCSI_CNX_STOPPED 2 #define ISCSI_CNX_CLEANUP_WAIT 3 /* Socket's Receive state machine */ #define IN_PROGRESS_WAIT_HEADER 0x0 #define IN_PROGRESS_HEADER_GATHER 0x1 #define IN_PROGRESS_DATA_RECV 0x2 /* Task Mgmt states */ #define TMABORT_INITIAL 0x0 #define TMABORT_SUCCESS 0x1 #define TMABORT_FAILED 0x2 #define TMABORT_TIMEDOUT 0x3 /* iSCSI Task Command's state machine */ #define IN_PROGRESS_IDLE 0x0 #define IN_PROGRESS_READ 0x1 #define IN_PROGRESS_WRITE 0x2 /* xmit state machine */ #define XMSTATE_IDLE 0x0 #define XMSTATE_R_HDR 0x1 #define XMSTATE_W_HDR 0x2 #define XMSTATE_IMM_HDR 0x4 #define XMSTATE_IMM_DATA 0x8 #define XMSTATE_UNS_INIT 0x10 #define XMSTATE_UNS_HDR 0x20 #define XMSTATE_UNS_DATA 0x40 #define XMSTATE_SOL_HDR 0x80 #define XMSTATE_SOL_DATA 0x100 #define ISCSI_DEFAULT_PORT 3260 #define ISCSI_STRING_MAX 255 #define ISCSI_NODE_NAME_MAX 255 #define ISCSI_NODE_PORTAL_MAX 32 #define ISCSI_ALIAS_NAME_MAX 255 #define ISCSI_CONN_MAX 1 #define ISCSI_PORTAL_MAX 1 #define ISCSI_CONN_RCVBUF_MIN 262144 #define ISCSI_CONN_SNDBUF_MIN 262144 #define ISCSI_TEXT_SEPARATOR '=' #define ISCSI_PAD_LEN 4 #define ISCSI_DRAFT20_VERSION 0x00 #define ISCSI_R2T_MAX 16 #define ISCSI_XMIT_CMDS_MAX 128 /* must be power of 2 */ #define ISCSI_MGMT_CMDS_MAX 32 /* must be power of 2 */ #define ISCSI_MGMT_ITT_OFFSET 0x1000 #define ISCSI_SG_TABLESIZE SG_ALL #define ISCSI_CMD_PER_LUN 128 #define ISCSI_TCP_MAX_LUN 256 #define ISCSI_TCP_MAX_CMD_LEN 16 struct iscsi_queue { struct kfifo *queue; /* FIFO Queue */ void **pool; /* Pool of elements */ int max; /* Max number of elements */ }; struct iscsi_session; struct iscsi_cmd_task; struct iscsi_mgmt_task; /* Socket connection recieve helper */ struct iscsi_tcp_recv { struct iscsi_hdr *hdr; struct sk_buff *skb; int offset; int len; int hdr_offset; int copy; int copied; int padding; struct iscsi_cmd_task *ctask; /* current cmd in progress */ /* copied and flipped values */ int opcode; int flags; int cmd_status; int ahslen; int datalen; uint32_t itt; }; struct iscsi_conn { struct iscsi_hdr hdr; /* Header placeholder */ char hdrext[4*sizeof(__u16) + sizeof(__u32)]; char *data; /* Data placeholder */ int data_copied; /* iSCSI connection-wide sequencing */ uint32_t exp_statsn; int hdr_size; /* PDU Header size pre-calc. */ /* control data */ int senselen; /* is data has sense? */ int cpu; /* binded CPU */ int busy; int id; /* iSCSI CID */ struct iscsi_tcp_recv in; /* TCP receive context */ int in_progress; /* Connection state machine */ struct socket *sock; /* BSD socket layer */ struct iscsi_session *session; /* Parent session */ struct list_head item; /* item's list of connections */ struct kfifo *writequeue; /* Write response xmit queue */ struct kfifo *immqueue; /* Immediate xmit queue */ struct kfifo *mgmtqueue; /* Mgmt xmit queue */ struct kfifo *xmitqueue; /* Data-path queue */ struct work_struct xmitwork; /* per-conn. xmit workqueue */ volatile int c_stage; /* Connection state */ iscsi_cnx_t handle; /* CP connection handle */ struct iscsi_mgmt_task *login_mtask; /* mtask used for login/text */ spinlock_t lock; /* general connection lock */ volatile int suspend; /* connection suspended */ struct crypto_tfm *tx_tfm; struct crypto_tfm *rx_tfm; struct iscsi_mgmt_task *mtask; /* xmit mtask in progress */ struct iscsi_cmd_task *ctask; /* xmit ctask in progress */ struct semaphore xmitsema; wait_queue_head_t ehwait; struct iscsi_tm tmhdr; volatile int tmabort_state; struct timer_list tmabort_timer; volatile int stop_stage; /* cnx_stop() state machine */ int data_size; /* actual recv_dlength size */ /* configuration */ int max_recv_dlength; int max_xmit_dlength; int hdrdgst_en; int datadgst_en; /* old values for socket callbacks */ void (*old_data_ready)(struct sock *, int); void (*old_state_change)(struct sock *); void (*old_write_space)(struct sock *); }; struct iscsi_session { /* iSCSI session-wide sequencing */ uint32_t cmdsn; uint32_t exp_cmdsn; uint32_t max_cmdsn; /* configuration */ int initial_r2t_en; int max_r2t; int imm_data_en; int first_burst; int max_burst; int time2wait; int time2retain; int pdu_inorder_en; int dataseq_inorder_en; int erl; int ifmarker_en; int ofmarker_en; /* control data */ struct Scsi_Host *host; int id; struct iscsi_conn *leadconn; /* Leading Conn. */ spinlock_t conn_lock; spinlock_t lock; volatile int state; struct list_head item; void *auth_client; iscsi_snx_t handle; /* CP session handle */ int conn_cnt; volatile int generation; struct list_head connections; /* list of connects. */ int cmds_max; /* size of cmds array */ struct iscsi_cmd_task **cmds; /* Original Cmds arr */ struct iscsi_queue cmdpool; /* PDU's pool */ int mgmtpool_max; /* size of mgmt array */ struct iscsi_mgmt_task **mgmt_cmds; /* Original mgmt arr */ struct iscsi_queue mgmtpool; /* Mgmt PDU's pool */ }; struct iscsi_buf { struct scatterlist sg; unsigned int sent; }; struct iscsi_data_task { struct iscsi_data hdr; /* PDU */ char hdrext[sizeof(__u32)]; /* Header-Digest */ struct list_head item; /* data queue item */ }; #define ISCSI_DTASK_DEFAULT_MAX ISCSI_SG_TABLESIZE * PAGE_SIZE / 512 struct iscsi_mgmt_task { struct iscsi_hdr hdr; /* mgmt. PDU */ char hdrext[sizeof(__u32)]; /* Header-Digest */ char *data; /* mgmt payload */ volatile int xmstate; /* mgmt xmit progress */ int data_count; /* counts data to be sent */ struct iscsi_buf headbuf; /* Header Buffer */ struct iscsi_buf sendbuf; /* in progress buffer */ int sent; uint32_t itt; /* this ITT */ }; struct iscsi_r2t_info { __be32 ttt; /* copied from R2T */ __be32 exp_statsn; /* copied from R2T */ uint32_t data_length; /* copied from R2T */ uint32_t data_offset; /* copied from R2T */ struct iscsi_buf headbuf; /* Data-Out Header Buffer */ struct iscsi_buf sendbuf; /* Data-Out in progress buffer*/ int sent; /* R2T sequence progress */ int data_count; /* DATA-Out payload progress */ struct scatterlist *sg; /* per-R2T SG list */ int solicit_datasn; }; struct iscsi_cmd_task { struct iscsi_cmd hdr; /* orig. SCSI PDU */ char hdrext[4*sizeof(__u16)+ /* one AHS */ sizeof(__u32)]; /* Header-Digest */ int itt; /* this ITT */ int datasn; /* DataSN numbering */ struct iscsi_buf headbuf; /* Header Buffer */ struct iscsi_buf sendbuf; /* in progress buffer */ int sent; struct scatterlist *sg; /* per-cmd SG list */ struct scatterlist *bad_sg; /* assert statement */ int sg_count; /* SG's to process */ uint32_t unsol_datasn; uint32_t exp_r2tsn; volatile int in_progress; /* State machine */ volatile int xmstate; /* Xmit State machine */ int imm_count; /* Imm-Data bytes */ int unsol_count; /* Imm-Data-Out bytes */ int r2t_data_count; /* R2T Data-Out bytes */ int data_count; /* Remaining Data-Out */ struct scsi_cmnd *sc; /* Assoc. SCSI cmnd */ int total_length; int data_offset; struct iscsi_conn *conn; /* used connection */ struct iscsi_r2t_info *r2t; /* in progress R2T */ struct iscsi_queue r2tpool; struct kfifo *r2tqueue; struct iscsi_r2t_info **r2ts; struct list_head dataqueue; /* Data-Out dataqueue */ mempool_t *datapool; }; #endif /* ISCSI_H */ --------------010907000305040105070201-- From gnb@melbourne.sgi.com Mon Apr 18 22:56:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Apr 2005 22:56:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3J5u0WR009564 for ; Mon, 18 Apr 2005 22:56:01 -0700 Received: from hole.melbourne.sgi.com (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24517; Tue, 19 Apr 2005 15:55:35 +1000 Received: by hole.melbourne.sgi.com (Postfix, from userid 16345) id B43641C082041; Tue, 19 Apr 2005 15:55:35 +1000 (EST) Date: Tue, 19 Apr 2005 15:55:35 +1000 From: Greg Banks To: jamal Cc: Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050419055535.GA12211@sgi.com> References: <1113855967.7436.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113855967.7436.39.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@sgi.com Precedence: bulk X-list: netdev Content-Length: 1083 Lines: 30 On Mon, Apr 18, 2005 at 04:26:07PM -0400, jamal wrote: > On Mon, 2005-18-04 at 09:55 -0700, Arthur Kepner wrote: > > I'll just chime in to say that I've seen similar behavior, > > (but with a very different system.) > > It would _help_ a great deal if people collect data and post. > What was this other system? Was it running e100 as well? etc etc http://marc.theaimsgroup.com/?l=linux-netdev&m=107183822710263&w=2 > > The problem with NAPI is (quoting a co-worker) that it > > relies on an "accident of timing". > > > > geez, that almost sounds like an insult. spank your coworker for me with > something sharp (i hope s/he doesnt enjoy it) No, thank you. Maybe next time. > How do you recognize when system resources are being poorly utilized? An inordinate amount of CPU is being spent running around polling the device instead of dealing with the packets in IP, TCP and NFS land. By inordinate, we mean twice as much or more cpu% than a MIPS/Irix box with slower CPUs. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From shemminger@osdl.org Tue Apr 19 00:45:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 00:45:59 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J7jrRI018181 for ; Tue, 19 Apr 2005 00:45:53 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3J7jis4014266 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 19 Apr 2005 00:45:47 -0700 Date: Tue, 19 Apr 2005 17:44:58 +1000 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] skbuff: remove old NET_CALLER macro Message-ID: <20050419174458.0ae804f3@localhost.localdomain> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1853 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: 1599 Lines: 51 Kill NET_CALLER it causes warnings from sparse and is no longer necessary. Signed-off-by: Stephen Hemminger diff -urNp -X dontdiff ck-2.6.11/include/linux/skbuff.h net-2.6.11/include/linux/skbuff.h --- ck-2.6.11/include/linux/skbuff.h 2005-03-02 18:38:38.000000000 +1100 +++ net-2.6.11/include/linux/skbuff.h 2005-04-19 16:59:31.000000000 +1000 @@ -83,12 +83,6 @@ * Any questions? No questions, good. --ANK */ -#ifdef __i386__ -#define NET_CALLER(arg) (*(((void **)&arg) - 1)) -#else -#define NET_CALLER(arg) __builtin_return_address(0) -#endif - struct net_device; #ifdef CONFIG_NETFILTER diff -urNp -X dontdiff ck-2.6.11/net/core/skbuff.c net-2.6.11/net/core/skbuff.c --- ck-2.6.11/net/core/skbuff.c 2005-04-19 17:07:13.000000000 +1000 +++ net-2.6.11/net/core/skbuff.c 2005-04-19 17:31:38.000000000 +1000 @@ -275,9 +275,10 @@ void kfree_skbmem(struct sk_buff *skb) void __kfree_skb(struct sk_buff *skb) { - if (skb->list) { + if (unlikely(skb->list)) { printk(KERN_WARNING "Warning: kfree_skb passed an skb still " - "on a list (from %p).\n", NET_CALLER(skb)); + "on a list (from %p).\n", + __builtin_return_address(0)); BUG(); } @@ -285,10 +286,11 @@ void __kfree_skb(struct sk_buff *skb) #ifdef CONFIG_XFRM secpath_put(skb->sp); #endif - if(skb->destructor) { + if (unlikely(skb->destructor)) { if (in_irq()) printk(KERN_WARNING "Warning: kfree_skb on " - "hard IRQ %p\n", NET_CALLER(skb)); + "hard IRQ %p\n", + __builtin_return_address(0)); skb->destructor(skb); } #ifdef CONFIG_NETFILTER From herbert@gondor.apana.org.au Tue Apr 19 01:05:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 01:05:50 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J85eaW019730 for ; Tue, 19 Apr 2005 01:05:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DNnjL-0002ri-00; Tue, 19 Apr 2005 18:05:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DNnit-0001Qz-00; Tue, 19 Apr 2005 18:04:43 +1000 From: Herbert Xu To: shemminger@osdl.org (Stephen Hemminger) Subject: Re: [PATCH] skbuff: remove old NET_CALLER macro Cc: davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050419174458.0ae804f3@localhost.localdomain> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 19 Apr 2005 18:04:43 +1000 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1558 Lines: 41 Stephen Hemminger wrote: > --- ck-2.6.11/net/core/skbuff.c 2005-04-19 17:07:13.000000000 +1000 > +++ net-2.6.11/net/core/skbuff.c 2005-04-19 17:31:38.000000000 +1000 > @@ -275,9 +275,10 @@ void kfree_skbmem(struct sk_buff *skb) > > void __kfree_skb(struct sk_buff *skb) > { > - if (skb->list) { > + if (unlikely(skb->list)) { > printk(KERN_WARNING "Warning: kfree_skb passed an skb still " > - "on a list (from %p).\n", NET_CALLER(skb)); > + "on a list (from %p).\n", > + __builtin_return_address(0)); > BUG(); Why not turn this if block into a BUG_ON? The return address will be printed by BUG anyway. > @@ -285,10 +286,11 @@ void __kfree_skb(struct sk_buff *skb) > #ifdef CONFIG_XFRM > secpath_put(skb->sp); > #endif > - if(skb->destructor) { > + if (unlikely(skb->destructor)) { Are you sure that this is the less common case? > if (in_irq()) > printk(KERN_WARNING "Warning: kfree_skb on " > - "hard IRQ %p\n", NET_CALLER(skb)); > + "hard IRQ %p\n", > + __builtin_return_address(0)); Similarly, This can be turned into a WARN_ON. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hch@lst.de Tue Apr 19 04:50:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 04:50:12 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JBo1JA005489 for ; Tue, 19 Apr 2005 04:50:04 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j3JBnp6t016554 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 19 Apr 2005 13:49:51 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j3JBnoiw016552; Tue, 19 Apr 2005 13:49:50 +0200 Date: Tue, 19 Apr 2005 13:49:50 +0200 From: Christoph Hellwig To: rnic-pi-comments@opengroup.org Cc: netdev@oss.sgi.com Subject: RNIC-PI Specification Message-ID: <20050419114950.GA16258@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 1620 Lines: 34 Some comments on the RNIC-PI Draft at http://www.opengroup.org/icsc/rnicpi/uploads/40/7235/rnicpi_draft1.pdf: (1) You're repeating the common mistake of mixing up a userland API with a kernel API specification. The Linux community and many others in the free software world don't care about these kind of kernel API specifications. Please split this into an optional sub-specification if you want to be take serious. (Note: In the following points I'm completely skipping the kernel part of the specification as it is irrelevant for Linux anyway) (2) In a lot of places you're talking about "IHV private" data or functionality. This doesn't make any sense in the free software world. Please change the wording to "driver private" or just get rid of it completely - in many cases it's just papering over a bad design of the sofware stack. (3) Please don't expose the difference between driver/os/whatever private data to the API user. It's the operating systems's job to provide such abstraction. (4) Please get rid of all the ri_consumer_domain_t arguments in the userland API. They're useless and the API is already compicated enough (5) Please get rid of the IN and OUT specifiers in the API. C doesn't have any concept of in vs out pointer and it's obsufcating the API needlessly. (6) If ri_modify_rnic isn't supported in userland don't specify it. Please keep the APIs simple. I've stopped reading throught the specification after the first 50 pages, I'll take another look once the above issues are fixed. From ak@suse.de Tue Apr 19 06:54:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 06:54:07 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JDrvOa016563 for ; Tue, 19 Apr 2005 06:54:00 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id A67DC75B8; Tue, 19 Apr 2005 15:53:51 +0200 (CEST) Date: Tue, 19 Apr 2005 15:53:50 +0200 From: Andi Kleen To: netdev@oss.sgi.com, mpm@selenic.com, davem@redhat.com Subject: [PATCH] Fix deadlock in netconsole with no carrier Message-ID: <20050419135350.GH7715@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1856 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: 901 Lines: 37 I got a deadlock at boot with netconsole when the netword card did not have a cable connected. This patch fixes this by limiting the number of retries. Also when we run into the device spinlock dont poll all the time, just spin. Signed-off-by: Andi Kleen diff -u net/core/netpoll.c-o net/core/netpoll.c --- net/core/netpoll.c-o 2005-03-02 08:38:32.000000000 +0100 +++ net/core/netpoll.c 2005-04-19 15:50:42.959142733 +0200 @@ -190,9 +190,10 @@ static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) { int status; + int try = 5; repeat: - if(!np || !np->dev || !netif_running(np->dev)) { + if(try-- == 0 || !np || !np->dev || !netif_running(np->dev)) { __kfree_skb(skb); return; } @@ -218,6 +219,10 @@ /* transmit busy */ if(status) { + if (status == NETDEV_TX_LOCKED) { + try++; + goto repeat; + } netpoll_poll(np); goto repeat; } From bcrl@kvack.org Tue Apr 19 07:00:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 07:00:08 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JE01lD017270 for ; Tue, 19 Apr 2005 07:00:04 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Tue, 19 Apr 2005 09:56:48 -0400 Date: Tue, 19 Apr 2005 09:56:48 -0400 From: Benjamin LaHaise To: Adrian Bunk Cc: jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] kill include/linux/eeprom.h Message-ID: <20050419135648.GC7315@kvack.org> References: <20050419012935.GQ5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419012935.GQ5489@stusta.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 266 Lines: 8 At the very least your patch doesn't do a thorough enough job of removing the dead code -- there is no good reason to move the unused code into ns83820.c. Also, someone needs to go around refactoring eeprom code out of the network drivers at some point. -ben From nwinlu@comcast.net Tue Apr 19 07:09:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 07:10:03 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JE9rRm018098 for ; Tue, 19 Apr 2005 07:09:53 -0700 Received: from [67.168.253.73] (c-67-168-253-73.hsd1.or.comcast.net[67.168.253.73]) by comcast.net (sccrmhc11) with ESMTP id <2005041914094101100hpo5se>; Tue, 19 Apr 2005 14:09:47 +0000 Message-ID: <42651122.30906@comcast.net> Date: Tue, 19 Apr 2005 07:09:38 -0700 From: Nick Winlund User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Benjamin LaHaise CC: Adrian Bunk , jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] kill include/linux/eeprom.h References: <20050419012935.GQ5489@stusta.de> <20050419135648.GC7315@kvack.org> In-Reply-To: <20050419135648.GC7315@kvack.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nwinlu@comcast.net Precedence: bulk X-list: netdev Content-Length: 1096 Lines: 33 No I think the eeprom routine should be saved as it is now for niche vendors and hobbyists. At the very least an accessible versions repository or CVS containing all prior versions of eeprom implementation should be available, a la a new " bitkeeper " or whatever retrieval interface Linus and collaborators decide on. One project where linux+eeprom may be used: http://www.ethernut.de/api/if__var_8h.html Nut OS API int NutNetLoadConfig (CONST char *name) Load network configuration from EEPROM. int NutNetSaveConfig (void) Save network configuration in EEPROM. Nick Benjamin LaHaise wrote: > At the very least your patch doesn't do a thorough enough job of > removing the dead code -- there is no good reason to move the unused > code into ns83820.c. > > Also, someone needs to go around refactoring eeprom code out of the > network drivers at some point. > > -ben > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From itn780@yahoo.com Tue Apr 19 07:35:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 07:35:31 -0700 (PDT) Received: from smtp100.mail.sc5.yahoo.com (smtp100.mail.sc5.yahoo.com [216.136.174.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3JEZBhi019499 for ; Tue, 19 Apr 2005 07:35:22 -0700 Received: from unknown (HELO ?192.168.0.179?) (itn780@24.7.113.184 with plain) by smtp100.mail.sc5.yahoo.com with SMTP; 19 Apr 2005 14:35:08 -0000 Message-ID: <4265170E.5040102@yahoo.com> Date: Tue, 19 Apr 2005 07:34:54 -0700 From: Alex Aizman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [ANNOUNCE] Linux-iSCSI High-Performance Initiator Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itn780@yahoo.com Precedence: bulk X-list: netdev Content-Length: 708 Lines: 25 Input is needed... Two weeks ago the combined linux-iscsi and open-iscsi teams posted on lkml and linux-scsi "Linux-iSCSI High-Performance Initiator" - announcement and a set of patches. Here's the original announcement and the submission, respectively: http://marc.theaimsgroup.com/?l=linux-kernel&m=111327337005048&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=111328256211837&w=2 The entire iSCSI Initiator's data path over TCP consists of 2 files: http://www.open-iscsi.org/src/iscsi_tcp.c http://www.open-iscsi.org/src/iscsi_tcp.h (The first file is 73K, I sent yesterday - seems it didn't make it). It'd be great to get this code reviewed from the networking perspective. Thanks! Alex From SRS0+df9d41a841471456b9d8+604+infradead.org+hch@pentafluge.srs.infradead.org Tue Apr 19 07:39:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 07:39:27 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JEdLGH020142 for ; Tue, 19 Apr 2005 07:39:22 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DNtsn-0003dT-1U; Tue, 19 Apr 2005 15:39:21 +0100 Date: Tue, 19 Apr 2005 15:39:20 +0100 From: Christoph Hellwig To: Alex Aizman Cc: netdev@oss.sgi.com Subject: Re: [ANNOUNCE] Linux-iSCSI High-Performance Initiator Message-ID: <20050419143920.GA13939@infradead.org> References: <4265170E.5040102@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4265170E.5040102@yahoo.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 650 Lines: 16 On Tue, Apr 19, 2005 at 07:34:54AM -0700, Alex Aizman wrote: > The entire iSCSI Initiator's data path over TCP consists of 2 files: > > http://www.open-iscsi.org/src/iscsi_tcp.c > > http://www.open-iscsi.org/src/iscsi_tcp.h > > (The first file is 73K, I sent yesterday - seems it didn't make it). > > It'd be great to get this code reviewed from the networking perspective. Note: I've done quite a bit review from the scsi perspective, but I asked the iscsi people to send it for review over here aswell. It's doing quite a lot of deep magic in network land, and maybe some of that should move into more generic APIs in the networking layer. From oxymoron@waste.org Tue Apr 19 10:06:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 10:07:02 -0700 (PDT) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JH6udR006083 for ; Tue, 19 Apr 2005 10:06:56 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.4/8.13.4/Debian-1) with ESMTP id j3JH6oH7030513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Apr 2005 12:06:50 -0500 Received: (from oxymoron@localhost) by waste.org (8.13.4/8.13.4/Submit) id j3JH6oOJ030510; Tue, 19 Apr 2005 12:06:50 -0500 Date: Tue, 19 Apr 2005 10:06:50 -0700 From: Matt Mackall To: Andi Kleen Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH] Fix deadlock in netconsole with no carrier Message-ID: <20050419170650.GW21897@waste.org> References: <20050419135350.GH7715@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419135350.GH7715@wotan.suse.de> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1861 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: 1268 Lines: 47 On Tue, Apr 19, 2005 at 03:53:50PM +0200, Andi Kleen wrote: > > I got a deadlock at boot with netconsole when the netword card > did not have a cable connected. This patch fixes this by limiting > the number of retries. It should be waiting for carrier detect before proceeding. What NIC is that? I'm sure five retries is not enough. > Also when we run into the device spinlock dont poll all the time, > just spin. Two patches? Again, I don't think we should give up so easily. > > Signed-off-by: Andi Kleen > > > diff -u net/core/netpoll.c-o net/core/netpoll.c > --- net/core/netpoll.c-o 2005-03-02 08:38:32.000000000 +0100 > +++ net/core/netpoll.c 2005-04-19 15:50:42.959142733 +0200 > @@ -190,9 +190,10 @@ > static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) > { > int status; > + int try = 5; > > repeat: > - if(!np || !np->dev || !netif_running(np->dev)) { > + if(try-- == 0 || !np || !np->dev || !netif_running(np->dev)) { > __kfree_skb(skb); > return; > } > @@ -218,6 +219,10 @@ > > /* transmit busy */ > if(status) { > + if (status == NETDEV_TX_LOCKED) { > + try++; > + goto repeat; > + } > netpoll_poll(np); > goto repeat; > } -- Mathematics is the supreme nostalgia of our time. From davem@davemloft.net Tue Apr 19 11:41:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 11:41:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JIfhK8011508 for ; Tue, 19 Apr 2005 11:41:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DNxYq-0008Ji-00; Tue, 19 Apr 2005 11:35:00 -0700 Date: Tue, 19 Apr 2005 11:35:00 -0700 From: "David S. Miller" To: Herbert Xu Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] skbuff: remove old NET_CALLER macro Message-Id: <20050419113500.0d10c9e1.davem@davemloft.net> In-Reply-To: References: <20050419174458.0ae804f3@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 466 Lines: 12 On Tue, 19 Apr 2005 18:04:43 +1000 Herbert Xu wrote: > Why not turn this if block into a BUG_ON? The return address will be > printed by BUG anyway. Also, __builtin_return_address(0) does not work reliably on some platforms, notably MIPS. However, you are making a straight transformation so you're not making things any worse than before. Eventually, this belongs in linux/compiler.h as "function_caller()" or something like that. From davem@davemloft.net Tue Apr 19 11:43:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 11:43:13 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JIh7l2011736 for ; Tue, 19 Apr 2005 11:43:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DNxaj-0008Kj-00; Tue, 19 Apr 2005 11:36:57 -0700 Date: Tue, 19 Apr 2005 11:36:57 -0700 From: "David S. Miller" To: Greg Banks Cc: hadi@cyberus.ca, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com Subject: Re: NAPI, e100, and system performance problem Message-Id: <20050419113657.7290d26e.davem@davemloft.net> In-Reply-To: <20050419055535.GA12211@sgi.com> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 597 Lines: 15 On Tue, 19 Apr 2005 15:55:35 +1000 Greg Banks wrote: > > How do you recognize when system resources are being poorly utilized? > > An inordinate amount of CPU is being spent running around polling the > device instead of dealing with the packets in IP, TCP and NFS land. > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix > box with slower CPUs. You haven't answered the "how" yet. What tools did you run, what did those tools attempt to measure, and what results did those tools output for you so that you could determine your conclusions with such certainty? From manfred@colorfullife.com Tue Apr 19 12:17:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 12:17:40 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JJHV8g013686 for ; Tue, 19 Apr 2005 12:17:34 -0700 Received: from [127.0.0.2] (dbl [127.0.0.1]) by dbl.q-ag.de (8.13.3/8.13.3/Debian-6) with ESMTP id j3JJI7db030621; Tue, 19 Apr 2005 21:18:08 +0200 Message-ID: <42655935.9050703@colorfullife.com> Date: Tue, 19 Apr 2005 21:17:09 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: AAbdulla@nvidia.com, Netdev , Carl-Daniel Hailfinger , adq@lidskialf.net Subject: [PATCH] forcedeth Update error handling Content-Type: multipart/mixed; boundary="------------010900090107000400000007" X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 5767 Lines: 193 This is a multi-part message in MIME format. --------------010900090107000400000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jeff, Ayaz wrote an update to the error handling for forcedeth (which I modified heavily, thus all bugs are mine): The ERROR4 bit is not a fatal error, it just indicates a mismatch between the actual packet len and the len according to the 802.3 header. The patch adds proper handling. The patch also removes the code that drops all packets with RX_ERROR & (!RX_FRAMINGERR): ERROR4 errors are also not fatal. Could you add it to your tree and forward it upstream? -- Manfred --------------010900090107000400000007 Content-Type: text/plain; name="patch-forced-ERROR4" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forced-ERROR4" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 11 // EXTRAVERSION = .6-bk4 --- 2.6/drivers/net/forcedeth.c 2005-03-02 08:37:45.000000000 +0100 +++ build-2.6/drivers/net/forcedeth.c 2005-04-16 13:38:21.000000000 +0200 @@ -81,6 +81,7 @@ * cause DMA to kfree'd memory. * 0.31: 14 Nov 2004: ethtool support for getting/setting link * capabilities. + * 0.32: 16 Apr 2005: RX_ERROR4 handling added. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -92,7 +93,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.31" +#define FORCEDETH_VERSION "0.32" #define DRV_NAME "forcedeth" #include @@ -109,6 +110,7 @@ #include #include #include +#include #include #include @@ -1013,6 +1015,59 @@ static void nv_tx_timeout(struct net_dev spin_unlock_irq(&np->lock); } +/* + * Called when the nic notices a mismatch between the actual data len on the + * wire and the len indicated in the 802 header + */ +static int nv_getlen(struct net_device *dev, void *packet, int datalen) +{ + int hdrlen; /* length of the 802 header */ + int protolen; /* length as stored in the proto field */ + + /* 1) calculate len according to header */ + if ( ((struct vlan_ethhdr *)packet)->h_vlan_proto == __constant_htons(ETH_P_8021Q)) { + protolen = ntohs( ((struct vlan_ethhdr *)packet)->h_vlan_encapsulated_proto ); + hdrlen = VLAN_HLEN; + } else { + protolen = ntohs( ((struct ethhdr *)packet)->h_proto); + hdrlen = ETH_HLEN; + } + dprintk(KERN_DEBUG "%s: nv_getlen: datalen %d, protolen %d, hdrlen %d\n", + dev->name, datalen, protolen, hdrlen); + if (protolen > ETH_DATA_LEN) + return datalen; /* Value in proto field not a len, no checks possible */ + + protolen += hdrlen; + /* consistency checks: */ + if (datalen > ETH_ZLEN) { + if (datalen >= protolen) { + /* more data on wire than in 802 header, trim of + * additional data. + */ + dprintk(KERN_DEBUG "%s: nv_getlen: accepting %d bytes.\n", + dev->name, protolen); + return protolen; + } else { + /* less data on wire than mentioned in header. + * Discard the packet. + */ + dprintk(KERN_DEBUG "%s: nv_getlen: discarding long packet.\n", + dev->name); + return -1; + } + } else { + /* short packet. Accept only if 802 values are also short */ + if (protolen > ETH_ZLEN) { + dprintk(KERN_DEBUG "%s: nv_getlen: discarding short packet.\n", + dev->name); + return -1; + } + dprintk(KERN_DEBUG "%s: nv_getlen: accepting %d bytes.\n", + dev->name, datalen); + return datalen; + } +} + static void nv_rx_process(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); @@ -1064,7 +1119,7 @@ static void nv_rx_process(struct net_dev np->stats.rx_errors++; goto next_pkt; } - if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3)) { np->stats.rx_errors++; goto next_pkt; } @@ -1078,22 +1133,24 @@ static void nv_rx_process(struct net_dev np->stats.rx_errors++; goto next_pkt; } - if (Flags & NV_RX_ERROR) { - /* framing errors are soft errors, the rest is fatal. */ - if (Flags & NV_RX_FRAMINGERR) { - if (Flags & NV_RX_SUBSTRACT1) { - len--; - } - } else { + if (Flags & NV_RX_ERROR4) { + len = nv_getlen(dev, np->rx_skbuff[i]->data, len); + if (len < 0) { np->stats.rx_errors++; goto next_pkt; } } + /* framing errors are soft errors. */ + if (Flags & NV_RX_FRAMINGERR) { + if (Flags & NV_RX_SUBSTRACT1) { + len--; + } + } } else { if (!(Flags & NV_RX2_DESCRIPTORVALID)) goto next_pkt; - if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3|NV_RX2_ERROR4)) { + if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3)) { np->stats.rx_errors++; goto next_pkt; } @@ -1107,17 +1164,19 @@ static void nv_rx_process(struct net_dev np->stats.rx_errors++; goto next_pkt; } - if (Flags & NV_RX2_ERROR) { - /* framing errors are soft errors, the rest is fatal. */ - if (Flags & NV_RX2_FRAMINGERR) { - if (Flags & NV_RX2_SUBSTRACT1) { - len--; - } - } else { + if (Flags & NV_RX2_ERROR4) { + len = nv_getlen(dev, np->rx_skbuff[i]->data, len); + if (len < 0) { np->stats.rx_errors++; goto next_pkt; } } + /* framing errors are soft errors */ + if (Flags & NV_RX2_FRAMINGERR) { + if (Flags & NV_RX2_SUBSTRACT1) { + len--; + } + } Flags &= NV_RX2_CHECKSUMMASK; if (Flags == NV_RX2_CHECKSUMOK1 || Flags == NV_RX2_CHECKSUMOK2 || --------------010900090107000400000007-- From akepner@sgi.com Tue Apr 19 13:42:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 13:42:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JKfnAX020774 for ; Tue, 19 Apr 2005 13:41:49 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j3JMLpP7003550 for ; Tue, 19 Apr 2005 15:22:01 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3JKeJbT58821367 for ; Tue, 19 Apr 2005 13:40:19 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-49.corp.sgi.com [134.15.0.49]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3JKdGlV16103177; Tue, 19 Apr 2005 13:39:17 -0700 (PDT) Date: Tue, 19 Apr 2005 13:38:20 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S. Miller" cc: Greg Banks , hadi@cyberus.ca, jesse.brandeburg@intel.com, netdev@oss.sgi.com Subject: NAPI and CPU utilization [was: NAPI, e100, and system performance problem] In-Reply-To: <20050419113657.7290d26e.davem@davemloft.net> Message-ID: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <20050419113657.7290d26e.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 3120 Lines: 76 [Modified the subject line in order to not distract from Jesse's original thread.] On Tue, 19 Apr 2005, David S. Miller wrote: > On Tue, 19 Apr 2005 15:55:35 +1000 > Greg Banks wrote: > > > > How do you recognize when system resources are being poorly utilized? > > > > An inordinate amount of CPU is being spent running around polling the > > device instead of dealing with the packets in IP, TCP and NFS land. > > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix > > box with slower CPUs. > > You haven't answered the "how" yet. > > What tools did you run, what did those tools attempt to measure, and > what results did those tools output for you so that you could determine > your conclusions with such certainty? > I'm answering for myself, not Greg. Much of the data is essentially from "/proc/". (We use a nice tool called PCP to gather the data, but that's where PCP gets it, for the most part.) But I've used several other tools to gather corroborating data, including: the "kernprof" patch, "q-tools", an ad-hoc patch which used "get_cycles()" to time things which were happening while interrupts were disabled. The data acquired with all these show that NAPI causes relatively few packets to be processed per interrupt, so that expensive PIOs are relatively poorly amortized over a given amount of input from the network. (When I use "relative(ly)" above, I mean relative what we see when using Greg's interrupt coalescence patch from http://marc.theaimsgroup.com/?l=linux-netdev&m=107183822710263&w=2) For example, following is a comparison of the number of packets processed per interrupt and CPU utilization using NAPI and Greg's interrupt coalescence patch. This data is pretty old by now, it was gathered using 2.6.5 on an Altix with 1GHz CPUs using the tg3 driver doing bulk data transfer using nttcp. (I'm eyeballing the data from a set of graphs, so it's rough...) Link util [%] Packets/Interrupt CPU utilization [%] NAPI Intr Coal. NAPI Intr Coal. --------------------------------------------------------- 25 2 3.5 45 17 40 4 6 52 30 50 4 6 60 36 60 4 7 75 41 70 6 10 80 36 80 6 16 90 40 85 7 16 100 45 100 - 17 - 50 I know more recent kernels have somewhat better performance, (http://marc.theaimsgroup.com/?l=linux-netdev&m=109848080827969&w=2 helped, for one thing.) The reason that CPU utilization is so high with NAPI is that we're spinning, waiting for PIOs to flush (this can take an impressively long time when the PCI bus/bridge is busy.) I guess that some of us (at SGI) have seen this so often as a bottleneck that we're surprised that it's not more generally recognized as a problem, er, uh, "opportunity for improvement". -- Arthur From rick.jones2@hp.com Tue Apr 19 13:52:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 13:52:23 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JKqJWR021508 for ; Tue, 19 Apr 2005 13:52:19 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 42E7C1D6F; Tue, 19 Apr 2005 13:52:19 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA27969; Tue, 19 Apr 2005 13:52:18 -0700 (PDT) Message-ID: <42656F82.3030600@hp.com> Date: Tue, 19 Apr 2005 13:52:18 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arthur Kepner Cc: "David S. Miller" , Greg Banks , hadi@cyberus.ca, jesse.brandeburg@intel.com, netdev@oss.sgi.com Subject: Re: NAPI and CPU utilization [was: NAPI, e100, and system performance problem] References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <20050419113657.7290d26e.davem@davemloft.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 165 Lines: 4 One issue/caveat/whatever on those coalescing parms and such. Watch-out for their effect on request/response performance on stuff like netperf TCP_RR. rick jones From davem@davemloft.net Tue Apr 19 14:16:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 14:16:17 -0700 (PDT) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JLGCXu023009 for ; Tue, 19 Apr 2005 14:16:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DNzyh-0000yg-00; Tue, 19 Apr 2005 14:09:51 -0700 Date: Tue, 19 Apr 2005 14:09:51 -0700 From: "David S. Miller" To: Arthur Kepner Cc: gnb@sgi.com, hadi@cyberus.ca, jesse.brandeburg@intel.com, netdev@oss.sgi.com Subject: Re: NAPI and CPU utilization [was: NAPI, e100, and system performance problem] Message-Id: <20050419140951.20965099.davem@davemloft.net> In-Reply-To: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <20050419113657.7290d26e.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 863 Lines: 21 Please don't expect us to take the table of numbers seriously when it's against a more than year old kernel and without a patch you know and even explicitly mention makes this case perform significantly better. I understand your basic premise, but you're asking us to evaluate known stale performance data. Can you please get numbers against current 2.6.x kernels? It is likely that people don't care so much about this because on most systems the PIO overhead is not so pronounced as it is on your enormous Altix systems. On PCI-E and the onboard Intel e1000 stuff, PIOs are incredibly cheap (Robert Olsson posted some nice numbers not too long ago). So what I'm saying is that the numbers probably don't fall much this way on non-Altix systems. But that doesn't mean we shouldn't start using hw coalescing a little bit even with NAPI, I think we should. From bunk@stusta.de Tue Apr 19 16:57:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Apr 2005 16:57:05 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3JNuwkT030530 for ; Tue, 19 Apr 2005 16:56:59 -0700 Received: (qmail 9122 invoked from network); 19 Apr 2005 23:56:53 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Apr 2005 23:56:53 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A3A11BB5AA; Wed, 20 Apr 2005 01:56:46 +0200 (CEST) Date: Wed, 20 Apr 2005 01:56:46 +0200 From: Adrian Bunk To: Benjamin LaHaise Cc: jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] kill include/linux/eeprom.h Message-ID: <20050419235646.GY5489@stusta.de> References: <20050419012935.GQ5489@stusta.de> <20050419135648.GC7315@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419135648.GC7315@kvack.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 775 Lines: 27 On Tue, Apr 19, 2005 at 09:56:48AM -0400, Benjamin LaHaise wrote: > At the very least your patch doesn't do a thorough enough job of > removing the dead code -- there is no good reason to move the unused > code into ns83820.c. Where does my patch do this? Only the one actually used function setup_ee_mem_bitbanger is moved to ns83820.c . > Also, someone needs to go around refactoring eeprom code out of the > network drivers at some point. I have no problem with this, but it has to be done right. > -ben cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From parklee_sel@yahoo.com Wed Apr 20 17:36:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:36:28 -0700 (PDT) Received: from web51501.mail.yahoo.com (web51501.mail.yahoo.com [206.190.38.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3L0aPdD031997 for ; Wed, 20 Apr 2005 17:36:26 -0700 Received: (qmail 69277 invoked by uid 60001); 20 Apr 2005 17:29:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=jiobkB7VxlxnPE4DPZk2ZDB6n8Vw8QP6Q1Uyka128/n1+KDQILX0d0chX9+Ig/uCdpAXHfAZQE/lZ62WT0CEAXgYDQoKfXpDEw5l5uLMzId9GQrw2dK3NRqwOd/7jGSwDU3I4rjc3FofmhFIL0236Dbn8aAUu6Op1so/5sTThQk= ; Message-ID: <20050420172944.69275.qmail@web51501.mail.yahoo.com> Received: from [221.15.137.233] by web51501.mail.yahoo.com via HTTP; Wed, 20 Apr 2005 10:29:43 PDT Date: Wed, 20 Apr 2005 10:29:43 -0700 (PDT) From: Park Lee Subject: Must every packet have a creating socket? (was Re: Does a forwarded packet has a local socket with it?) To: Neil Horman Cc: jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1105 Lines: 36 On Tue, 19 Apr 2005 at 08:26, Neil Horman wrote: > Not sure what your asking here. Asking "Does these > two sockets belong to local socket?" is a pretty > meaningless question, as the terminology is > nonsensical. All sockets have a protocol associated > with them (except raw sockets, but thats another > topic). When you create a socket you associate it > with a protocol family (AF_INET, AF_INET6, > AF_NETLINK, AF_APPLETALK, etc), > a connection type (SOCK_STREAM for connection > oriented protocols, SOCK_DGRAM for connection-less > protocols), and a protocol (IPPROTO_TCP, > IPPROTO_UDP, etc). Depending on the family, type > and protocol you select, you can talk to different > systems/services. > > Does that answer your question? Thanks a lot. Can I think that every packet (e.g. IP packet) must have a corresponding creating socket? (i.e. Must every packet be created by a socket?) Is there any other way to originate a packet? Thank you. Best Regards, Park Lee __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From bcrl@kvack.org Wed Apr 20 17:35:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:35:56 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L0ZqdD031681 for ; Wed, 20 Apr 2005 17:35:53 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Wed, 20 Apr 2005 10:42:39 -0400 Date: Wed, 20 Apr 2005 10:42:39 -0400 From: Benjamin LaHaise To: Adrian Bunk Cc: jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] kill include/linux/eeprom.h Message-ID: <20050420144239.GA14757@kvack.org> References: <20050419012935.GQ5489@stusta.de> <20050419135648.GC7315@kvack.org> <20050419235646.GY5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419235646.GY5489@stusta.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 408 Lines: 11 On Wed, Apr 20, 2005 at 01:56:46AM +0200, Adrian Bunk wrote: > Where does my patch do this? > Only the one actually used function setup_ee_mem_bitbanger is moved to > ns83820.c . Which is dead code if you have removed the other users of the data structure it initialized. Please try to understand the intent of the code being cleaned up instead of just blindly deleting things, and be thorough. -ben From SRS0+3a18edad83b07605ee9a+606+infradead.org+hch@pentafluge.srs.infradead.org Wed Apr 20 17:40:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:40:20 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L0eGdD000933 for ; Wed, 20 Apr 2005 17:40:18 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DOAk4-0007a5-Mg; Wed, 20 Apr 2005 09:39:28 +0100 Date: Wed, 20 Apr 2005 09:39:28 +0100 From: Christoph Hellwig To: Adrian Bunk Cc: mlindner@syskonnect.de, rroesler@syskonnect.de, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] drivers/net/sk98lin/: possible cleanups Message-ID: <20050420083928.GA29040@infradead.org> Mail-Followup-To: Christoph Hellwig , Adrian Bunk , mlindner@syskonnect.de, rroesler@syskonnect.de, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20050420021526.GB5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420021526.GB5489@stusta.de> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 278 Lines: 7 On Wed, Apr 20, 2005 at 04:15:26AM +0200, Adrian Bunk wrote: > This patch contains the following possible cleanups: > - make needlessly global functions static > - remove unused code Not sure it's worth doing much on this, as the driver is beeing obsoleted by the skge driver. From bunk@stusta.de Wed Apr 20 17:43:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:43:13 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3L0h9dD002078 for ; Wed, 20 Apr 2005 17:43:10 -0700 Received: (qmail 26112 invoked from network); 20 Apr 2005 12:43:01 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 20 Apr 2005 12:43:01 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 8F7ABBB86A; Wed, 20 Apr 2005 14:42:57 +0200 (CEST) Date: Wed, 20 Apr 2005 14:42:57 +0200 From: Adrian Bunk To: Christoph Hellwig , mlindner@syskonnect.de, rroesler@syskonnect.de, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] drivers/net/sk98lin/: possible cleanups Message-ID: <20050420124257.GK5489@stusta.de> References: <20050420021526.GB5489@stusta.de> <20050420083928.GA29040@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420083928.GA29040@infradead.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 686 Lines: 21 On Wed, Apr 20, 2005 at 09:39:28AM +0100, Christoph Hellwig wrote: > On Wed, Apr 20, 2005 at 04:15:26AM +0200, Adrian Bunk wrote: > > This patch contains the following possible cleanups: > > - make needlessly global functions static > > - remove unused code > > Not sure it's worth doing much on this, as the driver is beeing > obsoleted by the skge driver. I know, but as long as it's in the kernel I'm sending such patches. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From wolfgang.walter@studentenwerk.mhn.de Wed Apr 20 17:49:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:49:43 -0700 (PDT) Received: from email.studentenwerk.mhn.de (dresden.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L0ncdD003757 for ; Wed, 20 Apr 2005 17:49:40 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 16D3C58002 for ; Wed, 20 Apr 2005 17:37:52 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 0820054003 for ; Wed, 20 Apr 2005 17:37:52 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: netdev@oss.sgi.com Subject: Problem with IPSEC tunnel mode Date: Wed, 20 Apr 2005 17:37:50 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200504201737.51053.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3L0ncdD003757 X-archive-position: 140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 2559 Lines: 96 Hi, we have a problem with ipsec in tunnel mode (using kernel 2.6.11.7). Scenario: 10.148.4.8/28 host A | | 10.148.4.1/28 router B 192.168.9.237/30 | internet | 192.168.77.161/30 router C 10.148.15.9/30 | | 10.148.15.10/30 router D 10.0.25.209/30 | | 10.0.25.210/30 host E There is an ipsec-tunnel between B and C to connect the subnet 10.148.4.0/28 with 10.0.25.210. When now A sends a packet to E (src=10.148.4.8, dst=10.0.25.210), we see the following: 1. packet enters B 2. packet is tunneled to C 3. packet is received by C 4. it is decrypted, you can see the decrypted paket with tcpdump and it shows up in PREROUTING (mangle-table) 5. then it disappears (it is NOT dropped by iptables) especially it is not seen in FORWARD (mangle-table). The route to E on C is a host route via 10.148.15.10. The ipsec rules on C are: src 10.148.4.0/28 dst 10.0.25.210/32 dir in priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel src 10.148.4.0/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.210/32 dir fwd priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel If we connect 10.0.25.210 directly to C using a direct host route it does not work either. If we connect 10.0.25.210 directly to C giving C 10.0.25.209/30 instead of 10.148.15.9/30 it does not work, either (ipsec-rules are unchanged on C). But if we further change the ipsec-rules on C to src 10.148.4.0/28 dst 10.0.25.208/30 dir in priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel src 10.148.4.0/28 dst 10.0.25.208/30 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.208/30 dir fwd priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel (of course we change the corresponding rule on B, too) it works: the packet is not magically dropped. Interestingly, the original scenario works fine when we use kernel 2.6.7-rc1 instead of 2.6.11.7 and setkey from ipsec-tools 0.3.3. In this case there are no fwd-rules at all as this old version of setkey does not create one. Any help ist appreciated. Please CC: me as I'm not on the list. Greetings, Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From mallikarjuna.chilakala@intel.com Wed Apr 20 17:52:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 17:52:15 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L0qBdF004453 for ; Wed, 20 Apr 2005 17:52:12 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3KHjRi5024271; Wed, 20 Apr 2005 17:45:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3KHihxk014089; Wed, 20 Apr 2005 17:45:27 GMT Received: from [134.134.3.105] ([134.134.3.105]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042010452712369 ; Wed, 20 Apr 2005 10:45:27 -0700 Date: Tue, 19 Apr 2005 22:44:12 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 2/11] ixgb: Do not set the RS bit on context descriptors Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 31 Don't set the RS bit on context descriptors, causes un-necessary bus activity Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1209,9 +1209,9 @@ ixgb_tso(struct ixgb_adapter *adapter, s | IXGB_CONTEXT_DESC_CMD_TSE | IXGB_CONTEXT_DESC_CMD_IP | IXGB_CONTEXT_DESC_CMD_TCP - | IXGB_CONTEXT_DESC_CMD_RS | IXGB_CONTEXT_DESC_CMD_IDE | (skb->len - (hdr_len))); + if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; @@ -1246,9 +1246,8 @@ ixgb_tx_csum(struct ixgb_adapter *adapte context_desc->hdr_len = 0; context_desc->mss = 0; context_desc->cmd_type_len = - cpu_to_le32(IXGB_CONTEXT_DESC_TYPE - | IXGB_TX_DESC_CMD_RS - | IXGB_TX_DESC_CMD_IDE); + cpu_to_le32(IXGB_CONTEXT_DESC_TYPE + | IXGB_TX_DESC_CMD_IDE); if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; From folkert@vanheusden.com Wed Apr 20 18:15:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 18:15:29 -0700 (PDT) Received: from keetweej.vanheusden.com (keetweej.xs4all.nl [213.84.46.114]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L1FOdD008370 for ; Wed, 20 Apr 2005 18:15:25 -0700 Received: from keetweej.intranet.vanheusden.com (keetweej.intranet.vanheusden.com [192.168.64.99]) by keetweej.vanheusden.com (Postfix) with ESMTP id E02151CA363 for ; Wed, 20 Apr 2005 20:44:21 +0200 (CEST) Date: Wed, 20 Apr 2005 20:44:21 +0200 To: netdev@oss.sgi.com Subject: [PATCH] optimize check in port-allocation code Message-ID: <20050420184419.GM20290@vanheusden.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TdMwOTenGjBWB1uY" Content-Disposition: inline Organization: www.unixexpert.nl X-Chameleon-Return-To: folkert@vanheusden.com X-Xfmail-Return-To: folkert@vanheusden.com X-Phonenumber: +31-6-41278122 X-URL: http://www.vanheusden.com/ X-PGP-KeyID: 1F28D8AE X-GPG-fingerprint: AC89 09CE 41F2 00B4 FCF2 B174 3019 0E8C 1F28 D8AE X-Key: http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x1F28D8AE Read-Receipt-To: Reply-By: Thu Apr 21 15:59:59 CEST 2005 X-MSMail-Priority: High User-Agent: Mutt/1.5.9i From: folkert@vanheusden.com X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: folkert@vanheusden.com Precedence: bulk X-list: netdev Content-Length: 3768 Lines: 105 --TdMwOTenGjBWB1uY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, In the 2.6.11 code, I found this: static int tcp_v6_get_port(struct sock *sk, unsigned short snum) also in: static int tcp_v4_get_port(struct sock *sk, unsigned short snum) { =2E.. if (snum =3D=3D 0) { int low =3D sysctl_local_port_range[0]; int high =3D sysctl_local_port_range[1]; spin_lock(&tcp_portalloc_lock); rover =3D tcp_port_rover; do { rover++; if ((rover < low) || (rover > high)) rover =3D low; That 'rover < low' check is redundant? ints are bigger then the maximum portnumber (65535) so when rover++ gets too high, the check for 'rover > high' will truncate it to low (in the next line) waaay before the int itself wraps. It is needed because tcp_port_rover might be < low before the function starts, in that case the check for high) + if (rover > high) rover =3D low; head =3D &tcp_bhash[tcp_bhashfn(rover)]; spin_lock(&head->lock); diff -uNr net/ipv6/tcp_ipv6.c.org net/ipv6/tcp_ipv6.c --- net/ipv6/tcp_ipv6.c.org 2005-03-04 22:41:44.043007791 +0100 +++ net/ipv6/tcp_ipv6.c 2005-03-04 22:42:17.604728073 +0100 @@ -139,9 +139,12 @@ int rover; spin_lock(&tcp_portalloc_lock); - rover =3D tcp_port_rover; + if (tcp_port_rover < low) + rover =3D low; + else + rover =3D tcp_port_rover; do { rover++; - if ((rover < low) || (rover > high)) + if (rover > high) rover =3D low; head =3D &tcp_bhash[tcp_bhashfn(rover)]; spin_lock(&head->lock); Signed-off-by: Folkert van Heusden (please cc me, i'm not (yet) on the list) Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)=20 a try, it brings monitoring logfiles to a different level! See =20 http://vanheusden.com/multitail/features.html for a feature-list. =20 -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! --TdMwOTenGjBWB1uY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iIMEARECAEMFAkJmowI8Gmh0dHA6Ly93d3cudmFuaGV1c2Rlbi5jb20vZGF0YS1z aWduaW5nLXdpdGgtcGdwLXBvbGljeS5odG1sAAoJEDAZDowfKNiumsUAmQEmtWwC gITCxZYScgOik1iqp/btAJ9+yC73ficq5h4fUcpVvpnB5MZldg== =IQ8N -----END PGP SIGNATURE----- --TdMwOTenGjBWB1uY-- From mallikarjuna.chilakala@intel.com Wed Apr 20 18:18:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 18:18:46 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L1IgdD009779 for ; Wed, 20 Apr 2005 18:18:43 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3KHpnYW026575; Wed, 20 Apr 2005 17:51:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3KHpfxE021464; Wed, 20 Apr 2005 17:51:49 GMT Received: from [134.134.3.105] ([134.134.3.105]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042010514614069 ; Wed, 20 Apr 2005 10:51:46 -0700 Date: Tue, 19 Apr 2005 22:50:31 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2651 Lines: 65 Performance optimizations to e100 Tx Path Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 @@ -777,7 +777,7 @@ static int e100_eeprom_save(struct nic * return 0; } -#define E100_WAIT_SCB_TIMEOUT 40 +#define E100_WAIT_SCB_TIMEOUT 20000 /* we might have to wait 100ms!!! */ static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr) { unsigned long flags; @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni * because the controller is too busy, so * let's just queue the command and try again * when another command is scheduled. */ + if(err == -ENOSPC) { + //request a reset + schedule_work(&nic->tx_timeout_task); + } break; } else { nic->cuc_cmd = cuc_resume; @@ -891,7 +895,7 @@ static void mdio_write(struct net_device static void e100_get_defaults(struct nic *nic) { - struct param_range rfds = { .min = 64, .max = 256, .count = 64 }; + struct param_range rfds = { .min = 16, .max = 256, .count = 64 }; struct param_range cbs = { .min = 64, .max = 256, .count = 64 }; pci_read_config_byte(nic->pdev, PCI_REVISION_ID, &nic->rev_id); @@ -906,8 +910,9 @@ static void e100_get_defaults(struct nic /* Quadwords to DMA into FIFO before starting frame transmit */ nic->tx_threshold = 0xE0; - nic->tx_command = cpu_to_le16(cb_tx | cb_i | cb_tx_sf | - ((nic->mac >= mac_82558_D101_A4) ? cb_cid : 0)); + /* no interrupt for every tx completion, delay = 256us if not 557*/ + nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf | + ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i)); /* Template for a freshly allocated RFD */ nic->blank_rfd.command = cpu_to_le16(cb_el); @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str struct sk_buff *skb) { cb->command = nic->tx_command; + /* interrupt every 16 packets regardless of delay */ + if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i; cb->u.tcb.tbd_array = cb->dma_addr + offsetof(struct cb, u.tcb.tbd); cb->u.tcb.tcb_byte_count = 0; cb->u.tcb.threshold = nic->tx_threshold; cb->u.tcb.tbd_count = 1; cb->u.tcb.tbd.buf_addr = cpu_to_le32(pci_map_single(nic->pdev, skb->data, skb->len, PCI_DMA_TODEVICE)); + // check for mapping failure? cb->u.tcb.tbd.size = cpu_to_le16(skb->len); } From rick.jones2@hp.com Wed Apr 20 18:20:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 18:20:10 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L1K6dD010465 for ; Wed, 20 Apr 2005 18:20:07 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 8CD53E7CE; Wed, 20 Apr 2005 18:20:05 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id SAA08890; Wed, 20 Apr 2005 18:20:04 -0700 (PDT) Message-ID: <4266FFC4.6020305@hp.com> Date: Wed, 20 Apr 2005 18:20:04 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Park Lee Cc: Neil Horman , jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Must every packet have a creating socket? (was Re: Does a forwarded packet has a local socket with it?) References: <20050420172944.69275.qmail@web51501.mail.yahoo.com> In-Reply-To: <20050420172944.69275.qmail@web51501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 632 Lines: 25 > Can I think that every packet (e.g. IP packet) must > have a corresponding creating socket? (i.e. Must every > packet be created by a socket?) No. ICMP messages come to mind - although I _suppose_ that since those are in response to other traffic, you could claim it was in response to something sent from a "socket" or "endpoint" - depends on how far away you consider it to still be from a socket. > Is there any other way to originate a packet? > > Thank you. > > Best Regards, > Park Lee > > > > __________________________________ > Do you Yahoo!? > Make Yahoo! your home page > http://www.yahoo.com/r/hs From bunk@stusta.de Wed Apr 20 19:18:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 19:18:40 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3L2IYdD015559 for ; Wed, 20 Apr 2005 19:18:35 -0700 Received: (qmail 11695 invoked from network); 20 Apr 2005 02:18:22 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 20 Apr 2005 02:18:22 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 81505BB5AA; Wed, 20 Apr 2005 04:18:20 +0200 (CEST) Date: Wed, 20 Apr 2005 04:18:20 +0200 From: Adrian Bunk To: linux@syskonnect.de Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] remove drivers/net/skfp/lnkstat.c Message-ID: <20050420021820.GE5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5800 Lines: 229 This patch removes a file that seems to be used only on AIX (sic). Signed-off-by: Adrian Bunk --- drivers/net/skfp/Makefile | 2 drivers/net/skfp/lnkstat.c | 204 ------------------------------------- 2 files changed, 1 insertion(+), 205 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile.old 2005-04-20 01:39:14.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile 2005-04-20 01:39:33.000000000 +0200 @@ -6,7 +6,7 @@ skfp-objs := skfddi.o hwmtm.o fplustm.o smt.o cfm.o \ ecm.o pcmplc.o pmf.o queue.o rmt.o \ - smtdef.o smtinit.o smttimer.o srf.o lnkstat.o \ + smtdef.o smtinit.o smttimer.o srf.o \ hwt.o drvfbi.o ess.o # NOTE: --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/lnkstat.c 2005-04-20 01:35:22.000000000 +0200 +++ /dev/null 2005-03-19 22:42:59.000000000 +0100 @@ -1,204 +0,0 @@ -/****************************************************************************** - * - * (C)Copyright 1998,1999 SysKonnect, - * a business unit of Schneider & Koch & Co. Datensysteme GmbH. - * - * See the file "skfddi.c" for further information. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * The information in this file is provided "AS IS" without warranty. - * - ******************************************************************************/ - -/* - IBM FDDI read error log function -*/ - -#include "h/types.h" -#include "h/fddi.h" -#include "h/smc.h" -#include "h/lnkstat.h" - -#ifndef lint -static const char ID_sccs[] = "@(#)lnkstat.c 1.8 97/04/11 (C) SK " ; -#endif - -#ifdef sun -#define _far -#endif - -#define EL_IS_OK(x,l) ((((int)&(((struct s_error_log *)0)->x)) + \ - sizeof(er->x)) <= l) - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_error_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error work for AIX events. - -Return smt_error_word These bits are supported: - - SMT_ERL_ALC == [PS/PA].fddiPORTLerFlag - SMT_ERL_BLC == [PB].fddiPORTLerFlag - SMT_ERL_NCC == fddiMACNotCopiedFlag - SMT_ERL_FEC == fddiMACFrameErrorFlag - - END_MANUAL_ENTRY() - */ -u_long smt_get_error_word(struct s_smc *smc) -{ - u_long st; - - /* - * smt error word low - */ - st = 0 ; - if (smc->s.sas == SMT_SAS) { - if (smc->mib.p[PS].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - } - else { - if (smc->mib.p[PA].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - if (smc->mib.p[PB].fddiPORTLerFlag) - st |= SMT_ERL_BLC ; - } - if (smc->mib.m[MAC0].fddiMACNotCopiedFlag) - st |= SMT_ERL_NCC ; /* not copied condition */ - if (smc->mib.m[MAC0].fddiMACFrameErrorFlag) - st |= SMT_ERL_FEC ; /* frame error condition */ - - return st; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT event work for AIX events. - -Return smt_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_port_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT port event work for AIX events. - -Return smt_port_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_port_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_read_errorlog(smc,p,len) - struct s_smc *smc ; - char _far *p ; - int len ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error log field for AIX events. - -Para p pointer to the error log field - len len of the error log field - -Return len used len of the error log field - - END_MANUAL_ENTRY() - */ -int smt_read_errorlog(struct s_smc *smc, char _far *p, int len) -{ - int i ; - int st ; - struct s_error_log _far *er ; - - er = (struct s_error_log _far *) p ; - if (len > sizeof(struct s_error_log)) - len = sizeof(struct s_error_log) ; - for (i = 0 ; i < len ; i++) - *p++ = 0 ; - /* - * set count - */ - if (EL_IS_OK(set_count_high,len)) { - er->set_count_low = (u_short)smc->mib.fddiSMTSetCount.count ; - er->set_count_high = - (u_short)(smc->mib.fddiSMTSetCount.count >> 16L) ; - } - /* - * aci - */ - if (EL_IS_OK(aci_id_code,len)) { - er->aci_id_code = 0 ; - } - /* - * purge counter is missed frames; 16 bits only - */ - if (EL_IS_OK(purge_frame_counter,len)) { - if (smc->mib.m[MAC0].fddiMACCopied_Ct > 0xffff) - er->purge_frame_counter = 0xffff ; - else - er->purge_frame_counter = - (u_short)smc->mib.m[MAC0].fddiMACCopied_Ct ; - } - /* - * CMT and RMT state machines - */ - if (EL_IS_OK(ecm_state,len)) - er->ecm_state = smc->mib.fddiSMTECMState ; - - if (EL_IS_OK(pcm_b_state,len)) { - if (smc->s.sas == SMT_SAS) { - er->pcm_a_state = smc->y[PS].mib->fddiPORTPCMState ; - er->pcm_b_state = 0 ; - } - else { - er->pcm_a_state = smc->y[PA].mib->fddiPORTPCMState ; - er->pcm_b_state = smc->y[PB].mib->fddiPORTPCMState ; - } - } - if (EL_IS_OK(cfm_state,len)) - er->cfm_state = smc->mib.fddiSMTCF_State ; - if (EL_IS_OK(rmt_state,len)) - er->rmt_state = smc->mib.m[MAC0].fddiMACRMTState ; - - /* - * smt error word low (we only need the low order 16 bits.) - */ - - st = smt_get_error_word(smc) & 0xffff ; - - if (EL_IS_OK(smt_error_low,len)) - er->smt_error_low = st ; - - if (EL_IS_OK(ucode_version_level,len)) - er->ucode_version_level = 0x0101 ; - return(len) ; -} - From bunk@stusta.de Wed Apr 20 19:17:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 19:17:27 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3L2HNdD015089 for ; Wed, 20 Apr 2005 19:17:23 -0700 Received: (qmail 11675 invoked from network); 20 Apr 2005 02:17:10 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 20 Apr 2005 02:17:10 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id E2B14BB5AA; Wed, 20 Apr 2005 04:17:08 +0200 (CEST) Date: Wed, 20 Apr 2005 04:17:08 +0200 From: Adrian Bunk To: linux@syskonnect.de Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/skfp/: fix LITTLE_ENDIAN Message-ID: <20050420021708.GD5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1163 Lines: 33 This patch fixes the LITTLE_ENDIAN #define. Signed-off-by: Adrian Bunk --- drivers/net/skfp/h/osdef1st.h | 2 ++ drivers/net/skfp/smt.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h.old 2005-04-20 01:22:21.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h 2005-04-20 01:23:55.000000000 +0200 @@ -20,6 +20,8 @@ // HWM (HardWare Module) Definitions // ----------------------- +#include + #ifdef __LITTLE_ENDIAN #define LITTLE_ENDIAN #else --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c.old 2005-04-20 01:26:34.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c 2005-04-20 01:26:22.000000000 +0200 @@ -86,7 +86,7 @@ static void smt_send_sif_operation(struct s_smc *smc, struct fddi_addr *dest, u_long tid, int local); #ifdef LITTLE_ENDIAN -static void smt_string_swap(void); +static void smt_string_swap(char *data, const char *format, int len); #endif static void smt_add_frame_len(SMbuf *mb, int len); static void smt_fill_una(struct s_smc *smc, struct smt_p_una *una); From bunk@stusta.de Wed Apr 20 19:15:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 19:15:47 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3L2FedD014827 for ; Wed, 20 Apr 2005 19:15:41 -0700 Received: (qmail 11601 invoked from network); 20 Apr 2005 02:15:28 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 20 Apr 2005 02:15:28 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 8EFC7BB5AA; Wed, 20 Apr 2005 04:15:26 +0200 (CEST) Date: Wed, 20 Apr 2005 04:15:26 +0200 From: Adrian Bunk To: mlindner@syskonnect.de, rroesler@syskonnect.de Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] drivers/net/sk98lin/: possible cleanups Message-ID: <20050420021526.GB5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 55778 Lines: 1984 This patch contains the following possible cleanups: - make needlessly global functions static - remove unused code Signed-off-by: Adrian Bunk --- drivers/net/sk98lin/h/skaddr.h | 48 --- drivers/net/sk98lin/h/skcsum.h | 6 drivers/net/sk98lin/h/skdrv2nd.h | 1 drivers/net/sk98lin/h/skgeinit.h | 56 --- drivers/net/sk98lin/h/skgepnmi.h | 4 drivers/net/sk98lin/h/skgesirq.h | 1 drivers/net/sk98lin/h/ski2c.h | 3 drivers/net/sk98lin/h/skvpd.h | 15 - drivers/net/sk98lin/skaddr.c | 35 +- drivers/net/sk98lin/skcsum.c | 252 ---------------- drivers/net/sk98lin/skgeinit.c | 148 --------- drivers/net/sk98lin/skgemib.c | 7 drivers/net/sk98lin/skgepnmi.c | 153 ---------- drivers/net/sk98lin/skgesirq.c | 24 - drivers/net/sk98lin/ski2c.c | 6 drivers/net/sk98lin/sklm80.c | 72 ---- drivers/net/sk98lin/skrlmt.c | 1 drivers/net/sk98lin/skvpd.c | 108 ------- drivers/net/sk98lin/skxmac2.c | 461 ------------------------------- 19 files changed, 40 insertions(+), 1361 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skaddr.h.old 2005-04-19 23:34:34.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skaddr.h 2005-04-19 23:42:57.000000000 +0200 @@ -236,18 +236,6 @@ SK_U32 PortNumber, int Flags); -extern int SkAddrXmacMcClear( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - int Flags); - -extern int SkAddrGmacMcClear( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - int Flags); - extern int SkAddrMcAdd( SK_AC *pAC, SK_IOC IoC, @@ -255,35 +243,11 @@ SK_MAC_ADDR *pMc, int Flags); -extern int SkAddrXmacMcAdd( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - SK_MAC_ADDR *pMc, - int Flags); - -extern int SkAddrGmacMcAdd( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - SK_MAC_ADDR *pMc, - int Flags); - extern int SkAddrMcUpdate( SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber); -extern int SkAddrXmacMcUpdate( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber); - -extern int SkAddrGmacMcUpdate( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber); - extern int SkAddrOverride( SK_AC *pAC, SK_IOC IoC, @@ -297,18 +261,6 @@ SK_U32 PortNumber, int NewPromMode); -extern int SkAddrXmacPromiscuousChange( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - int NewPromMode); - -extern int SkAddrGmacPromiscuousChange( - SK_AC *pAC, - SK_IOC IoC, - SK_U32 PortNumber, - int NewPromMode); - #ifndef SK_SLIM extern int SkAddrSwap( SK_AC *pAC, --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skaddr.c.old 2005-04-19 23:34:50.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skaddr.c 2005-04-20 00:01:12.000000000 +0200 @@ -87,6 +87,21 @@ static int Next0[SK_MAX_MACS] = {0}; #endif /* DEBUG */ +static int SkAddrGmacMcAdd(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber, + SK_MAC_ADDR *pMc, int Flags); +static int SkAddrGmacMcClear(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber, + int Flags); +static int SkAddrGmacMcUpdate(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber); +static int SkAddrGmacPromiscuousChange(SK_AC *pAC, SK_IOC IoC, + SK_U32 PortNumber, int NewPromMode); +static int SkAddrXmacMcAdd(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber, + SK_MAC_ADDR *pMc, int Flags); +static int SkAddrXmacMcClear(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber, + int Flags); +static int SkAddrXmacMcUpdate(SK_AC *pAC, SK_IOC IoC, SK_U32 PortNumber); +static int SkAddrXmacPromiscuousChange(SK_AC *pAC, SK_IOC IoC, + SK_U32 PortNumber, int NewPromMode); + /* functions ******************************************************************/ /****************************************************************************** @@ -372,7 +387,7 @@ * SK_ADDR_SUCCESS * SK_ADDR_ILLEGAL_PORT */ -int SkAddrXmacMcClear( +static int SkAddrXmacMcClear( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* Index of affected port */ @@ -429,7 +444,7 @@ * SK_ADDR_SUCCESS * SK_ADDR_ILLEGAL_PORT */ -int SkAddrGmacMcClear( +static int SkAddrGmacMcClear( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* Index of affected port */ @@ -519,7 +534,7 @@ * Returns: * Hash value of multicast address. */ -SK_U32 SkXmacMcHash( +static SK_U32 SkXmacMcHash( unsigned char *pMc) /* Multicast address */ { SK_U32 Idx; @@ -557,7 +572,7 @@ * Returns: * Hash value of multicast address. */ -SK_U32 SkGmacMcHash( +static SK_U32 SkGmacMcHash( unsigned char *pMc) /* Multicast address */ { SK_U32 Data; @@ -672,7 +687,7 @@ * SK_MC_ILLEGAL_ADDRESS * SK_MC_RLMT_OVERFLOW */ -int SkAddrXmacMcAdd( +static int SkAddrXmacMcAdd( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* Port Number */ @@ -778,7 +793,7 @@ * SK_MC_FILTERING_INEXACT * SK_MC_ILLEGAL_ADDRESS */ -int SkAddrGmacMcAdd( +static int SkAddrGmacMcAdd( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* Port Number */ @@ -937,7 +952,7 @@ * SK_MC_FILTERING_INEXACT * SK_ADDR_ILLEGAL_PORT */ -int SkAddrXmacMcUpdate( +static int SkAddrXmacMcUpdate( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber) /* Port Number */ @@ -1082,7 +1097,7 @@ * SK_MC_FILTERING_INEXACT * SK_ADDR_ILLEGAL_PORT */ -int SkAddrGmacMcUpdate( +static int SkAddrGmacMcUpdate( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber) /* Port Number */ @@ -1468,7 +1483,7 @@ * SK_ADDR_SUCCESS * SK_ADDR_ILLEGAL_PORT */ -int SkAddrXmacPromiscuousChange( +static int SkAddrXmacPromiscuousChange( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* port whose promiscuous mode changes */ @@ -1585,7 +1600,7 @@ * SK_ADDR_SUCCESS * SK_ADDR_ILLEGAL_PORT */ -int SkAddrGmacPromiscuousChange( +static int SkAddrGmacPromiscuousChange( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* I/O context */ SK_U32 PortNumber, /* port whose promiscuous mode changes */ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skcsum.h.old 2005-04-19 23:44:51.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skcsum.h 2005-04-19 23:45:01.000000000 +0200 @@ -203,12 +203,6 @@ unsigned Checksum2, int NetNumber); -extern void SkCsGetSendInfo( - SK_AC *pAc, - void *pIpHeader, - SKCS_PACKET_INFO *pPacketInfo, - int NetNumber); - extern void SkCsSetReceiveFlags( SK_AC *pAc, unsigned ReceiveFlags, --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skcsum.c.old 2005-04-19 23:45:09.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skcsum.c 2005-04-19 23:46:19.000000000 +0200 @@ -136,258 +136,6 @@ /****************************************************************************** * - * SkCsGetSendInfo - get checksum information for a send packet - * - * Description: - * Get all checksum information necessary to send a TCP or UDP packet. The - * function checks the IP header passed to it. If the high-level protocol - * is either TCP or UDP the pseudo header checksum is calculated and - * returned. - * - * The function returns the total length of the IP header (including any - * IP option fields), which is the same as the start offset of the IP data - * which in turn is the start offset of the TCP or UDP header. - * - * The function also returns the TCP or UDP pseudo header checksum, which - * should be used as the start value for the hardware checksum calculation. - * (Note that any actual pseudo header checksum can never calculate to - * zero.) - * - * Note: - * There is a bug in the GENESIS ASIC which may lead to wrong checksums. - * - * Arguments: - * pAc - A pointer to the adapter context struct. - * - * pIpHeader - Pointer to IP header. Must be at least the IP header *not* - * including any option fields, i.e. at least 20 bytes. - * - * Note: This pointer will be used to address 8-, 16-, and 32-bit - * variables with the respective alignment offsets relative to the pointer. - * Thus, the pointer should point to a 32-bit aligned address. If the - * target system cannot address 32-bit variables on non 32-bit aligned - * addresses, then the pointer *must* point to a 32-bit aligned address. - * - * pPacketInfo - A pointer to the packet information structure for this - * packet. Before calling this SkCsGetSendInfo(), the following field must - * be initialized: - * - * ProtocolFlags - Initialize with any combination of - * SKCS_PROTO_XXX bit flags. SkCsGetSendInfo() will only work on - * the protocols specified here. Any protocol(s) not specified - * here will be ignored. - * - * Note: Only one checksum can be calculated in hardware. Thus, if - * SKCS_PROTO_IP is specified in the 'ProtocolFlags', - * SkCsGetSendInfo() must calculate the IP header checksum in - * software. It might be a better idea to have the calling - * protocol stack calculate the IP header checksum. - * - * Returns: N/A - * On return, the following fields in 'pPacketInfo' may or may not have - * been filled with information, depending on the protocol(s) found in the - * packet: - * - * ProtocolFlags - Returns the SKCS_PROTO_XXX bit flags of the protocol(s) - * that were both requested by the caller and actually found in the packet. - * Protocol(s) not specified by the caller and/or not found in the packet - * will have their respective SKCS_PROTO_XXX bit flags reset. - * - * Note: For IP fragments, TCP and UDP packet information is ignored. - * - * IpHeaderLength - The total length in bytes of the complete IP header - * including any option fields is returned here. This is the start offset - * of the IP data, i.e. the TCP or UDP header if present. - * - * IpHeaderChecksum - If IP has been specified in the 'ProtocolFlags', the - * 16-bit Internet Checksum of the IP header is returned here. This value - * is to be stored into the packet's 'IP Header Checksum' field. - * - * PseudoHeaderChecksum - If this is a TCP or UDP packet and if TCP or UDP - * has been specified in the 'ProtocolFlags', the 16-bit Internet Checksum - * of the TCP or UDP pseudo header is returned here. - */ -void SkCsGetSendInfo( -SK_AC *pAc, /* Adapter context struct. */ -void *pIpHeader, /* IP header. */ -SKCS_PACKET_INFO *pPacketInfo, /* Packet information struct. */ -int NetNumber) /* Net number */ -{ - /* Internet Header Version found in IP header. */ - unsigned InternetHeaderVersion; - - /* Length of the IP header as found in IP header. */ - unsigned IpHeaderLength; - - /* Bit field specifiying the desired/found protocols. */ - unsigned ProtocolFlags; - - /* Next level protocol identifier found in IP header. */ - unsigned NextLevelProtocol; - - /* Length of IP data portion. */ - unsigned IpDataLength; - - /* TCP/UDP pseudo header checksum. */ - unsigned long PseudoHeaderChecksum; - - /* Pointer to next level protocol statistics structure. */ - SKCS_PROTO_STATS *NextLevelProtoStats; - - /* Temporary variable. */ - unsigned Tmp; - - Tmp = *(SK_U8 *) - SKCS_IDX(pIpHeader, SKCS_OFS_IP_HEADER_VERSION_AND_LENGTH); - - /* Get the Internet Header Version (IHV). */ - /* Note: The IHV is stored in the upper four bits. */ - - InternetHeaderVersion = Tmp >> 4; - - /* Check the Internet Header Version. */ - /* Note: We currently only support IP version 4. */ - - if (InternetHeaderVersion != 4) { /* IPv4? */ - SK_DBG_MSG(pAc, SK_DBGMOD_CSUM, SK_DBGCAT_ERR | SK_DBGCAT_TX, - ("Tx: Unknown Internet Header Version %u.\n", - InternetHeaderVersion)); - pPacketInfo->ProtocolFlags = 0; - pAc->Csum.ProtoStats[NetNumber][SKCS_PROTO_STATS_IP].TxUnableCts++; - return; - } - - /* Get the IP header length (IHL). */ - /* - * Note: The IHL is stored in the lower four bits as the number of - * 4-byte words. - */ - - IpHeaderLength = (Tmp & 0xf) * 4; - pPacketInfo->IpHeaderLength = IpHeaderLength; - - /* Check the IP header length. */ - - /* 04-Aug-1998 sw - Really check the IHL? Necessary? */ - - if (IpHeaderLength < 5*4) { - SK_DBG_MSG(pAc, SK_DBGMOD_CSUM, SK_DBGCAT_ERR | SK_DBGCAT_TX, - ("Tx: Invalid IP Header Length %u.\n", IpHeaderLength)); - pPacketInfo->ProtocolFlags = 0; - pAc->Csum.ProtoStats[NetNumber][SKCS_PROTO_STATS_IP].TxUnableCts++; - return; - } - - /* This is an IPv4 frame with a header of valid length. */ - - pAc->Csum.ProtoStats[NetNumber][SKCS_PROTO_STATS_IP].TxOkCts++; - - /* Check if we should calculate the IP header checksum. */ - - ProtocolFlags = pPacketInfo->ProtocolFlags; - - if (ProtocolFlags & SKCS_PROTO_IP) { - pPacketInfo->IpHeaderChecksum = - SkCsCalculateChecksum(pIpHeader, IpHeaderLength); - } - - /* Get the next level protocol identifier. */ - - NextLevelProtocol = - *(SK_U8 *) SKCS_IDX(pIpHeader, SKCS_OFS_IP_NEXT_LEVEL_PROTOCOL); - - /* - * Check if this is a TCP or UDP frame and if we should calculate the - * TCP/UDP pseudo header checksum. - * - * Also clear all protocol bit flags of protocols not present in the - * frame. - */ - - if ((ProtocolFlags & SKCS_PROTO_TCP) != 0 && - NextLevelProtocol == SKCS_PROTO_ID_TCP) { - /* TCP/IP frame. */ - ProtocolFlags &= SKCS_PROTO_TCP | SKCS_PROTO_IP; - NextLevelProtoStats = - &pAc->Csum.ProtoStats[NetNumber][SKCS_PROTO_STATS_TCP]; - } - else if ((ProtocolFlags & SKCS_PROTO_UDP) != 0 && - NextLevelProtocol == SKCS_PROTO_ID_UDP) { - /* UDP/IP frame. */ - ProtocolFlags &= SKCS_PROTO_UDP | SKCS_PROTO_IP; - NextLevelProtoStats = - &pAc->Csum.ProtoStats[NetNumber][SKCS_PROTO_STATS_UDP]; - } - else { - /* - * Either not a TCP or UDP frame and/or TCP/UDP processing not - * specified. - */ - pPacketInfo->ProtocolFlags = ProtocolFlags & SKCS_PROTO_IP; - return; - } - - /* Check if this is an IP fragment. */ - - /* - * Note: An IP fragment has a non-zero "Fragment Offset" field and/or - * the "More Fragments" bit set. Thus, if both the "Fragment Offset" - * and the "More Fragments" are zero, it is *not* a fragment. We can - * easily check both at the same time since they are in the same 16-bit - * word. - */ - - if ((*(SK_U16 *) - SKCS_IDX(pIpHeader, SKCS_OFS_IP_FLAGS_AND_FRAGMENT_OFFSET) & - ~SKCS_IP_DONT_FRAGMENT) != 0) { - /* IP fragment; ignore all other protocols. */ - pPacketInfo->ProtocolFlags = ProtocolFlags & SKCS_PROTO_IP; - NextLevelProtoStats->TxUnableCts++; - return; - } - - /* - * Calculate the TCP/UDP pseudo header checksum. - */ - - /* Get total length of IP header and data. */ - - IpDataLength = - *(SK_U16 *) SKCS_IDX(pIpHeader, SKCS_OFS_IP_TOTAL_LENGTH); - - /* Get length of IP data portion. */ - - IpDataLength = SKCS_NTOH16(IpDataLength) - IpHeaderLength; - - /* Calculate the sum of all pseudo header fields (16-bit). */ - - PseudoHeaderChecksum = - (unsigned long) *(SK_U16 *) SKCS_IDX(pIpHeader, - SKCS_OFS_IP_SOURCE_ADDRESS + 0) + - (unsigned long) *(SK_U16 *) SKCS_IDX(pIpHeader, - SKCS_OFS_IP_SOURCE_ADDRESS + 2) + - (unsigned long) *(SK_U16 *) SKCS_IDX(pIpHeader, - SKCS_OFS_IP_DESTINATION_ADDRESS + 0) + - (unsigned long) *(SK_U16 *) SKCS_IDX(pIpHeader, - SKCS_OFS_IP_DESTINATION_ADDRESS + 2) + - (unsigned long) SKCS_HTON16(NextLevelProtocol) + - (unsigned long) SKCS_HTON16(IpDataLength); - - /* Add-in any carries. */ - - SKCS_OC_ADD(PseudoHeaderChecksum, PseudoHeaderChecksum, 0); - - /* Add-in any new carry. */ - - SKCS_OC_ADD(pPacketInfo->PseudoHeaderChecksum, PseudoHeaderChecksum, 0); - - pPacketInfo->ProtocolFlags = ProtocolFlags; - NextLevelProtoStats->TxOkCts++; /* Success. */ -} /* SkCsGetSendInfo */ - - -/****************************************************************************** - * * SkCsGetReceiveInfo - verify checksum information for a received packet * * Description: --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgeinit.h.old 2005-04-19 23:46:57.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgeinit.h 2005-04-20 00:22:36.000000000 +0200 @@ -464,12 +464,6 @@ /* * public functions in skgeinit.c */ -extern void SkGePollRxD( - SK_AC *pAC, - SK_IOC IoC, - int Port, - SK_BOOL PollRxD); - extern void SkGePollTxD( SK_AC *pAC, SK_IOC IoC, @@ -522,10 +516,6 @@ int Led, int Mode); -extern void SkGeInitRamIface( - SK_AC *pAC, - SK_IOC IoC); - extern int SkGeInitAssignRamToQueues( SK_AC *pAC, int ActivePort, @@ -549,11 +539,6 @@ SK_IOC IoC, int Port); -extern void SkMacClearRst( - SK_AC *pAC, - SK_IOC IoC, - int Port); - extern void SkXmInitMac( SK_AC *pAC, SK_IOC IoC, @@ -580,11 +565,6 @@ SK_IOC IoC, int Port); -extern void SkMacFlushRxFifo( - SK_AC *pAC, - SK_IOC IoC, - int Port); - extern void SkMacIrq( SK_AC *pAC, SK_IOC IoC, @@ -601,12 +581,6 @@ int Port, SK_U16 IStatus); -extern void SkMacSetRxTxEn( - SK_AC *pAC, - SK_IOC IoC, - int Port, - int Para); - extern int SkMacRxTxEnable( SK_AC *pAC, SK_IOC IoC, @@ -659,16 +633,6 @@ int StartNum, int StopNum); -extern void SkXmInitDupMd( - SK_AC *pAC, - SK_IOC IoC, - int Port); - -extern void SkXmInitPauseMd( - SK_AC *pAC, - SK_IOC IoC, - int Port); - extern void SkXmAutoNegLipaXmac( SK_AC *pAC, SK_IOC IoC, @@ -729,17 +693,6 @@ int Port, SK_BOOL StartTest); -extern int SkGmEnterLowPowerMode( - SK_AC *pAC, - SK_IOC IoC, - int Port, - SK_U8 Mode); - -extern int SkGmLeaveLowPowerMode( - SK_AC *pAC, - SK_IOC IoC, - int Port); - #ifdef SK_DIAG extern void SkGePhyRead( SK_AC *pAC, @@ -782,7 +735,6 @@ /* * public functions in skgeinit.c */ -extern void SkGePollRxD(); extern void SkGePollTxD(); extern void SkGeYellowLED(); extern int SkGeCfgSync(); @@ -792,7 +744,6 @@ extern void SkGeDeInit(); extern int SkGeInitPort(); extern void SkGeXmitLED(); -extern void SkGeInitRamIface(); extern int SkGeInitAssignRamToQueues(); /* @@ -801,18 +752,15 @@ extern void SkMacRxTxDisable(); extern void SkMacSoftRst(); extern void SkMacHardRst(); -extern void SkMacClearRst(); extern void SkMacInitPhy(); extern int SkMacRxTxEnable(); extern void SkMacPromiscMode(); extern void SkMacHashing(); extern void SkMacIrqDisable(); extern void SkMacFlushTxFifo(); -extern void SkMacFlushRxFifo(); extern void SkMacIrq(); extern int SkMacAutoNegDone(); extern void SkMacAutoNegLipaPhy(); -extern void SkMacSetRxTxEn(); extern void SkXmInitMac(); extern void SkXmPhyRead(); extern void SkXmPhyWrite(); @@ -820,8 +768,6 @@ extern void SkGmPhyRead(); extern void SkGmPhyWrite(); extern void SkXmClrExactAddr(); -extern void SkXmInitDupMd(); -extern void SkXmInitPauseMd(); extern void SkXmAutoNegLipaXmac(); extern int SkXmUpdateStats(); extern int SkGmUpdateStats(); @@ -832,8 +778,6 @@ extern int SkXmOverflowStatus(); extern int SkGmOverflowStatus(); extern int SkGmCableDiagStatus(); -extern int SkGmEnterLowPowerMode(); -extern int SkGmLeaveLowPowerMode(); #ifdef SK_DIAG extern void SkGePhyRead(); --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgeinit.c.old 2005-04-19 23:47:17.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgeinit.c 2005-04-20 00:20:01.000000000 +0200 @@ -59,34 +59,6 @@ /****************************************************************************** * - * SkGePollRxD() - Enable / Disable Descriptor Polling of RxD Ring - * - * Description: - * Enable or disable the descriptor polling of the receive descriptor - * ring (RxD) for port 'Port'. - * The new configuration is *not* saved over any SkGeStopPort() and - * SkGeInitPort() calls. - * - * Returns: - * nothing - */ -void SkGePollRxD( -SK_AC *pAC, /* adapter context */ -SK_IOC IoC, /* IO context */ -int Port, /* Port Index (MAC_1 + n) */ -SK_BOOL PollRxD) /* SK_TRUE (enable pol.), SK_FALSE (disable pol.) */ -{ - SK_GEPORT *pPrt; - - pPrt = &pAC->GIni.GP[Port]; - - SK_OUT32(IoC, Q_ADDR(pPrt->PRxQOff, Q_CSR), (PollRxD) ? - CSR_ENA_POL : CSR_DIS_POL); -} /* SkGePollRxD */ - - -/****************************************************************************** - * * SkGePollTxD() - Enable / Disable Descriptor Polling of TxD Rings * * Description: @@ -952,7 +924,7 @@ * Returns: * nothing */ -void SkGeInitRamIface( +static void SkGeInitRamIface( SK_AC *pAC, /* adapter context */ SK_IOC IoC) /* IO context */ { @@ -1409,83 +1381,6 @@ } /* SkGeInit0*/ -#ifdef SK_PCI_RESET - -/****************************************************************************** - * - * SkGePciReset() - Reset PCI interface - * - * Description: - * o Read PCI configuration. - * o Change power state to 3. - * o Change power state to 0. - * o Restore PCI configuration. - * - * Returns: - * 0: Success. - * 1: Power state could not be changed to 3. - */ -static int SkGePciReset( -SK_AC *pAC, /* adapter context */ -SK_IOC IoC) /* IO context */ -{ - int i; - SK_U16 PmCtlSts; - SK_U32 Bp1; - SK_U32 Bp2; - SK_U16 PciCmd; - SK_U8 Cls; - SK_U8 Lat; - SK_U8 ConfigSpace[PCI_CFG_SIZE]; - - /* - * Note: Switching to D3 state is like a software reset. - * Switching from D3 to D0 is a hardware reset. - * We have to save and restore the configuration space. - */ - for (i = 0; i < PCI_CFG_SIZE; i++) { - SkPciReadCfgDWord(pAC, i*4, &ConfigSpace[i]); - } - - /* We know the RAM Interface Arbiter is enabled. */ - SkPciWriteCfgWord(pAC, PCI_PM_CTL_STS, PCI_PM_STATE_D3); - SkPciReadCfgWord(pAC, PCI_PM_CTL_STS, &PmCtlSts); - - if ((PmCtlSts & PCI_PM_STATE_MSK) != PCI_PM_STATE_D3) { - return(1); - } - - /* Return to D0 state. */ - SkPciWriteCfgWord(pAC, PCI_PM_CTL_STS, PCI_PM_STATE_D0); - - /* Check for D0 state. */ - SkPciReadCfgWord(pAC, PCI_PM_CTL_STS, &PmCtlSts); - - if ((PmCtlSts & PCI_PM_STATE_MSK) != PCI_PM_STATE_D0) { - return(1); - } - - /* Check PCI Config Registers. */ - SkPciReadCfgWord(pAC, PCI_COMMAND, &PciCmd); - SkPciReadCfgByte(pAC, PCI_CACHE_LSZ, &Cls); - SkPciReadCfgDWord(pAC, PCI_BASE_1ST, &Bp1); - SkPciReadCfgDWord(pAC, PCI_BASE_2ND, &Bp2); - SkPciReadCfgByte(pAC, PCI_LAT_TIM, &Lat); - - if (PciCmd != 0 || Cls != (SK_U8)0 || Lat != (SK_U8)0 || - (Bp1 & 0xfffffff0L) != 0 || Bp2 != 1) { - return(1); - } - - /* Restore PCI Config Space. */ - for (i = 0; i < PCI_CFG_SIZE; i++) { - SkPciWriteCfgDWord(pAC, i*4, ConfigSpace[i]); - } - - return(0); -} /* SkGePciReset */ - -#endif /* SK_PCI_RESET */ /****************************************************************************** * @@ -1524,10 +1419,6 @@ /* save CLK_RUN bits (YUKON-Lite) */ SK_IN16(IoC, B0_CTST, &CtrlStat); -#ifdef SK_PCI_RESET - (void)SkGePciReset(pAC, IoC); -#endif /* SK_PCI_RESET */ - /* do the SW-reset */ SK_OUT8(IoC, B0_CTST, CS_RST_SET); @@ -1991,11 +1882,6 @@ int i; SK_U16 Word; -#ifdef SK_PHY_LP_MODE - SK_U8 Byte; - SK_U16 PmCtlSts; -#endif /* SK_PHY_LP_MODE */ - #if (!defined(SK_SLIM) && !defined(VCPU)) /* ensure I2C is ready */ SkI2cWaitIrq(pAC, IoC); @@ -2010,38 +1896,6 @@ } } -#ifdef SK_PHY_LP_MODE - /* - * for power saving purposes within mobile environments - * we set the PHY to coma mode and switch to D3 power state. - */ - if (pAC->GIni.GIYukonLite && - pAC->GIni.GIChipRev == CHIP_REV_YU_LITE_A3) { - - /* for all ports switch PHY to coma mode */ - for (i = 0; i < pAC->GIni.GIMacsFound; i++) { - - SkGmEnterLowPowerMode(pAC, IoC, i, PHY_PM_DEEP_SLEEP); - } - - if (pAC->GIni.GIVauxAvail) { - /* switch power to VAUX */ - Byte = PC_VAUX_ENA | PC_VCC_ENA | PC_VAUX_ON | PC_VCC_OFF; - - SK_OUT8(IoC, B0_POWER_CTRL, Byte); - } - - /* switch to D3 state */ - SK_IN16(IoC, PCI_C(PCI_PM_CTL_STS), &PmCtlSts); - - PmCtlSts |= PCI_PM_STATE_D3; - - SK_OUT8(IoC, B2_TST_CTRL1, TST_CFG_WRITE_ON); - - SK_OUT16(IoC, PCI_C(PCI_PM_CTL_STS), PmCtlSts); - } -#endif /* SK_PHY_LP_MODE */ - /* Reset all bits in the PCI STATUS register */ /* * Note: PCI Cfg cycles cannot be used, because they are not --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgepnmi.h.old 2005-04-19 23:48:35.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgepnmi.h 2005-04-20 00:16:53.000000000 +0200 @@ -946,10 +946,6 @@ * Function prototypes */ extern int SkPnmiInit(SK_AC *pAC, SK_IOC IoC, int Level); -extern int SkPnmiGetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, void* pBuf, - unsigned int* pLen, SK_U32 Instance, SK_U32 NetIndex); -extern int SkPnmiPreSetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, - void* pBuf, unsigned int *pLen, SK_U32 Instance, SK_U32 NetIndex); extern int SkPnmiSetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, void* pBuf, unsigned int *pLen, SK_U32 Instance, SK_U32 NetIndex); extern int SkPnmiGetStruct(SK_AC *pAC, SK_IOC IoC, void* pBuf, --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgepnmi.c.old 2005-04-19 23:48:49.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgepnmi.c 2005-04-20 00:20:49.000000000 +0200 @@ -56,10 +56,6 @@ * Public Function prototypes */ int SkPnmiInit(SK_AC *pAC, SK_IOC IoC, int level); -int SkPnmiGetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, void *pBuf, - unsigned int *pLen, SK_U32 Instance, SK_U32 NetIndex); -int SkPnmiPreSetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, void *pBuf, - unsigned int *pLen, SK_U32 Instance, SK_U32 NetIndex); int SkPnmiSetVar(SK_AC *pAC, SK_IOC IoC, SK_U32 Id, void *pBuf, unsigned int *pLen, SK_U32 Instance, SK_U32 NetIndex); int SkPnmiGetStruct(SK_AC *pAC, SK_IOC IoC, void *pBuf, @@ -587,7 +583,7 @@ * exist (e.g. port instance 3 on a two port * adapter. */ -int SkPnmiGetVar( +static int SkPnmiGetVar( SK_AC *pAC, /* Pointer to adapter context */ SK_IOC IoC, /* IO context handle */ SK_U32 Id, /* Object ID that is to be processed */ @@ -629,7 +625,7 @@ * exist (e.g. port instance 3 on a two port * adapter. */ -int SkPnmiPreSetVar( +static int SkPnmiPreSetVar( SK_AC *pAC, /* Pointer to adapter context */ SK_IOC IoC, /* IO context handle */ SK_U32 Id, /* Object ID that is to be processed */ @@ -5062,9 +5058,6 @@ case OID_SKGE_SPEED_CAP: case OID_SKGE_SPEED_MODE: case OID_SKGE_SPEED_STATUS: -#ifdef SK_PHY_LP_MODE - case OID_SKGE_PHY_LP_MODE: -#endif if (*pLen < (Limit - LogPortIndex) * sizeof(SK_U8)) { *pLen = (Limit - LogPortIndex) * sizeof(SK_U8); @@ -5140,28 +5133,6 @@ Offset += sizeof(SK_U32); break; -#ifdef SK_PHY_LP_MODE - case OID_SKGE_PHY_LP_MODE: - if (!pAC->Pnmi.DualNetActiveFlag) { /* SingleNetMode */ - if (LogPortIndex == 0) { - continue; - } - else { - /* Get value for physical ports */ - PhysPortIndex = SK_PNMI_PORT_LOG2PHYS(pAC, LogPortIndex); - Val8 = (SK_U8) pAC->GIni.GP[PhysPortIndex].PPhyPowerState; - *pBufPtr = Val8; - } - } - else { /* DualNetMode */ - - Val8 = (SK_U8) pAC->GIni.GP[PhysPortIndex].PPhyPowerState; - *pBufPtr = Val8; - } - Offset += sizeof(SK_U8); - break; -#endif - case OID_SKGE_LINK_CAP: if (!pAC->Pnmi.DualNetActiveFlag) { /* SingleNetMode */ if (LogPortIndex == 0) { @@ -5478,16 +5449,6 @@ } break; -#ifdef SK_PHY_LP_MODE - case OID_SKGE_PHY_LP_MODE: - if (*pLen < Limit - LogPortIndex) { - - *pLen = Limit - LogPortIndex; - return (SK_PNMI_ERR_TOO_SHORT); - } - break; -#endif - case OID_SKGE_MTU: if (*pLen < sizeof(SK_U32)) { @@ -5845,116 +5806,6 @@ Offset += sizeof(SK_U32); break; -#ifdef SK_PHY_LP_MODE - case OID_SKGE_PHY_LP_MODE: - /* The preset ends here */ - if (Action == SK_PNMI_PRESET) { - - return (SK_PNMI_ERR_OK); - } - - if (!pAC->Pnmi.DualNetActiveFlag) { /* SingleNetMode */ - if (LogPortIndex == 0) { - Offset = 0; - continue; - } - else { - /* Set value for physical ports */ - PhysPortIndex = SK_PNMI_PORT_LOG2PHYS(pAC, LogPortIndex); - - switch (*(pBuf + Offset)) { - case 0: - /* If LowPowerMode is active, we can leave it. */ - if (pAC->GIni.GP[PhysPortIndex].PPhyPowerState) { - - Val32 = SkGmLeaveLowPowerMode(pAC, IoC, PhysPortIndex); - - if (pAC->GIni.GP[PhysPortIndex].PPhyPowerState < 3) { - - SkDrvInitAdapter(pAC); - } - break; - } - else { - *pLen = 0; - return (SK_PNMI_ERR_GENERAL); - } - case 1: - case 2: - case 3: - case 4: - /* If no LowPowerMode is active, we can enter it. */ - if (!pAC->GIni.GP[PhysPortIndex].PPhyPowerState) { - - if ((*(pBuf + Offset)) < 3) { - - SkDrvDeInitAdapter(pAC); - } - - Val32 = SkGmEnterLowPowerMode(pAC, IoC, PhysPortIndex, *pBuf); - break; - } - else { - *pLen = 0; - return (SK_PNMI_ERR_GENERAL); - } - default: - *pLen = 0; - return (SK_PNMI_ERR_BAD_VALUE); - } - } - } - else { /* DualNetMode */ - - switch (*(pBuf + Offset)) { - case 0: - /* If we are in a LowPowerMode, we can leave it. */ - if (pAC->GIni.GP[PhysPortIndex].PPhyPowerState) { - - Val32 = SkGmLeaveLowPowerMode(pAC, IoC, PhysPortIndex); - - if (pAC->GIni.GP[PhysPortIndex].PPhyPowerState < 3) { - - SkDrvInitAdapter(pAC); - } - break; - } - else { - *pLen = 0; - return (SK_PNMI_ERR_GENERAL); - } - - case 1: - case 2: - case 3: - case 4: - /* If we are not already in LowPowerMode, we can enter it. */ - if (!pAC->GIni.GP[PhysPortIndex].PPhyPowerState) { - - if ((*(pBuf + Offset)) < 3) { - - SkDrvDeInitAdapter(pAC); - } - else { - - Val32 = SkGmEnterLowPowerMode(pAC, IoC, PhysPortIndex, *pBuf); - } - break; - } - else { - *pLen = 0; - return (SK_PNMI_ERR_GENERAL); - } - - default: - *pLen = 0; - return (SK_PNMI_ERR_BAD_VALUE); - } - } - Offset += sizeof(SK_U8); - break; -#endif - default: SK_DBG_MSG(pAC, SK_DBGMOD_PNMI, SK_DBGCAT_ERR, ("MacPrivateConf: Unknown OID should be handled before set")); --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgesirq.h.old 2005-04-19 23:49:20.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skgesirq.h 2005-04-19 23:49:26.000000000 +0200 @@ -105,7 +105,6 @@ extern void SkGeSirqIsr(SK_AC *pAC, SK_IOC IoC, SK_U32 Istatus); extern int SkGeSirqEvent(SK_AC *pAC, SK_IOC IoC, SK_U32 Event, SK_EVPARA Para); -extern void SkHWLinkUp(SK_AC *pAC, SK_IOC IoC, int Port); extern void SkHWLinkDown(SK_AC *pAC, SK_IOC IoC, int Port); #endif /* _INC_SKGESIRQ_H_ */ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgesirq.c.old 2005-04-19 23:49:36.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgesirq.c 2005-04-20 00:16:42.000000000 +0200 @@ -265,7 +265,7 @@ * * Returns: N/A */ -void SkHWLinkUp( +static void SkHWLinkUp( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ @@ -612,14 +612,6 @@ * we ignore those */ pPrt->HalfDupTimerActive = SK_TRUE; -#ifdef XXX - Len = sizeof(SK_U64); - SkPnmiGetVar(pAC, IoC, OID_SKGE_STAT_TX_OCTETS, (char *)&Octets, - &Len, (SK_U32)SK_PNMI_PORT_PHYS2INST(pAC, 0), - pAC->Rlmt.Port[0].Net->NetNumber); - - pPrt->LastOctets = Octets; -#endif /* XXX */ /* Snap statistic counters */ (void)SkXmUpdateStats(pAC, IoC, 0); @@ -653,14 +645,6 @@ pPrt->PLinkModeStatus == SK_LMODE_STAT_AUTOHALF) && !pPrt->HalfDupTimerActive) { pPrt->HalfDupTimerActive = SK_TRUE; -#ifdef XXX - Len = sizeof(SK_U64); - SkPnmiGetVar(pAC, IoC, OID_SKGE_STAT_TX_OCTETS, (char *)&Octets, - &Len, (SK_U32)SK_PNMI_PORT_PHYS2INST(pAC, 1), - pAC->Rlmt.Port[1].Net->NetNumber); - - pPrt->LastOctets = Octets; -#endif /* XXX */ /* Snap statistic counters */ (void)SkXmUpdateStats(pAC, IoC, 1); @@ -2085,12 +2069,6 @@ pPrt->HalfDupTimerActive = SK_FALSE; if (pPrt->PLinkModeStatus == SK_LMODE_STAT_HALF || pPrt->PLinkModeStatus == SK_LMODE_STAT_AUTOHALF) { -#ifdef XXX - Len = sizeof(SK_U64); - SkPnmiGetVar(pAC, IoC, OID_SKGE_STAT_TX_OCTETS, (char *)&Octets, - &Len, (SK_U32)SK_PNMI_PORT_PHYS2INST(pAC, Port), - pAC->Rlmt.Port[Port].Net->NetNumber); -#endif /* XXX */ /* Snap statistic counters */ (void)SkXmUpdateStats(pAC, IoC, Port); --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/ski2c.h.old 2005-04-19 23:49:57.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/ski2c.h 2005-04-19 23:50:39.000000000 +0200 @@ -162,9 +162,6 @@ } SK_I2C; extern int SkI2cInit(SK_AC *pAC, SK_IOC IoC, int Level); -extern int SkI2cWrite(SK_AC *pAC, SK_IOC IoC, SK_U32 Data, int Dev, int Size, - int Reg, int Burst); -extern int SkI2cReadSensor(SK_AC *pAC, SK_IOC IoC, SK_SENSOR *pSen); #ifdef SK_DIAG extern SK_U32 SkI2cRead(SK_AC *pAC, SK_IOC IoC, int Dev, int Size, int Reg, int Burst); --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/ski2c.c.old 2005-04-19 23:50:12.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/ski2c.c 2005-04-20 00:19:10.000000000 +0200 @@ -396,7 +396,7 @@ * 1: error, transfer does not complete, I2C transfer * killed, wait loop terminated. */ -int SkI2cWait( +static int SkI2cWait( SK_AC *pAC, /* Adapter Context */ SK_IOC IoC, /* I/O Context */ int Event) /* complete event to wait for (I2C_READ or I2C_WRITE) */ @@ -481,7 +481,7 @@ * returns 0: success * 1: error */ -int SkI2cWrite( +static int SkI2cWrite( SK_AC *pAC, /* Adapter Context */ SK_IOC IoC, /* I/O Context */ SK_U32 I2cData, /* I2C Data to write */ @@ -538,7 +538,7 @@ * 1 if the read is completed * 0 if the read must be continued (I2C Bus still allocated) */ -int SkI2cReadSensor( +static int SkI2cReadSensor( SK_AC *pAC, /* Adapter Context */ SK_IOC IoC, /* I/O Context */ SK_SENSOR *pSen) /* Sensor to be read */ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skrlmt.c.old 2005-04-19 23:50:57.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skrlmt.c 2005-04-19 23:51:05.000000000 +0200 @@ -282,7 +282,6 @@ SK_MAC_ADDR SkRlmtMcAddr = {{0x01, 0x00, 0x5A, 0x52, 0x4C, 0x4D}}; SK_MAC_ADDR BridgeMcAddr = {{0x01, 0x80, 0xC2, 0x00, 0x00, 0x00}}; -SK_MAC_ADDR BcAddr = {{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}}; /* local variables ************************************************************/ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skvpd.h.old 2005-04-19 23:51:20.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skvpd.h 2005-04-20 00:28:16.000000000 +0200 @@ -191,14 +191,6 @@ int addr); #endif /* SKDIAG */ -extern int VpdSetupPara( - SK_AC *pAC, - const char *key, - const char *buf, - int len, - int type, - int op); - extern SK_VPD_STATUS *VpdStat( SK_AC *pAC, SK_IOC IoC); @@ -235,11 +227,6 @@ SK_AC *pAC, SK_IOC IoC); -extern void VpdErrLog( - SK_AC *pAC, - SK_IOC IoC, - char *msg); - #ifdef SKDIAG extern int VpdReadBlock( SK_AC *pAC, @@ -257,7 +244,6 @@ #endif /* SKDIAG */ #else /* SK_KR_PROTO */ extern SK_U32 VpdReadDWord(); -extern int VpdSetupPara(); extern SK_VPD_STATUS *VpdStat(); extern int VpdKeys(); extern int VpdRead(); @@ -265,7 +251,6 @@ extern int VpdWrite(); extern int VpdDelete(); extern int VpdUpdate(); -extern void VpdErrLog(); #endif /* SK_KR_PROTO */ #endif /* __INC_SKVPD_H_ */ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skvpd.c.old 2005-04-19 23:51:35.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skvpd.c 2005-04-20 00:11:20.000000000 +0200 @@ -132,65 +132,6 @@ #endif /* SKDIAG */ -#if 0 - -/* - Write the dword 'data' at address 'addr' into the VPD EEPROM, and - verify that the data is written. - - Needed Time: - -. MIN MAX -. ------------------------------------------------------------------- -. write 1.8 ms 3.6 ms -. internal write cyles 0.7 ms 7.0 ms -. ------------------------------------------------------------------- -. over all program time 2.5 ms 10.6 ms -. read 1.3 ms 2.6 ms -. ------------------------------------------------------------------- -. over all 3.8 ms 13.2 ms -. - - - Returns 0: success - 1: error, I2C transfer does not terminate - 2: error, data verify error - - */ -static int VpdWriteDWord( -SK_AC *pAC, /* pAC pointer */ -SK_IOC IoC, /* IO Context */ -int addr, /* VPD address */ -SK_U32 data) /* VPD data to write */ -{ - /* start VPD write */ - /* Don't swap here, it's a data stream of bytes */ - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_CTRL, - ("VPD write dword at addr 0x%x, data = 0x%x\n",addr,data)); - VPD_OUT32(pAC, IoC, PCI_VPD_DAT_REG, (SK_U32)data); - /* But do it here */ - addr |= VPD_WRITE; - - VPD_OUT16(pAC, IoC, PCI_VPD_ADR_REG, (SK_U16)(addr | VPD_WRITE)); - - /* this may take up to 10,6 ms */ - if (VpdWait(pAC, IoC, VPD_WRITE)) { - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_ERR, - ("Write Timed Out\n")); - return(1); - }; - - /* verify data */ - if (VpdReadDWord(pAC, IoC, addr) != data) { - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_ERR | SK_DBGCAT_FATAL, - ("Data Verify Error\n")); - return(2); - } - return(0); -} /* VpdWriteDWord */ - -#endif /* 0 */ - /* * Read one Stream of 'len' bytes of VPD data, starting at 'addr' from * or to the I2C EEPROM. @@ -728,7 +669,7 @@ * 6: fatal VPD error * */ -int VpdSetupPara( +static int VpdSetupPara( SK_AC *pAC, /* common data base */ const char *key, /* keyword to insert */ const char *buf, /* buffer with the keyword value */ @@ -1148,50 +1089,3 @@ return(0); } - - -/* - * Read the contents of the VPD EEPROM and copy it to the VPD buffer - * if not already done. If the keyword "VF" is not present it will be - * created and the error log message will be stored to this keyword. - * If "VF" is not present the error log message will be stored to the - * keyword "VL". "VL" will created or overwritten if "VF" is present. - * The VPD read/write area is saved to the VPD EEPROM. - * - * returns nothing, errors will be ignored. - */ -void VpdErrLog( -SK_AC *pAC, /* common data base */ -SK_IOC IoC, /* IO Context */ -char *msg) /* error log message */ -{ - SK_VPD_PARA *v, vf; /* VF */ - int len; - - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_TX, - ("VPD error log msg %s\n", msg)); - if ((pAC->vpd.v.vpd_status & VPD_VALID) == 0) { - if (VpdInit(pAC, IoC) != 0) { - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_ERR, - ("VPD init error\n")); - return; - } - } - - len = strlen(msg); - if (len > VPD_MAX_LEN) { - /* cut it */ - len = VPD_MAX_LEN; - } - if ((v = vpd_find_para(pAC, VPD_VF, &vf)) != NULL) { - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_TX, ("overwrite VL\n")); - (void)VpdSetupPara(pAC, VPD_VL, msg, len, VPD_RW_KEY, OWR_KEY); - } - else { - SK_DBG_MSG(pAC, SK_DBGMOD_VPD, SK_DBGCAT_TX, ("write VF\n")); - (void)VpdSetupPara(pAC, VPD_VF, msg, len, VPD_RW_KEY, ADD_KEY); - } - - (void)VpdUpdate(pAC, IoC); -} - --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skxmac2.c.old 2005-04-19 23:52:29.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skxmac2.c 2005-04-20 00:25:17.000000000 +0200 @@ -41,13 +41,13 @@ #endif #ifdef GENESIS -BCOM_HACK BcomRegA1Hack[] = { +static BCOM_HACK BcomRegA1Hack[] = { { 0x18, 0x0c20 }, { 0x17, 0x0012 }, { 0x15, 0x1104 }, { 0x17, 0x0013 }, { 0x15, 0x0404 }, { 0x17, 0x8006 }, { 0x15, 0x0132 }, { 0x17, 0x8006 }, { 0x15, 0x0232 }, { 0x17, 0x800D }, { 0x15, 0x000F }, { 0x18, 0x0420 }, { 0, 0 } }; -BCOM_HACK BcomRegC0Hack[] = { +static BCOM_HACK BcomRegC0Hack[] = { { 0x18, 0x0c20 }, { 0x17, 0x0012 }, { 0x15, 0x1204 }, { 0x17, 0x0013 }, { 0x15, 0x0A04 }, { 0x18, 0x0420 }, { 0, 0 } @@ -790,7 +790,7 @@ * Returns: * nothing */ -void SkMacFlushRxFifo( +static void SkMacFlushRxFifo( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ @@ -1231,38 +1231,6 @@ } /* SkMacHardRst */ -/****************************************************************************** - * - * SkMacClearRst() - Clear the MAC reset - * - * Description: calls a clear MAC reset routine dep. on board type - * - * Returns: - * nothing - */ -void SkMacClearRst( -SK_AC *pAC, /* adapter context */ -SK_IOC IoC, /* IO context */ -int Port) /* Port Index (MAC_1 + n) */ -{ - -#ifdef GENESIS - if (pAC->GIni.GIGenesis) { - - SkXmClearRst(pAC, IoC, Port); - } -#endif /* GENESIS */ - -#ifdef YUKON - if (pAC->GIni.GIYukon) { - - SkGmClearRst(pAC, IoC, Port); - } -#endif /* YUKON */ - -} /* SkMacClearRst */ - - #ifdef GENESIS /****************************************************************************** * @@ -1713,7 +1681,7 @@ * Returns: * nothing */ -void SkXmInitDupMd( +static void SkXmInitDupMd( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ @@ -1761,7 +1729,7 @@ * Returns: * nothing */ -void SkXmInitPauseMd( +static void SkXmInitPauseMd( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ @@ -2076,283 +2044,7 @@ } /* SkXmInitPhyBcom */ #endif /* GENESIS */ - #ifdef YUKON -#ifndef SK_SLIM -/****************************************************************************** - * - * SkGmEnterLowPowerMode() - * - * Description: - * This function sets the Marvell Alaska PHY to the low power mode - * given by parameter mode. - * The following low power modes are available: - * - * - Coma Mode (Deep Sleep): - * Power consumption: ~15 - 30 mW - * The PHY cannot wake up on its own. - * - * - IEEE 22.2.4.1.5 compatible power down mode - * Power consumption: ~240 mW - * The PHY cannot wake up on its own. - * - * - energy detect mode - * Power consumption: ~160 mW - * The PHY can wake up on its own by detecting activity - * on the CAT 5 cable. - * - * - energy detect plus mode - * Power consumption: ~150 mW - * The PHY can wake up on its own by detecting activity - * on the CAT 5 cable. - * Connected devices can be woken up by sending normal link - * pulses every one second. - * - * Note: - * - * Returns: - * 0: ok - * 1: error - */ -int SkGmEnterLowPowerMode( -SK_AC *pAC, /* adapter context */ -SK_IOC IoC, /* IO context */ -int Port, /* Port Index (e.g. MAC_1) */ -SK_U8 Mode) /* low power mode */ -{ - SK_U16 Word; - SK_U32 DWord; - SK_U8 LastMode; - int Ret = 0; - - if (pAC->GIni.GIYukonLite && - pAC->GIni.GIChipRev == CHIP_REV_YU_LITE_A3) { - - /* save current power mode */ - LastMode = pAC->GIni.GP[Port].PPhyPowerState; - pAC->GIni.GP[Port].PPhyPowerState = Mode; - - switch (Mode) { - /* coma mode (deep sleep) */ - case PHY_PM_DEEP_SLEEP: - /* setup General Purpose Control Register */ - GM_OUT16(IoC, 0, GM_GP_CTRL, GM_GPCR_FL_PASS | - GM_GPCR_SPEED_100 | GM_GPCR_AU_ALL_DIS); - - /* apply COMA mode workaround */ - SkGmPhyWrite(pAC, IoC, Port, 29, 0x001f); - SkGmPhyWrite(pAC, IoC, Port, 30, 0xfff3); - - SK_IN32(IoC, PCI_C(PCI_OUR_REG_1), &DWord); - - SK_OUT8(IoC, B2_TST_CTRL1, TST_CFG_WRITE_ON); - - /* Set PHY to Coma Mode */ - SK_OUT32(IoC, PCI_C(PCI_OUR_REG_1), DWord | PCI_PHY_COMA); - - SK_OUT8(IoC, B2_TST_CTRL1, TST_CFG_WRITE_OFF); - - break; - - /* IEEE 22.2.4.1.5 compatible power down mode */ - case PHY_PM_IEEE_POWER_DOWN: - /* - * - disable MAC 125 MHz clock - * - allow MAC power down - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - Word |= PHY_M_PC_DIS_125CLK; - Word &= ~PHY_M_PC_MAC_POW_UP; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* - * register changes must be followed by a software - * reset to take effect - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_CTRL, &Word); - Word |= PHY_CT_RESET; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_CTRL, Word); - - /* switch IEEE compatible power down mode on */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_CTRL, &Word); - Word |= PHY_CT_PDOWN; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_CTRL, Word); - break; - - /* energy detect and energy detect plus mode */ - case PHY_PM_ENERGY_DETECT: - case PHY_PM_ENERGY_DETECT_PLUS: - /* - * - disable MAC 125 MHz clock - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - Word |= PHY_M_PC_DIS_125CLK; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* activate energy detect mode 1 */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - - /* energy detect mode */ - if (Mode == PHY_PM_ENERGY_DETECT) { - Word |= PHY_M_PC_EN_DET; - } - /* energy detect plus mode */ - else { - Word |= PHY_M_PC_EN_DET_PLUS; - } - - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* - * reinitialize the PHY to force a software reset - * which is necessary after the register settings - * for the energy detect modes. - * Furthermore reinitialisation prevents that the - * PHY is running out of a stable state. - */ - SkGmInitPhyMarv(pAC, IoC, Port, SK_FALSE); - break; - - /* don't change current power mode */ - default: - pAC->GIni.GP[Port].PPhyPowerState = LastMode; - Ret = 1; - break; - } - } - /* low power modes are not supported by this chip */ - else { - Ret = 1; - } - - return(Ret); - -} /* SkGmEnterLowPowerMode */ - -/****************************************************************************** - * - * SkGmLeaveLowPowerMode() - * - * Description: - * Leave the current low power mode and switch to normal mode - * - * Note: - * - * Returns: - * 0: ok - * 1: error - */ -int SkGmLeaveLowPowerMode( -SK_AC *pAC, /* adapter context */ -SK_IOC IoC, /* IO context */ -int Port) /* Port Index (e.g. MAC_1) */ -{ - SK_U32 DWord; - SK_U16 Word; - SK_U8 LastMode; - int Ret = 0; - - if (pAC->GIni.GIYukonLite && - pAC->GIni.GIChipRev == CHIP_REV_YU_LITE_A3) { - - /* save current power mode */ - LastMode = pAC->GIni.GP[Port].PPhyPowerState; - pAC->GIni.GP[Port].PPhyPowerState = PHY_PM_OPERATIONAL_MODE; - - switch (LastMode) { - /* coma mode (deep sleep) */ - case PHY_PM_DEEP_SLEEP: - SK_IN32(IoC, PCI_C(PCI_OUR_REG_1), &DWord); - - SK_OUT8(IoC, B2_TST_CTRL1, TST_CFG_WRITE_ON); - - /* Release PHY from Coma Mode */ - SK_OUT32(IoC, PCI_C(PCI_OUR_REG_1), DWord & ~PCI_PHY_COMA); - - SK_OUT8(IoC, B2_TST_CTRL1, TST_CFG_WRITE_OFF); - - SK_IN32(IoC, B2_GP_IO, &DWord); - - /* set to output */ - DWord |= (GP_DIR_9 | GP_IO_9); - - /* set PHY reset */ - SK_OUT32(IoC, B2_GP_IO, DWord); - - DWord &= ~GP_IO_9; /* clear PHY reset (active high) */ - - /* clear PHY reset */ - SK_OUT32(IoC, B2_GP_IO, DWord); - break; - - /* IEEE 22.2.4.1.5 compatible power down mode */ - case PHY_PM_IEEE_POWER_DOWN: - /* - * - enable MAC 125 MHz clock - * - set MAC power up - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - Word &= ~PHY_M_PC_DIS_125CLK; - Word |= PHY_M_PC_MAC_POW_UP; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* - * register changes must be followed by a software - * reset to take effect - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_CTRL, &Word); - Word |= PHY_CT_RESET; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_CTRL, Word); - - /* switch IEEE compatible power down mode off */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_CTRL, &Word); - Word &= ~PHY_CT_PDOWN; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_CTRL, Word); - break; - - /* energy detect and energy detect plus mode */ - case PHY_PM_ENERGY_DETECT: - case PHY_PM_ENERGY_DETECT_PLUS: - /* - * - enable MAC 125 MHz clock - */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - Word &= ~PHY_M_PC_DIS_125CLK; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* disable energy detect mode */ - SkGmPhyRead(pAC, IoC, Port, PHY_MARV_PHY_CTRL, &Word); - Word &= ~PHY_M_PC_EN_DET_MSK; - SkGmPhyWrite(pAC, IoC, Port, PHY_MARV_PHY_CTRL, Word); - - /* - * reinitialize the PHY to force a software reset - * which is necessary after the register settings - * for the energy detect modes. - * Furthermore reinitialisation prevents that the - * PHY is running out of a stable state. - */ - SkGmInitPhyMarv(pAC, IoC, Port, SK_FALSE); - break; - - /* don't change current power mode */ - default: - pAC->GIni.GP[Port].PPhyPowerState = LastMode; - Ret = 1; - break; - } - } - /* low power modes are not supported by this chip */ - else { - Ret = 1; - } - - return(Ret); - -} /* SkGmLeaveLowPowerMode */ -#endif /* !SK_SLIM */ - - /****************************************************************************** * * SkGmInitPhyMarv() - Initialize the Marvell Phy registers @@ -3420,145 +3112,6 @@ } /* SkMacAutoNegDone */ -#ifdef GENESIS -/****************************************************************************** - * - * SkXmSetRxTxEn() - Special Set Rx/Tx Enable and some features in XMAC - * - * Description: - * sets MAC or PHY LoopBack and Duplex Mode in the MMU Command Reg. - * enables Rx/Tx - * - * Returns: N/A - */ -static void SkXmSetRxTxEn( -SK_AC *pAC, /* Adapter Context */ -SK_IOC IoC, /* IO context */ -int Port, /* Port Index (MAC_1 + n) */ -int Para) /* Parameter to set: MAC or PHY LoopBack, Duplex Mode */ -{ - SK_U16 Word; - - XM_IN16(IoC, Port, XM_MMU_CMD, &Word); - - switch (Para & (SK_MAC_LOOPB_ON | SK_MAC_LOOPB_OFF)) { - case SK_MAC_LOOPB_ON: - Word |= XM_MMU_MAC_LB; - break; - case SK_MAC_LOOPB_OFF: - Word &= ~XM_MMU_MAC_LB; - break; - } - - switch (Para & (SK_PHY_LOOPB_ON | SK_PHY_LOOPB_OFF)) { - case SK_PHY_LOOPB_ON: - Word |= XM_MMU_GMII_LOOP; - break; - case SK_PHY_LOOPB_OFF: - Word &= ~XM_MMU_GMII_LOOP; - break; - } - - switch (Para & (SK_PHY_FULLD_ON | SK_PHY_FULLD_OFF)) { - case SK_PHY_FULLD_ON: - Word |= XM_MMU_GMII_FD; - break; - case SK_PHY_FULLD_OFF: - Word &= ~XM_MMU_GMII_FD; - break; - } - - XM_OUT16(IoC, Port, XM_MMU_CMD, Word | XM_MMU_ENA_RX | XM_MMU_ENA_TX); - - /* dummy read to ensure writing */ - XM_IN16(IoC, Port, XM_MMU_CMD, &Word); - -} /* SkXmSetRxTxEn */ -#endif /* GENESIS */ - - -#ifdef YUKON -/****************************************************************************** - * - * SkGmSetRxTxEn() - Special Set Rx/Tx Enable and some features in GMAC - * - * Description: - * sets MAC LoopBack and Duplex Mode in the General Purpose Control Reg. - * enables Rx/Tx - * - * Returns: N/A - */ -static void SkGmSetRxTxEn( -SK_AC *pAC, /* Adapter Context */ -SK_IOC IoC, /* IO context */ -int Port, /* Port Index (MAC_1 + n) */ -int Para) /* Parameter to set: MAC LoopBack, Duplex Mode */ -{ - SK_U16 Ctrl; - - GM_IN16(IoC, Port, GM_GP_CTRL, &Ctrl); - - switch (Para & (SK_MAC_LOOPB_ON | SK_MAC_LOOPB_OFF)) { - case SK_MAC_LOOPB_ON: - Ctrl |= GM_GPCR_LOOP_ENA; - break; - case SK_MAC_LOOPB_OFF: - Ctrl &= ~GM_GPCR_LOOP_ENA; - break; - } - - switch (Para & (SK_PHY_FULLD_ON | SK_PHY_FULLD_OFF)) { - case SK_PHY_FULLD_ON: - Ctrl |= GM_GPCR_DUP_FULL; - break; - case SK_PHY_FULLD_OFF: - Ctrl &= ~GM_GPCR_DUP_FULL; - break; - } - - GM_OUT16(IoC, Port, GM_GP_CTRL, (SK_U16)(Ctrl | GM_GPCR_RX_ENA | - GM_GPCR_TX_ENA)); - - /* dummy read to ensure writing */ - GM_IN16(IoC, Port, GM_GP_CTRL, &Ctrl); - -} /* SkGmSetRxTxEn */ -#endif /* YUKON */ - - -#ifndef SK_SLIM -/****************************************************************************** - * - * SkMacSetRxTxEn() - Special Set Rx/Tx Enable and parameters - * - * Description: calls the Special Set Rx/Tx Enable routines dep. on board type - * - * Returns: N/A - */ -void SkMacSetRxTxEn( -SK_AC *pAC, /* Adapter Context */ -SK_IOC IoC, /* IO context */ -int Port, /* Port Index (MAC_1 + n) */ -int Para) -{ -#ifdef GENESIS - if (pAC->GIni.GIGenesis) { - - SkXmSetRxTxEn(pAC, IoC, Port, Para); - } -#endif /* GENESIS */ - -#ifdef YUKON - if (pAC->GIni.GIYukon) { - - SkGmSetRxTxEn(pAC, IoC, Port, Para); - } -#endif /* YUKON */ - -} /* SkMacSetRxTxEn */ -#endif /* !SK_SLIM */ - - /****************************************************************************** * * SkMacRxTxEnable() - Enable Rx/Tx activity if port is up @@ -3976,7 +3529,7 @@ * Returns: * nothing */ -void SkXmIrq( +static void SkXmIrq( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ @@ -4112,7 +3665,7 @@ * Returns: * nothing */ -void SkGmIrq( +static void SkGmIrq( SK_AC *pAC, /* adapter context */ SK_IOC IoC, /* IO context */ int Port) /* Port Index (MAC_1 + n) */ --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skdrv2nd.h.old 2005-04-20 00:12:04.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/h/skdrv2nd.h 2005-04-20 00:12:10.000000000 +0200 @@ -60,7 +60,6 @@ extern int SkPciReadCfgDWord(SK_AC*, int, SK_U32*); extern int SkPciReadCfgWord(SK_AC*, int, SK_U16*); extern int SkPciReadCfgByte(SK_AC*, int, SK_U8*); -extern int SkPciWriteCfgDWord(SK_AC*, int, SK_U32); extern int SkPciWriteCfgWord(SK_AC*, int, SK_U16); extern int SkPciWriteCfgByte(SK_AC*, int, SK_U8); extern int SkDrvEvent(SK_AC*, SK_IOC IoC, SK_U32, SK_EVPARA); --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/sklm80.c.old 2005-04-20 00:17:33.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/sklm80.c 2005-04-20 00:18:15.000000000 +0200 @@ -34,79 +34,7 @@ #include "h/lm80.h" #include "h/skdrv2nd.h" /* Adapter Control- and Driver specific Def. */ -#ifdef SK_DIAG -#define BREAK_OR_WAIT(pAC,IoC,Event) SkI2cWait(pAC,IoC,Event) -#else /* nSK_DIAG */ #define BREAK_OR_WAIT(pAC,IoC,Event) break -#endif /* nSK_DIAG */ - -#ifdef SK_DIAG -/* - * read the register 'Reg' from the device 'Dev' - * - * return read error -1 - * success the read value - */ -int SkLm80RcvReg( -SK_IOC IoC, /* Adapter Context */ -int Dev, /* I2C device address */ -int Reg) /* register to read */ -{ - int Val = 0; - int TempExt; - - /* Signal device number */ - if (SkI2cSndDev(IoC, Dev, I2C_WRITE)) { - return(-1); - } - - if (SkI2cSndByte(IoC, Reg)) { - return(-1); - } - - /* repeat start */ - if (SkI2cSndDev(IoC, Dev, I2C_READ)) { - return(-1); - } - - switch (Reg) { - case LM80_TEMP_IN: - Val = (int)SkI2cRcvByte(IoC, 1); - - /* First: correct the value: it might be negative */ - if ((Val & 0x80) != 0) { - /* Value is negative */ - Val = Val - 256; - } - Val = Val * SK_LM80_TEMP_LSB; - SkI2cStop(IoC); - - TempExt = (int)SkLm80RcvReg(IoC, LM80_ADDR, LM80_TEMP_CTRL); - - if (Val > 0) { - Val += ((TempExt >> 7) * SK_LM80_TEMPEXT_LSB); - } - else { - Val -= ((TempExt >> 7) * SK_LM80_TEMPEXT_LSB); - } - return(Val); - break; - case LM80_VT0_IN: - case LM80_VT1_IN: - case LM80_VT2_IN: - case LM80_VT3_IN: - Val = (int)SkI2cRcvByte(IoC, 1) * SK_LM80_VT_LSB; - break; - - default: - Val = (int)SkI2cRcvByte(IoC, 1); - break; - } - - SkI2cStop(IoC); - return(Val); -} -#endif /* SK_DIAG */ /* * read a sensors value (LM80 specific) --- linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgemib.c.old 2005-04-20 00:20:11.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/sk98lin/skgemib.c 2005-04-20 00:20:17.000000000 +0200 @@ -871,13 +871,6 @@ sizeof(SK_PNMI_CONF), SK_PNMI_OFF(Conf) + SK_PNMI_CNF_OFF(ConfPhyType), SK_PNMI_RO, MacPrivateConf, 0}, -#ifdef SK_PHY_LP_MODE - {OID_SKGE_PHY_LP_MODE, - SK_PNMI_MAC_ENTRIES, - sizeof(SK_PNMI_CONF), - SK_PNMI_OFF(Conf) + SK_PNMI_CNF_OFF(ConfPhyMode), - SK_PNMI_RW, MacPrivateConf, 0}, -#endif {OID_SKGE_LINK_CAP, SK_PNMI_MAC_ENTRIES, sizeof(SK_PNMI_CONF), From hadi@cyberus.ca Wed Apr 20 19:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 19:41:02 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L2ewdD018619 for ; Wed, 20 Apr 2005 19:40:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DOGvT-0006vV-6h for netdev@oss.sgi.com; Wed, 20 Apr 2005 11:15:39 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOGvP-00078c-43; Wed, 20 Apr 2005 11:15:35 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Greg Banks Cc: "David S. Miller" , akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com In-Reply-To: <20050420145629.GH19415@sgi.com> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <20050419113657.7290d26e.davem@davemloft.net> <20050420145629.GH19415@sgi.com> Content-Type: text/plain Organization: unknown Date: Wed, 20 Apr 2005 11:15:31 -0400 Message-Id: <1114010131.8916.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 179 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: 1413 Lines: 39 On Thu, 2005-21-04 at 00:56 +1000, Greg Banks wrote: > We have a stats package called PCP (see oss.sgi.com) which samples > all kinds of stuff out of /proc at a configurable polling frequency, > default 2 sec, and provides scrolling graphs. We've also done some > profiling work using the SGI kernprof patch in 2.4 kernels and > oprofile in 2.6 kernels. > this may not be sufficient to debug; that PCP sounds like a hog in its own merit polling /proc. Actually, lets start by saying this: If you problem is PIO being too expensive on your machines, then the solution maybe for you to set coalescing parameters appropriately. This is a known issue - "fixing NAPI" requires complicating things for the majority who dont have the same problem as you. The issue pointed out by Rick Jones that you sacrifice latency is still valid. Additionaly, with many NICs in place, coalescing is not gonna cut it. Having said that - here are some items that will be useful to collect before and after a run: - netstat -s output - /proc/net/softnet_stat - ifconfig output - tc -s qdisc on the interfaces - oprofile - any other thing you could come up with like some of the stuff you posted recently on how many packets/interupt are processed with and without NAPI. - preferably run UDP tests so we dont have to think hard about stats like retransmits etc. - And as pointed by Dave, pick the latest kernel. cheers, jamal From rddunlap@osdl.org Wed Apr 20 19:42:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 19:42:13 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L2g8dD018700 for ; Wed, 20 Apr 2005 19:42:09 -0700 Received: from midway.verizon.net (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3L2g5s3032459 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Apr 2005 19:42:06 -0700 Date: Wed, 20 Apr 2005 19:42:00 -0700 From: "Randy.Dunlap" To: Adrian Bunk Cc: linux@syskonnect.de, jgarzik@pobox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] drivers/net/skfp/: fix LITTLE_ENDIAN Message-Id: <20050420194200.4354510e.rddunlap@osdl.org> In-Reply-To: <20050420021708.GD5489@stusta.de> References: <20050420021708.GD5489@stusta.de> Organization: OSDL X-Mailer: Sylpheed version 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1307 Lines: 35 On Wed, 20 Apr 2005 04:17:08 +0200 Adrian Bunk wrote: | This patch fixes the LITTLE_ENDIAN #define. and a function prototype. | Signed-off-by: Adrian Bunk | | --- | | drivers/net/skfp/h/osdef1st.h | 2 ++ | drivers/net/skfp/smt.c | 2 +- | 2 files changed, 3 insertions(+), 1 deletion(-) | | --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h.old 2005-04-20 01:22:21.000000000 +0200 | +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h 2005-04-20 01:23:55.000000000 +0200 | @@ -20,6 +20,8 @@ | // HWM (HardWare Module) Definitions | // ----------------------- | | +#include | + | #ifdef __LITTLE_ENDIAN | #define LITTLE_ENDIAN | #else | --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c.old 2005-04-20 01:26:34.000000000 +0200 | +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c 2005-04-20 01:26:22.000000000 +0200 | @@ -86,7 +86,7 @@ | static void smt_send_sif_operation(struct s_smc *smc, struct fddi_addr *dest, | u_long tid, int local); | #ifdef LITTLE_ENDIAN | -static void smt_string_swap(void); | +static void smt_string_swap(char *data, const char *format, int len); | #endif | static void smt_add_frame_len(SMbuf *mb, int len); | static void smt_fill_una(struct s_smc *smc, struct smt_p_una *una); From rddunlap@osdl.org Wed Apr 20 20:05:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 20:05:36 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L35WdD020795 for ; Wed, 20 Apr 2005 20:05:33 -0700 Received: from midway.verizon.net (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3L35Us3001701 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Apr 2005 20:05:30 -0700 Date: Wed, 20 Apr 2005 20:05:24 -0700 From: "Randy.Dunlap" To: Malli Chilakala Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Message-Id: <20050420200524.3e284eb9.rddunlap@osdl.org> In-Reply-To: References: Organization: OSDL X-Mailer: Sylpheed version 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 2191 Lines: 62 On Tue, 19 Apr 2005 22:50:31 -0700 (PDT) Malli Chilakala wrote: | Performance optimizations to e100 Tx Path | | Signed-off-by: Mallikarjuna R Chilakala | Signed-off-by: Ganesh Venkatesan | Signed-off-by: John Ronciak | diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new | --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 | +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 | @@ -777,7 +777,7 @@ static int e100_eeprom_save(struct nic * | return 0; | } | | -#define E100_WAIT_SCB_TIMEOUT 40 | +#define E100_WAIT_SCB_TIMEOUT 20000 /* we might have to wait 100ms!!! */ What correlation is there between 20000 and 100 ms ? | static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr) | { | unsigned long flags; | @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni | * because the controller is too busy, so | * let's just queue the command and try again | * when another command is scheduled. */ | + if(err == -ENOSPC) { if (err == -ENOSPC) { is preferred (with space after if). (same comment for below) | + //request a reset Kernel comment style is /* ... */, not //. (same comment for below) | + schedule_work(&nic->tx_timeout_task); | + } | break; | } else { | nic->cuc_cmd = cuc_resume; | @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str | struct sk_buff *skb) | { | cb->command = nic->tx_command; | + /* interrupt every 16 packets regardless of delay */ | + if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i; Don't put if() and statement on one line, please. It tends to hide code unintentionally. | cb->u.tcb.tbd_array = cb->dma_addr + offsetof(struct cb, u.tcb.tbd); | cb->u.tcb.tcb_byte_count = 0; | cb->u.tcb.threshold = nic->tx_threshold; | cb->u.tcb.tbd_count = 1; | cb->u.tcb.tbd.buf_addr = cpu_to_le32(pci_map_single(nic->pdev, | skb->data, skb->len, PCI_DMA_TODEVICE)); | + // check for mapping failure? | cb->u.tcb.tbd.size = cpu_to_le16(skb->len); | } --- ~Randy From herbert@gondor.apana.org.au Wed Apr 20 20:08:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 20:08:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L389dE021369 for ; Wed, 20 Apr 2005 20:08:12 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOMjN-0001CC-00; Thu, 21 Apr 2005 07:27:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOMiS-0007Oq-00; Thu, 21 Apr 2005 07:26:36 +1000 Date: Thu, 21 Apr 2005 07:26:36 +1000 To: Paul Wouters Cc: "David S. Miller" , dev@lists.openswan.org, Michael Richardson , netdev@oss.sgi.com Subject: Re: [Openswan dev] Re: [IPSEC] COW skb header in UDP decap Message-ID: <20050420212636.GA28424@gondor.apana.org.au> References: <21730.1112984853@marajade.sandelman.ottawa.on.ca> <20050409010124.GA22059@gondor.apana.org.au> <20050419231741.64e44443.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 376 Lines: 10 On Wed, Apr 20, 2005 at 04:10:01PM +0200, Paul Wouters wrote: > > Which reminds me. I still have hanging 'ip xfrm state' commands on 2.6.11.7 What does strace say? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From shemminger@osdl.org Wed Apr 20 20:21:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 20:21:11 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L3L5dD027084 for ; Wed, 20 Apr 2005 20:21:07 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3L3L0s4002725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Apr 2005 20:21:03 -0700 Date: Thu, 21 Apr 2005 13:20:20 +1000 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen Message-ID: <20050421132020.41858bc4@localhost.localdomain> In-Reply-To: <42666098.5060409@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 185 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: 959 Lines: 25 On Wed, 20 Apr 2005 16:00:56 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > There may be no sane way to do duplication without that. > > This way doesn't work properly either. The classful qdiscs don't care > about their own q.qlen and just try to dequeue, if successful they > decrement q.qlen. When duplicating packets in an inner qdisc the > top-level qdisc's q.qlen will turn negative at some point (it's > unsigned, but returned as int from qdisc_restart) and will cause > qdisc_run() to spin forever. So duplication is a no go... Unless there is a different way of accounting for qlen (like a callback). > > Other ways like injecting > > packets again at top of queue with a thread/tasklet seem rather gross > > Injecting at the top is also problematic because it needs to > follow the same classification-path as the first packet, which > can only be guarenteed with stateless classification. > > Regards > Patrick From kaber@trash.net Wed Apr 20 20:26:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 20:26:48 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L3QidD027864 for ; Wed, 20 Apr 2005 20:26:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOFlA-0007bJ-QL; Wed, 20 Apr 2005 16:00:56 +0200 Message-ID: <42666098.5060409@trash.net> Date: Wed, 20 Apr 2005 16:00:56 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> In-Reply-To: <20050419110639.47767113@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/843/Wed Apr 20 12:49:20 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 742 Lines: 19 Stephen Hemminger wrote: > There may be no sane way to do duplication without that. This way doesn't work properly either. The classful qdiscs don't care about their own q.qlen and just try to dequeue, if successful they decrement q.qlen. When duplicating packets in an inner qdisc the top-level qdisc's q.qlen will turn negative at some point (it's unsigned, but returned as int from qdisc_restart) and will cause qdisc_run() to spin forever. > Other ways like injecting > packets again at top of queue with a thread/tasklet seem rather gross Injecting at the top is also problematic because it needs to follow the same classification-path as the first packet, which can only be guarenteed with stateless classification. Regards Patrick From herbert@gondor.apana.org.au Wed Apr 20 22:09:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Apr 2005 22:09:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3L593dD001583 for ; Wed, 20 Apr 2005 22:09:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOTvf-0003QT-00; Thu, 21 Apr 2005 15:08:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOTvD-00061Q-00; Thu, 21 Apr 2005 15:08:15 +1000 Date: Thu, 21 Apr 2005 15:08:15 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NET] Add missing newline for skb_*_panic Message-ID: <20050421050815.GA23133@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/845/Wed Apr 20 20:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1414 Lines: 47 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here is a trivial patch to make the skb_under_panic/skb_over_panic messages to look nicer. As it is their printk is joined onto the first line of the BUG output because of a missing newline. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/skbuff.c 1.44 vs edited ===== --- 1.44/net/core/skbuff.c 2005-03-12 07:32:26 +11:00 +++ edited/net/core/skbuff.c 2005-04-21 15:06:12 +10:00 @@ -86,7 +86,7 @@ */ void skb_over_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:over: %p:%d put:%d dev:%s", + printk(KERN_INFO "skput:over: %p:%d put:%d dev:%s\n", here, skb->len, sz, skb->dev ? skb->dev->name : ""); BUG(); } @@ -102,7 +102,7 @@ void skb_under_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:under: %p:%d put:%d dev:%s", + printk(KERN_INFO "skput:under: %p:%d put:%d dev:%s\n", here, skb->len, sz, skb->dev ? skb->dev->name : ""); BUG(); } --9jxsPFA5p3P2qPhR-- From bboissin@gmail.com Thu Apr 21 03:25:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 03:25:43 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LAPddD020458 for ; Thu, 21 Apr 2005 03:25:40 -0700 Received: by wproxy.gmail.com with SMTP id 68so542448wra for ; Thu, 21 Apr 2005 03:25:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AQrwddxeZrfpCLyGz15hoP8nacPuG/XWD8iyNQ7pBxosabc4acFmaJ3vXITNlRekgKUqEG0+LVjnCBZRj8Kc/fjR8uK+3iH2GydtTrWXOs1MP7UI3N1noKxLoNHFK2q0as/PEpMTX/Tk6hkPKrLANE38UZ+uzlGEw6sc3fMwfxI= Received: by 10.54.45.77 with SMTP id s77mr1584338wrs; Thu, 21 Apr 2005 03:25:38 -0700 (PDT) Received: by 10.54.14.22 with HTTP; Thu, 21 Apr 2005 03:25:38 -0700 (PDT) Message-ID: <40f323d005042103253bf924f2@mail.gmail.com> Date: Thu, 21 Apr 2005 12:25:38 +0200 From: Benoit Boissinot Reply-To: Benoit Boissinot To: Adrian Bunk Subject: Re: [2.6 patch] drivers/net/hamradio/baycom_epp.c: cleanups Cc: sailer@ife.ee.ethz.ch, linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050420165344.GO5489@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050420165344.GO5489@stusta.de> X-Virus-Scanned: ClamAV 0.83/845/Wed Apr 20 20:37:59 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3LAPddD020458 X-archive-position: 190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bboissin@gmail.com Precedence: bulk X-list: netdev Content-Length: 374 Lines: 15 On 4/20/05, Adrian Bunk wrote: > The times when tricky goto's produced better codes are long gone. > > This patch should express the same in a better way, please check whether > I made any mistake. > By the way, it solves compile errors with gcc-4: a lot of drivers/net/hamradio/baycom_epp.c:690: error: jump into statement expression regards, Benoit From herbert@gondor.apana.org.au Thu Apr 21 06:01:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 06:01:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LD1YdD032285 for ; Thu, 21 Apr 2005 06:01:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DObG0-0006j5-00; Thu, 21 Apr 2005 22:58:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DObFc-0000je-00; Thu, 21 Apr 2005 22:57:48 +1000 From: Herbert Xu To: wolfgang.walter@studentenwerk.mhn.de (Wolfgang Walter) Subject: Re: Problem with IPSEC tunnel mode Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <200504201737.51053.wolfgang.walter@studentenwerk.mhn.de> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 21 Apr 2005 22:57:48 +1000 X-Virus-Scanned: ClamAV 0.83/845/Wed Apr 20 20:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1231 Lines: 35 Wolfgang Walter wrote: > > 5. then it disappears (it is NOT dropped by iptables) > especially it is not seen in FORWARD (mangle-table). > > The route to E on C is a host route via 10.148.15.10. Please show us the output of "ip ru" and "ip ro". > src 10.148.4.0/28 dst 10.0.25.210/32 > dir in priority 2084 > tmpl src 192.168.9.237 dst 192.168.77.161 > proto esp spi 0x00000000 reqid 16465 mode tunnel > > src 10.148.4.0/28 dst 10.0.25.210/32 > dir out priority 0 > > src 10.148.4.0/28 dst 10.0.25.210/32 > dir fwd priority 2084 > tmpl src 192.168.9.237 dst 192.168.77.161 > proto esp spi 0x00000000 reqid 16465 mode tunnel Please attach the complete output of "ip x p". > Interestingly, the original scenario works fine when we use kernel 2.6.7-rc1 > instead of 2.6.11.7 and setkey from ipsec-tools 0.3.3. In this case there are What if you use the new ipsec-tools against the old kernel? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From parklee_sel@yahoo.com Thu Apr 21 06:05:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 06:05:42 -0700 (PDT) Received: from web51501.mail.yahoo.com (web51501.mail.yahoo.com [206.190.38.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3LD5ddD000405 for ; Thu, 21 Apr 2005 06:05:39 -0700 Received: (qmail 96625 invoked by uid 60001); 21 Apr 2005 13:05:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=eixHroBsLEsfuEj6jqdymPe0AVGQ8siYXTnosKhHtk0iGKVuFJnL+JUSGsfMUXBxLxnoOUlMptsx6/lakuMFfMhF+/4aWubT2NyT0ev9DymCEJIv56L+L4kBG/y0Tq1PvTt5wPP9zkds4pAIrOtQw6uhv/4XSs5dK34UuJIXx6I= ; Message-ID: <20050421130537.96620.qmail@web51501.mail.yahoo.com> Received: from [221.15.137.22] by web51501.mail.yahoo.com via HTTP; Thu, 21 Apr 2005 06:05:37 PDT Date: Thu, 21 Apr 2005 06:05:37 -0700 (PDT) From: Park Lee Subject: Re: Must every packet have a creating socket? (was Re: Does a forwarded packet has a local socket with it?) To: Rick Jones Cc: Neil Horman , Masoud Sharbiani , jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/845/Wed Apr 20 20:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: parklee_sel@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1212 Lines: 36 On Wed, 20 Apr 2005 at 18:20, Rick Jones wrote: >> On Wed, 20 Apr 2005 at 10:29, Park Lee wrote: >> Can I think that every packet (e.g. IP packet) must >> have a corresponding creating socket? (i.e. Must >> every packet be created by a socket?) > > No. ICMP messages come to mind - although I > _suppose_ that since those are in response to other > traffic, you could claim it was in response to > something sent from a "socket" or "endpoint" - > depends on how far away you consider it to still > be from a socket. But as I know, The Linux network component creates two special purpose sockets for use by the AF_INET protocol family. The tcp socket is used to send resets when a TCP packet is rejected, since there may be no local socket corresponding to the packet. The icmp socket is used to send ICMP messages. Then, ICMP echo replies are asociated with the special kernel socket. So, I still think that every packet (e.g. IP packet) must have a corresponding creating socket. Am I right? Thank you. Best Regards, Park Lee __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From wolfgang.walter@studentenwerk.mhn.de Thu Apr 21 07:40:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 07:40:53 -0700 (PDT) Received: from email.studentenwerk.mhn.de (mailin.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LEeJdD005175 for ; Thu, 21 Apr 2005 07:40:20 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id A665A58003; Thu, 21 Apr 2005 16:40:17 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 9075E54002; Thu, 21 Apr 2005 16:40:17 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: Herbert Xu Subject: Re: Problem with IPSEC tunnel mode Date: Thu, 21 Apr 2005 16:40:16 +0200 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Qt7ZC/7Rq7CpG8G" Message-Id: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/845/Wed Apr 20 20:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 370362 Lines: 12374 --Boundary-00=_Qt7ZC/7Rq7CpG8G Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 21. April 2005 14:57 schrieb Herbert Xu: > Wolfgang Walter wrote: > > 5. then it disappears (it is NOT dropped by iptables) > > especially it is not seen in FORWARD (mangle-table). > > > > The route to E on C is a host route via 10.148.15.10. > > Please show us the output of "ip ru" and "ip ro". > ip ru 0: from all lookup local 32766: from all lookup main 32767: from all lookup default > > src 10.148.4.0/28 dst 10.0.25.210/32 > > dir in priority 2084 > > tmpl src 192.168.9.237 dst 192.168.77.161 > > proto esp spi 0x00000000 reqid 16465 mode tunnel > > > > src 10.148.4.0/28 dst 10.0.25.210/32 > > dir out priority 0 > > > > src 10.148.4.0/28 dst 10.0.25.210/32 > > dir fwd priority 2084 > > tmpl src 192.168.9.237 dst 192.168.77.161 > > proto esp spi 0x00000000 reqid 16465 mode tunnel > > Please attach the complete output of "ip x p". Is attached. > > > Interestingly, the original scenario works fine when we use kernel > > 2.6.7-rc1 instead of 2.6.11.7 and setkey from ipsec-tools 0.3.3. In this > > case there are > > What if you use the new ipsec-tools against the old kernel? I can try that but can do that only friday evening. Do you expect any=20 difference? We used ip x p to look at the rules generatet with setkey on that old syste= m.=20 Actually, setkey could not display these policies (too many rules). The=20 output of ip x p is identical to the above, only no fwd rule at all and all= =20 rules have the same priority (the order is same, though). > > Cheers, Thanks, =2D-=20 Wolfgang Walter Studentenwerk M=FCnchen Anstalt des =F6ffentlichen Rechts Leopoldstra=DFe 15 80802 M=FCnchen --Boundary-00=_Qt7ZC/7Rq7CpG8G Content-Type: text/plain; charset="iso-8859-15"; name="01_mail_ro" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_mail_ro" > ip ro 10.0.25.210 via 10.148.15.10 dev eth0.1010 src 10.148.15.9 10.0.25.218 via 10.148.15.22 dev eth0.1013 src 10.148.15.21 10.0.25.155 via 10.148.15.30 dev eth0.1014 src 10.148.15.29 10.0.25.217 via 10.148.15.18 dev eth0.1011 src 10.148.15.17 10.0.25.229 via 10.148.15.6 dev eth0.1012 src 10.148.15.5 10.0.25.52 via 10.148.15.26 dev eth0.1003 src 10.148.15.25 10.0.25.226 via 10.148.15.2 dev eth0.1009 src 10.148.15.1 10.0.25.242 via 10.148.15.2 dev eth0.1009 src 10.148.15.1 192.168.77.160/30 dev eth3 scope link src 192.168.77.161 10.0.25.156/30 dev eth0.1018 scope link src 10.0.25.157 10.148.7.40/30 dev eth1.1002 scope link src 10.148.7.41 10.148.7.36/30 dev eth1.1015 scope link src 10.148.7.37 10.148.7.32/30 dev eth1.1005 scope link src 10.148.7.33 10.148.15.32/30 dev eth0.1017 scope link src 10.148.15.33 10.148.15.28/30 dev eth0.1014 scope link src 10.148.15.29 10.148.15.24/30 dev eth0.1003 scope link src 10.148.15.25 10.148.15.20/30 dev eth0.1013 scope link src 10.148.15.21 10.148.5.0/30 via 10.148.14.2 dev eth1.1016 src 10.148.14.1 10.148.15.16/30 dev eth0.1011 scope link src 10.148.15.17 10.148.15.8/30 dev eth0.1010 scope link src 10.148.15.9 10.148.14.0/30 dev eth1.1016 scope link src 10.148.14.1 10.148.7.8/30 dev eth1.1019 scope link src 10.148.7.9 10.148.15.4/30 dev eth0.1012 scope link src 10.148.15.5 10.148.7.0/30 dev eth1.1004 scope link src 10.148.7.1 10.148.15.0/30 dev eth0.1009 scope link src 10.148.15.1 10.148.7.48/29 dev eth1.1020 scope link src 10.148.7.49 10.148.12.32/29 dev eth0.1 scope link src 10.148.12.33 10.0.25.192/28 dev eth10 scope link src 10.0.25.193 10.148.4.64/28 dev eth2.1022 scope link src 10.148.4.65 10.148.12.0/28 dev eth2.1 scope link src 10.148.12.1 10.148.12.16/28 dev eth1.1 scope link src 10.148.12.17 10.148.8.128/27 dev eth2.2002 scope link src 10.148.8.129 10.148.8.0/25 dev eth2.1021 scope link src 10.148.8.1 10.148.2.0/24 dev eth1.2001 scope link src 10.148.2.1 192.28.246.0/24 via 10.148.15.34 dev eth0.1017 src 10.148.15.33 10.148.0.0/23 dev eth2.1001 scope link src 10.148.0.1 10.148.32.0/20 via 10.148.15.30 dev eth0.1014 src 10.148.15.29 default via 192.168.77.162 dev eth3 src 192.168.77.161 --Boundary-00=_Qt7ZC/7Rq7CpG8G Content-Type: text/plain; charset="iso-8859-15"; name="01_mail_spd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_mail_spd" src 0.0.0.0/0 dst 255.255.255.255/32 dir in priority 0 src 192.168.9.237/32 dst 192.168.77.161/32 dir in priority 0 src 192.168.99.93/32 dst 192.168.77.161/32 dir in priority 0 src 192.168.99.29/32 dst 192.168.77.161/32 dir in priority 0 src 192.168.99.81/32 dst 192.168.77.161/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.32.0/20 dir in priority 0 src 10.148.32.0/20 dst 10.148.0.0/23 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.40/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.4/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.2.0/24 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.16/30 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.229/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.4.64/28 dir in priority 0 src 10.148.32.0/20 dst 192.28.246.0/24 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.48/29 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.242/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.36/30 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.226/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.0/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.28/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.20/30 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.192/28 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.218/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.8.0/25 dir in priority 0 src 10.148.32.0/20 dst 10.148.8.128/27 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.156/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.0/28 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.155/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.8/30 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.210/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.32/29 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.52/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.5.0/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.32/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.24/30 dir in priority 0 src 10.148.32.0/20 dst 10.0.25.217/32 dir in priority 0 src 10.148.32.0/20 dst 10.148.14.0/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.16/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.15.8/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.32/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.7.0/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.32.0/20 dir in priority 0 src 10.148.0.0/23 dst 10.148.0.0/23 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.40/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.4/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.2.0/24 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.16/30 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.229/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.4.64/28 dir in priority 0 src 10.148.0.0/23 dst 192.28.246.0/24 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.48/29 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.242/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.36/30 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.226/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.0/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.28/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.20/30 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.192/28 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.218/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.8.0/25 dir in priority 0 src 10.148.0.0/23 dst 10.148.8.128/27 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.156/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.0/28 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.155/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.8/30 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.210/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.32/29 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.52/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.5.0/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.32/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.24/30 dir in priority 0 src 10.148.0.0/23 dst 10.0.25.217/32 dir in priority 0 src 10.148.0.0/23 dst 10.148.14.0/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.16/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.15.8/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.32/30 dir in priority 0 src 10.148.0.0/23 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.40/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.40/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.40/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.40/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.40/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.40/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.4/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.4/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.4/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.4/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.4/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.4/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.32.0/20 dir in priority 0 src 10.148.2.0/24 dst 10.148.0.0/23 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.40/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.4/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.2.0/24 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.16/30 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.229/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.4.64/28 dir in priority 0 src 10.148.2.0/24 dst 192.28.246.0/24 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.48/29 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.242/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.36/30 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.226/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.0/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.28/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.20/30 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.192/28 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.218/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.8.0/25 dir in priority 0 src 10.148.2.0/24 dst 10.148.8.128/27 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.156/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.0/28 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.155/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.8/30 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.210/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.32/29 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.52/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.5.0/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.32/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.24/30 dir in priority 0 src 10.148.2.0/24 dst 10.0.25.217/32 dir in priority 0 src 10.148.2.0/24 dst 10.148.14.0/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.16/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.15.8/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.32/30 dir in priority 0 src 10.148.2.0/24 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.16/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.16/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.16/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.16/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.16/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.16/30 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.229/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.229/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.229/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.229/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.229/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.229/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.32.0/20 dir in priority 0 src 10.148.4.64/28 dst 10.148.0.0/23 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.40/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.4/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.2.0/24 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.16/30 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.229/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.4.64/28 dir in priority 0 src 10.148.4.64/28 dst 192.28.246.0/24 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.48/29 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.242/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.36/30 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.226/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.0/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.28/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.20/30 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.192/28 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.218/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.8.0/25 dir in priority 0 src 10.148.4.64/28 dst 10.148.8.128/27 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.156/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.0/28 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.155/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.8/30 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.210/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.32/29 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.52/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.5.0/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.32/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.24/30 dir in priority 0 src 10.148.4.64/28 dst 10.0.25.217/32 dir in priority 0 src 10.148.4.64/28 dst 10.148.14.0/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.16/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.15.8/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.32/30 dir in priority 0 src 10.148.4.64/28 dst 10.148.7.0/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.32.0/20 dir in priority 0 src 192.28.246.0/24 dst 10.148.0.0/23 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.40/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.4/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.2.0/24 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.16/30 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.229/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.4.64/28 dir in priority 0 src 192.28.246.0/24 dst 192.28.246.0/24 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.48/29 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.242/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.36/30 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.226/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.0/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.28/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.20/30 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.192/28 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.218/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.8.0/25 dir in priority 0 src 192.28.246.0/24 dst 10.148.8.128/27 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.156/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.0/28 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.155/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.8/30 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.210/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.32/29 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.52/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.5.0/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.32/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.24/30 dir in priority 0 src 192.28.246.0/24 dst 10.0.25.217/32 dir in priority 0 src 192.28.246.0/24 dst 10.148.14.0/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.16/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.15.8/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.32/30 dir in priority 0 src 192.28.246.0/24 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.48/29 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.48/29 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.48/29 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.48/29 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.48/29 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.48/29 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.242/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.242/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.242/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.242/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.242/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.242/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.36/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.36/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.36/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.36/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.36/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.36/30 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.226/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.226/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.226/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.226/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.226/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.226/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.0/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.0/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.0/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.0/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.0/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.0/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.28/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.28/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.28/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.28/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.28/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.28/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.20/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.20/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.20/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.20/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.20/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.20/30 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.192/28 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.192/28 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.192/28 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.192/28 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.192/28 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.192/28 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.218/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.218/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.218/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.218/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.218/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.218/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.32.0/20 dir in priority 0 src 10.148.8.0/25 dst 10.148.0.0/23 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.40/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.4/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.2.0/24 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.16/30 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.229/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.4.64/28 dir in priority 0 src 10.148.8.0/25 dst 192.28.246.0/24 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.48/29 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.242/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.36/30 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.226/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.0/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.28/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.20/30 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.192/28 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.218/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.8.0/25 dir in priority 0 src 10.148.8.0/25 dst 10.148.8.128/27 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.156/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.0/28 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.155/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.8/30 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.210/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.32/29 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.52/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.5.0/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.32/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.24/30 dir in priority 0 src 10.148.8.0/25 dst 10.0.25.217/32 dir in priority 0 src 10.148.8.0/25 dst 10.148.14.0/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.16/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.15.8/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.32/30 dir in priority 0 src 10.148.8.0/25 dst 10.148.7.0/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.32.0/20 dir in priority 0 src 10.148.8.128/27 dst 10.148.0.0/23 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.40/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.4/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.2.0/24 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.16/30 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.229/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.4.64/28 dir in priority 0 src 10.148.8.128/27 dst 192.28.246.0/24 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.48/29 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.242/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.36/30 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.226/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.0/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.28/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.20/30 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.192/28 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.218/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.8.0/25 dir in priority 0 src 10.148.8.128/27 dst 10.148.8.128/27 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.156/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.0/28 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.155/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.8/30 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.210/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.32/29 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.52/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.5.0/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.32/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.24/30 dir in priority 0 src 10.148.8.128/27 dst 10.0.25.217/32 dir in priority 0 src 10.148.8.128/27 dst 10.148.14.0/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.16/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.15.8/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.32/30 dir in priority 0 src 10.148.8.128/27 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.156/30 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.156/30 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.156/30 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.156/30 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.156/30 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.156/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.32.0/20 dir in priority 0 src 10.148.12.0/28 dst 10.148.0.0/23 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.40/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.4/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.2.0/24 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.16/30 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.229/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.4.64/28 dir in priority 0 src 10.148.12.0/28 dst 192.28.246.0/24 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.48/29 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.242/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.36/30 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.226/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.0/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.28/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.20/30 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.192/28 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.218/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.8.0/25 dir in priority 0 src 10.148.12.0/28 dst 10.148.8.128/27 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.156/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.0/28 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.155/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.8/30 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.210/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.32/29 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.52/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.5.0/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.32/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.24/30 dir in priority 0 src 10.148.12.0/28 dst 10.0.25.217/32 dir in priority 0 src 10.148.12.0/28 dst 10.148.14.0/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.16/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.15.8/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.32/30 dir in priority 0 src 10.148.12.0/28 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.155/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.155/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.155/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.155/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.155/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.155/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.8/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.8/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.8/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.8/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.8/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.8/30 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.210/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.210/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.210/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.210/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.210/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.210/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.32.0/20 dir in priority 0 src 10.148.12.32/29 dst 10.148.0.0/23 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.40/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.4/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.2.0/24 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.16/30 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.229/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.4.64/28 dir in priority 0 src 10.148.12.32/29 dst 192.28.246.0/24 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.48/29 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.242/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.36/30 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.226/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.0/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.28/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.20/30 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.192/28 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.218/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.8.0/25 dir in priority 0 src 10.148.12.32/29 dst 10.148.8.128/27 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.156/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.0/28 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.155/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.8/30 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.210/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.32/29 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.52/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.5.0/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.32/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.24/30 dir in priority 0 src 10.148.12.32/29 dst 10.0.25.217/32 dir in priority 0 src 10.148.12.32/29 dst 10.148.14.0/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.16/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.15.8/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.32/30 dir in priority 0 src 10.148.12.32/29 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.52/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.52/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.52/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.52/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.52/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.52/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.5.0/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.5.0/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.5.0/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.5.0/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.5.0/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.5.0/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.32/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.32/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.32/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.32/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.32/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.32/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.24/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.24/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.24/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.24/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.24/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.24/30 dst 10.148.7.0/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.32.0/20 dir in priority 0 src 10.0.25.217/32 dst 10.148.0.0/23 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.40/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.4/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.2.0/24 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.16/30 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.4.64/28 dir in priority 0 src 10.0.25.217/32 dst 192.28.246.0/24 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.48/29 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.36/30 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.0/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.28/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.20/30 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.8.0/25 dir in priority 0 src 10.0.25.217/32 dst 10.148.8.128/27 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.0/28 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.8/30 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.32/29 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.52/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.5.0/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.32/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.24/30 dir in priority 0 src 10.0.25.217/32 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.217/32 dst 10.148.14.0/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.16/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.15.8/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.32/30 dir in priority 0 src 10.0.25.217/32 dst 10.148.7.0/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.14.0/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.14.0/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.14.0/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.14.0/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.14.0/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.14.0/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.32.0/20 dir in priority 0 src 10.148.12.16/28 dst 10.148.0.0/23 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.40/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.4/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.2.0/24 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.16/30 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.229/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.4.64/28 dir in priority 0 src 10.148.12.16/28 dst 192.28.246.0/24 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.48/29 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.242/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.36/30 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.226/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.0/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.28/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.20/30 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.192/28 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.218/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.8.0/25 dir in priority 0 src 10.148.12.16/28 dst 10.148.8.128/27 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.156/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.0/28 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.155/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.8/30 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.210/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.32/29 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.52/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.5.0/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.32/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.24/30 dir in priority 0 src 10.148.12.16/28 dst 10.0.25.217/32 dir in priority 0 src 10.148.12.16/28 dst 10.148.14.0/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.16/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.15.8/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.32/30 dir in priority 0 src 10.148.12.16/28 dst 10.148.7.0/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.15.8/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.15.8/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.15.8/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.15.8/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.15.8/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.15.8/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.32/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.32/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.32/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.32/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.32/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.32/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.32.0/20 dir in priority 0 src 10.148.7.0/30 dst 10.148.0.0/23 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.40/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.4/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.2.0/24 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.16/30 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.229/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.4.64/28 dir in priority 0 src 10.148.7.0/30 dst 192.28.246.0/24 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.48/29 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.242/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.36/30 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.226/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.0/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.28/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.20/30 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.192/28 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.218/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.8.0/25 dir in priority 0 src 10.148.7.0/30 dst 10.148.8.128/27 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.156/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.0/28 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.155/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.8/30 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.210/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.32/29 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.52/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.5.0/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.32/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.24/30 dir in priority 0 src 10.148.7.0/30 dst 10.0.25.217/32 dir in priority 0 src 10.148.7.0/30 dst 10.148.14.0/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.16/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.15.8/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.32/30 dir in priority 0 src 10.148.7.0/30 dst 10.148.7.0/30 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.40/29 dir in priority 0 src 10.148.32.0/20 dst 10.148.4.0/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.3.0/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.48/29 dir in priority 0 src 10.148.32.0/20 dst 10.148.4.32/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.3.32/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.4.16/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.4.48/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.3.48/28 dir in priority 0 src 10.148.32.0/20 dst 10.148.12.64/29 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.40/29 dir in priority 0 src 10.148.0.0/23 dst 10.148.4.0/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.3.0/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.48/29 dir in priority 0 src 10.148.0.0/23 dst 10.148.4.32/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.3.32/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.4.16/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.4.48/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.3.48/28 dir in priority 0 src 10.148.0.0/23 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.40/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.40/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.40/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.4/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.4/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.4/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.40/29 dir in priority 0 src 10.148.2.0/24 dst 10.148.4.0/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.3.0/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.48/29 dir in priority 0 src 10.148.2.0/24 dst 10.148.4.32/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.3.32/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.4.16/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.4.48/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.3.48/28 dir in priority 0 src 10.148.2.0/24 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.16/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.16/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.16/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.229/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.229/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.229/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.40/29 dir in priority 0 src 10.148.4.64/28 dst 10.148.4.0/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.3.0/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.48/29 dir in priority 0 src 10.148.4.64/28 dst 10.148.4.32/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.3.32/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.4.16/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.4.48/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.3.48/28 dir in priority 0 src 10.148.4.64/28 dst 10.148.12.64/29 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.40/29 dir in priority 0 src 192.28.246.0/24 dst 10.148.4.0/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.3.0/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.48/29 dir in priority 0 src 192.28.246.0/24 dst 10.148.4.32/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.3.32/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.4.16/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.4.48/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.3.48/28 dir in priority 0 src 192.28.246.0/24 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.48/29 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.48/29 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.48/29 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.242/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.242/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.242/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.36/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.36/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.36/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.226/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.226/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.226/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.0/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.0/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.0/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.28/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.28/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.28/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.20/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.20/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.20/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.192/28 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.192/28 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.192/28 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.218/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.218/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.218/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.40/29 dir in priority 0 src 10.148.8.0/25 dst 10.148.4.0/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.3.0/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.48/29 dir in priority 0 src 10.148.8.0/25 dst 10.148.4.32/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.3.32/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.4.16/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.4.48/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.3.48/28 dir in priority 0 src 10.148.8.0/25 dst 10.148.12.64/29 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.40/29 dir in priority 0 src 10.148.8.128/27 dst 10.148.4.0/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.3.0/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.48/29 dir in priority 0 src 10.148.8.128/27 dst 10.148.4.32/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.3.32/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.4.16/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.4.48/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.3.48/28 dir in priority 0 src 10.148.8.128/27 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.156/30 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.156/30 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.156/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.40/29 dir in priority 0 src 10.148.12.0/28 dst 10.148.4.0/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.3.0/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.48/29 dir in priority 0 src 10.148.12.0/28 dst 10.148.4.32/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.3.32/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.4.16/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.4.48/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.3.48/28 dir in priority 0 src 10.148.12.0/28 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.155/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.155/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.155/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.8/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.8/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.8/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.210/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.210/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.210/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.40/29 dir in priority 0 src 10.148.12.32/29 dst 10.148.4.0/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.3.0/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.48/29 dir in priority 0 src 10.148.12.32/29 dst 10.148.4.32/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.3.32/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.4.16/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.4.48/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.3.48/28 dir in priority 0 src 10.148.12.32/29 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.52/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.52/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.52/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.5.0/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.5.0/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.5.0/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.32/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.32/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.32/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.24/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.24/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.24/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.40/29 dir in priority 0 src 10.0.25.217/32 dst 10.148.4.0/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.3.0/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.48/29 dir in priority 0 src 10.0.25.217/32 dst 10.148.4.32/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.3.32/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.4.16/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.4.48/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.3.48/28 dir in priority 0 src 10.0.25.217/32 dst 10.148.12.64/29 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.14.0/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.14.0/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.14.0/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.40/29 dir in priority 0 src 10.148.12.16/28 dst 10.148.4.0/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.3.0/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.48/29 dir in priority 0 src 10.148.12.16/28 dst 10.148.4.32/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.3.32/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.4.16/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.4.48/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.3.48/28 dir in priority 0 src 10.148.12.16/28 dst 10.148.12.64/29 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.15.8/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.15.8/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.15.8/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.32/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.32/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.32/30 dst 10.148.12.64/29 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.40/29 dir in priority 0 src 10.148.7.0/30 dst 10.148.4.0/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.3.0/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.48/29 dir in priority 0 src 10.148.7.0/30 dst 10.148.4.32/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.3.32/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.4.16/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.4.48/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.3.48/28 dir in priority 0 src 10.148.7.0/30 dst 10.148.12.64/29 dir in priority 0 src 10.0.25.218/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.218/32 dir in priority 0 src 10.0.25.156/30 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.156/30 dir in priority 0 src 10.0.25.192/28 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.192/28 dir in priority 0 src 10.0.25.229/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.229/32 dir in priority 0 src 10.0.25.217/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.217/32 dir in priority 0 src 10.0.25.242/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.242/32 dir in priority 0 src 10.0.25.155/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.155/32 dir in priority 0 src 10.0.25.226/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.226/32 dir in priority 0 src 10.0.25.210/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.210/32 dir in priority 0 src 10.0.25.52/32 dst 0.0.0.0/0 dir in priority 0 src 0.0.0.0/0 dst 10.0.25.52/32 dir in priority 0 src 0.0.0.0/0 dst 192.168.77.161/32 dir in priority 0 src 10.148.12.40/29 dst 10.0.25.155/32 dir in priority 2083 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17809 mode tunnel src 10.148.4.16/28 dst 10.0.25.210/32 dir in priority 2084 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16877 mode tunnel src 10.148.4.0/28 dst 10.0.25.210/32 dir in priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel src 10.148.4.32/28 dst 10.0.25.210/32 dir in priority 2084 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17141 mode tunnel src 10.148.4.0/28 dst 10.0.25.217/32 dir in priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16873 mode tunnel src 10.148.4.16/28 dst 10.0.25.217/32 dir in priority 2084 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16665 mode tunnel src 10.148.4.32/28 dst 10.0.25.217/32 dir in priority 2084 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17181 mode tunnel src 10.148.4.0/28 dst 10.148.15.0/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17817 mode tunnel src 10.148.4.0/28 dst 10.148.7.0/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17541 mode tunnel src 10.148.4.16/28 dst 10.148.7.8/30 dir in priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17797 mode tunnel src 10.148.4.16/28 dst 10.148.7.0/30 dir in priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17133 mode tunnel src 10.148.4.16/28 dst 10.148.7.32/30 dir in priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17285 mode tunnel src 10.148.4.0/28 dst 10.148.7.40/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16569 mode tunnel src 10.148.4.0/28 dst 10.148.7.32/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17405 mode tunnel src 10.148.4.16/28 dst 10.148.7.40/30 dir in priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16693 mode tunnel src 10.148.3.0/28 dst 10.148.7.0/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16729 mode tunnel src 10.148.3.32/28 dst 10.148.15.24/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17805 mode tunnel src 10.148.3.32/28 dst 10.148.14.0/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17801 mode tunnel src 10.148.4.32/28 dst 10.148.7.0/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16661 mode tunnel src 10.148.4.32/28 dst 10.148.7.32/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17521 mode tunnel src 10.148.4.32/28 dst 10.148.7.40/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16505 mode tunnel src 10.148.3.32/28 dst 10.148.7.40/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17753 mode tunnel src 10.148.3.32/28 dst 10.148.7.0/30 dir in priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16485 mode tunnel src 10.148.4.0/28 dst 10.148.15.8/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17317 mode tunnel src 10.148.3.0/28 dst 10.148.7.40/30 dir in priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17073 mode tunnel src 10.148.4.16/28 dst 192.28.246.0/24 dir in priority 2340 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17669 mode tunnel src 10.148.4.16/28 dst 10.148.2.0/24 dir in priority 2340 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16917 mode tunnel src 10.148.4.0/28 dst 10.148.2.0/24 dir in priority 2340 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16697 mode tunnel src 10.148.3.0/28 dst 10.148.2.0/24 dir in priority 2340 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16425 mode tunnel src 10.148.4.32/28 dst 10.148.2.0/24 dir in priority 2340 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17009 mode tunnel src 10.148.3.32/28 dst 10.148.2.0/24 dir in priority 2340 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16857 mode tunnel src 10.148.3.0/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16581 mode tunnel src 10.148.4.0/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16845 mode tunnel src 10.148.4.16/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16501 mode tunnel src 10.148.4.32/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16509 mode tunnel src 10.148.3.32/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17757 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in action block priority 65535 src 0.0.0.0/0 dst 255.255.255.255/32 dir out priority 0 src 192.168.77.161/32 dst 192.168.9.237/32 dir out priority 0 src 192.168.77.161/32 dst 192.168.99.93/32 dir out priority 0 src 192.168.77.161/32 dst 192.168.99.29/32 dir out priority 0 src 192.168.77.161/32 dst 192.168.99.81/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.32.0/20 dir out priority 0 src 10.148.32.0/20 dst 10.148.0.0/23 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.40/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.4/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.2.0/24 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.16/30 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.229/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.4.64/28 dir out priority 0 src 10.148.32.0/20 dst 192.28.246.0/24 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.48/29 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.242/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.36/30 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.226/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.0/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.28/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.20/30 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.192/28 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.218/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.8.0/25 dir out priority 0 src 10.148.32.0/20 dst 10.148.8.128/27 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.156/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.12.0/28 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.155/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.8/30 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.210/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.12.32/29 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.52/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.5.0/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.32/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.24/30 dir out priority 0 src 10.148.32.0/20 dst 10.0.25.217/32 dir out priority 0 src 10.148.32.0/20 dst 10.148.14.0/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.12.16/28 dir out priority 0 src 10.148.32.0/20 dst 10.148.15.8/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.32/30 dir out priority 0 src 10.148.32.0/20 dst 10.148.7.0/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.32.0/20 dir out priority 0 src 10.148.0.0/23 dst 10.148.0.0/23 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.40/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.4/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.2.0/24 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.16/30 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.229/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.4.64/28 dir out priority 0 src 10.148.0.0/23 dst 192.28.246.0/24 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.48/29 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.242/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.36/30 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.226/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.0/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.28/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.20/30 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.192/28 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.218/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.8.0/25 dir out priority 0 src 10.148.0.0/23 dst 10.148.8.128/27 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.156/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.12.0/28 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.155/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.8/30 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.210/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.12.32/29 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.52/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.5.0/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.32/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.24/30 dir out priority 0 src 10.148.0.0/23 dst 10.0.25.217/32 dir out priority 0 src 10.148.0.0/23 dst 10.148.14.0/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.12.16/28 dir out priority 0 src 10.148.0.0/23 dst 10.148.15.8/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.32/30 dir out priority 0 src 10.148.0.0/23 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.40/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.40/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.40/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.40/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.40/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.40/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.40/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.4/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.4/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.4/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.4/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.4/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.4/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.4/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.32.0/20 dir out priority 0 src 10.148.2.0/24 dst 10.148.0.0/23 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.40/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.4/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.2.0/24 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.16/30 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.229/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.4.64/28 dir out priority 0 src 10.148.2.0/24 dst 192.28.246.0/24 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.48/29 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.242/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.36/30 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.226/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.0/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.28/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.20/30 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.192/28 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.218/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.8.0/25 dir out priority 0 src 10.148.2.0/24 dst 10.148.8.128/27 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.156/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.12.0/28 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.155/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.8/30 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.210/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.12.32/29 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.52/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.5.0/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.32/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.24/30 dir out priority 0 src 10.148.2.0/24 dst 10.0.25.217/32 dir out priority 0 src 10.148.2.0/24 dst 10.148.14.0/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.12.16/28 dir out priority 0 src 10.148.2.0/24 dst 10.148.15.8/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.32/30 dir out priority 0 src 10.148.2.0/24 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.16/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.16/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.16/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.16/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.16/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.16/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.16/30 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.229/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.229/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.229/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.229/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.229/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.229/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.229/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.4.64/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.4.64/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.4.64/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.4.64/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.4.64/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.4.64/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.4.64/28 dst 10.148.7.0/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.32.0/20 dir out priority 0 src 192.28.246.0/24 dst 10.148.0.0/23 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.40/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.4/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.2.0/24 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.16/30 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.229/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.4.64/28 dir out priority 0 src 192.28.246.0/24 dst 192.28.246.0/24 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.48/29 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.242/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.36/30 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.226/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.0/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.28/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.20/30 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.192/28 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.218/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.8.0/25 dir out priority 0 src 192.28.246.0/24 dst 10.148.8.128/27 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.156/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.12.0/28 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.155/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.8/30 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.210/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.12.32/29 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.52/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.5.0/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.32/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.24/30 dir out priority 0 src 192.28.246.0/24 dst 10.0.25.217/32 dir out priority 0 src 192.28.246.0/24 dst 10.148.14.0/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.12.16/28 dir out priority 0 src 192.28.246.0/24 dst 10.148.15.8/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.32/30 dir out priority 0 src 192.28.246.0/24 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.48/29 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.48/29 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.48/29 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.48/29 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.48/29 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.48/29 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.48/29 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.242/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.242/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.242/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.242/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.242/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.242/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.242/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.36/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.36/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.36/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.36/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.36/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.36/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.36/30 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.226/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.226/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.226/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.226/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.226/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.226/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.226/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.0/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.0/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.0/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.0/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.0/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.0/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.0/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.28/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.28/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.28/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.28/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.28/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.28/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.28/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.20/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.20/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.20/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.20/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.20/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.20/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.20/30 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.192/28 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.192/28 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.192/28 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.192/28 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.192/28 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.192/28 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.192/28 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.218/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.218/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.218/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.218/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.218/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.218/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.218/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.32.0/20 dir out priority 0 src 10.148.8.0/25 dst 10.148.0.0/23 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.40/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.4/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.2.0/24 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.16/30 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.229/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.4.64/28 dir out priority 0 src 10.148.8.0/25 dst 192.28.246.0/24 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.48/29 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.242/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.36/30 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.226/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.0/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.28/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.20/30 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.192/28 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.218/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.8.0/25 dir out priority 0 src 10.148.8.0/25 dst 10.148.8.128/27 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.156/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.12.0/28 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.155/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.8/30 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.210/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.12.32/29 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.52/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.5.0/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.32/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.24/30 dir out priority 0 src 10.148.8.0/25 dst 10.0.25.217/32 dir out priority 0 src 10.148.8.0/25 dst 10.148.14.0/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.12.16/28 dir out priority 0 src 10.148.8.0/25 dst 10.148.15.8/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.32/30 dir out priority 0 src 10.148.8.0/25 dst 10.148.7.0/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.32.0/20 dir out priority 0 src 10.148.8.128/27 dst 10.148.0.0/23 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.40/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.4/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.2.0/24 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.16/30 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.229/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.4.64/28 dir out priority 0 src 10.148.8.128/27 dst 192.28.246.0/24 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.48/29 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.242/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.36/30 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.226/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.0/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.28/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.20/30 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.192/28 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.218/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.8.0/25 dir out priority 0 src 10.148.8.128/27 dst 10.148.8.128/27 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.156/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.12.0/28 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.155/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.8/30 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.210/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.12.32/29 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.52/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.5.0/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.32/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.24/30 dir out priority 0 src 10.148.8.128/27 dst 10.0.25.217/32 dir out priority 0 src 10.148.8.128/27 dst 10.148.14.0/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.12.16/28 dir out priority 0 src 10.148.8.128/27 dst 10.148.15.8/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.32/30 dir out priority 0 src 10.148.8.128/27 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.156/30 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.156/30 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.156/30 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.156/30 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.156/30 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.156/30 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.156/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.0/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.0/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.0/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.0/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.0/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.0/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.0/28 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.155/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.155/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.155/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.155/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.155/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.155/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.155/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.8/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.8/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.8/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.8/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.8/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.8/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.8/30 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.210/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.210/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.210/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.210/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.210/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.210/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.210/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.32/29 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.32/29 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.32/29 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.32/29 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.32/29 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.32/29 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.32/29 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.52/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.52/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.52/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.52/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.52/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.52/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.52/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.5.0/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.5.0/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.5.0/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.5.0/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.5.0/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.5.0/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.5.0/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.32/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.32/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.32/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.32/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.32/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.32/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.32/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.24/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.24/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.24/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.24/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.24/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.24/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.24/30 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.32.0/20 dir out priority 0 src 10.0.25.217/32 dst 10.148.0.0/23 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.40/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.4/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.2.0/24 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.16/30 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.4.64/28 dir out priority 0 src 10.0.25.217/32 dst 192.28.246.0/24 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.48/29 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.36/30 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.0/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.28/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.20/30 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.8.0/25 dir out priority 0 src 10.0.25.217/32 dst 10.148.8.128/27 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.12.0/28 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.8/30 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.12.32/29 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.52/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.5.0/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.32/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.24/30 dir out priority 0 src 10.0.25.217/32 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.217/32 dst 10.148.14.0/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.12.16/28 dir out priority 0 src 10.0.25.217/32 dst 10.148.15.8/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.32/30 dir out priority 0 src 10.0.25.217/32 dst 10.148.7.0/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.14.0/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.14.0/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.14.0/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.14.0/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.14.0/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.14.0/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.14.0/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.16/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.16/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.16/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.16/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.16/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.16/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.16/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.15.8/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.15.8/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.15.8/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.15.8/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.15.8/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.15.8/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.15.8/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.32/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.32/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.32/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.32/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.32/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.32/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.32/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.32.0/20 dir out priority 0 src 10.148.7.0/30 dst 10.148.0.0/23 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.40/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.4/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.2.0/24 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.16/30 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.229/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.4.64/28 dir out priority 0 src 10.148.7.0/30 dst 192.28.246.0/24 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.48/29 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.242/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.36/30 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.226/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.0/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.28/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.20/30 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.192/28 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.218/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.8.0/25 dir out priority 0 src 10.148.7.0/30 dst 10.148.8.128/27 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.156/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.12.0/28 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.155/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.8/30 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.210/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.12.32/29 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.52/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.5.0/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.32/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.24/30 dir out priority 0 src 10.148.7.0/30 dst 10.0.25.217/32 dir out priority 0 src 10.148.7.0/30 dst 10.148.14.0/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.12.16/28 dir out priority 0 src 10.148.7.0/30 dst 10.148.15.8/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.32/30 dir out priority 0 src 10.148.7.0/30 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.32.0/20 dir out priority 0 src 10.148.4.0/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.3.0/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.48/29 dst 10.148.32.0/20 dir out priority 0 src 10.148.4.32/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.3.32/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.4.16/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.4.48/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.3.48/28 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.64/29 dst 10.148.32.0/20 dir out priority 0 src 10.148.12.40/29 dst 10.148.0.0/23 dir out priority 0 src 10.148.4.0/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.3.0/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.48/29 dst 10.148.0.0/23 dir out priority 0 src 10.148.4.32/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.3.32/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.4.16/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.4.48/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.3.48/28 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.64/29 dst 10.148.0.0/23 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.40/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.40/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.40/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.4/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.4/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.4/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.2.0/24 dir out priority 0 src 10.148.4.0/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.3.0/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.48/29 dst 10.148.2.0/24 dir out priority 0 src 10.148.4.32/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.3.32/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.4.16/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.4.48/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.3.48/28 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.64/29 dst 10.148.2.0/24 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.16/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.16/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.16/30 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.229/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.229/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.229/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.4.64/28 dir out priority 0 src 10.148.4.0/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.3.0/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.48/29 dst 10.148.4.64/28 dir out priority 0 src 10.148.4.32/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.3.32/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.4.16/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.4.48/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.3.48/28 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.64/29 dst 10.148.4.64/28 dir out priority 0 src 10.148.12.40/29 dst 192.28.246.0/24 dir out priority 0 src 10.148.4.0/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.3.0/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.48/29 dst 192.28.246.0/24 dir out priority 0 src 10.148.4.32/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.3.32/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.4.16/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.4.48/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.3.48/28 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.64/29 dst 192.28.246.0/24 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.48/29 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.48/29 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.48/29 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.242/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.242/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.242/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.36/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.36/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.36/30 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.226/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.226/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.226/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.0/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.0/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.0/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.28/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.28/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.28/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.20/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.20/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.20/30 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.192/28 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.192/28 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.192/28 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.218/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.218/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.218/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.8.0/25 dir out priority 0 src 10.148.4.0/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.3.0/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.48/29 dst 10.148.8.0/25 dir out priority 0 src 10.148.4.32/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.3.32/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.4.16/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.4.48/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.3.48/28 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.64/29 dst 10.148.8.0/25 dir out priority 0 src 10.148.12.40/29 dst 10.148.8.128/27 dir out priority 0 src 10.148.4.0/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.3.0/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.48/29 dst 10.148.8.128/27 dir out priority 0 src 10.148.4.32/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.3.32/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.4.16/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.4.48/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.3.48/28 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.64/29 dst 10.148.8.128/27 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.156/30 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.156/30 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.156/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.12.0/28 dir out priority 0 src 10.148.4.0/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.3.0/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.48/29 dst 10.148.12.0/28 dir out priority 0 src 10.148.4.32/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.3.32/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.4.16/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.4.48/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.3.48/28 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.64/29 dst 10.148.12.0/28 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.155/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.155/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.155/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.8/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.8/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.8/30 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.210/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.12.32/29 dir out priority 0 src 10.148.4.0/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.3.0/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.48/29 dst 10.148.12.32/29 dir out priority 0 src 10.148.4.32/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.3.32/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.4.16/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.4.48/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.3.48/28 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.64/29 dst 10.148.12.32/29 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.52/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.52/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.52/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.5.0/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.5.0/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.5.0/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.32/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.32/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.32/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.24/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.24/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.24/30 dir out priority 0 src 10.148.12.40/29 dst 10.0.25.217/32 dir out priority 0 src 10.148.4.0/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.3.0/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.48/29 dst 10.0.25.217/32 dir out priority 0 src 10.148.4.32/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.3.32/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.4.16/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.4.48/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.3.48/28 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.64/29 dst 10.0.25.217/32 dir out priority 0 src 10.148.12.40/29 dst 10.148.14.0/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.14.0/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.14.0/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.12.16/28 dir out priority 0 src 10.148.4.0/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.3.0/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.48/29 dst 10.148.12.16/28 dir out priority 0 src 10.148.4.32/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.3.32/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.4.16/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.4.48/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.3.48/28 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.64/29 dst 10.148.12.16/28 dir out priority 0 src 10.148.12.40/29 dst 10.148.15.8/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.15.8/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.15.8/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.32/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.32/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.32/30 dir out priority 0 src 10.148.12.40/29 dst 10.148.7.0/30 dir out priority 0 src 10.148.4.0/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.3.0/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.48/29 dst 10.148.7.0/30 dir out priority 0 src 10.148.4.32/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.3.32/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.4.16/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.4.48/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.3.48/28 dst 10.148.7.0/30 dir out priority 0 src 10.148.12.64/29 dst 10.148.7.0/30 dir out priority 0 src 10.0.25.218/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.218/32 dir out priority 0 src 10.0.25.156/30 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.156/30 dir out priority 0 src 10.0.25.192/28 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.192/28 dir out priority 0 src 10.0.25.229/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.229/32 dir out priority 0 src 10.0.25.217/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.217/32 dir out priority 0 src 10.0.25.242/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.242/32 dir out priority 0 src 10.0.25.155/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.155/32 dir out priority 0 src 10.0.25.226/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.226/32 dir out priority 0 src 10.0.25.210/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.210/32 dir out priority 0 src 10.0.25.52/32 dst 0.0.0.0/0 dir out priority 0 src 0.0.0.0/0 dst 10.0.25.52/32 dir out priority 0 src 192.168.77.161/32 dst 0.0.0.0/0 dir out priority 0 src 10.0.25.217/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.12.64/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.12.48/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.12.40/29 dir out priority 2083 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17809 mode tunnel src 10.0.25.52/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16465 mode tunnel src 10.0.25.155/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 16665 mode tunnel src 10.0.25.155/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16873 mode tunnel src 10.0.25.210/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 16877 mode tunnel src 10.0.25.217/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.4.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17141 mode tunnel src 10.0.25.217/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17181 mode tunnel src 10.0.25.226/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.217/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.226/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.4.16/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.3.0/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.3.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.218/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.229/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.155/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.242/32 dst 10.148.4.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.52/32 dst 10.148.4.32/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.210/32 dst 10.148.3.48/28 dir out priority 2084 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.12.40/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.12.64/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.12.48/29 dir out priority 2147 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 16485 mode tunnel src 10.148.7.36/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 16505 mode tunnel src 10.148.7.8/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16569 mode tunnel src 10.148.15.20/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 16661 mode tunnel src 10.148.7.8/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 16693 mode tunnel src 10.148.7.36/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16729 mode tunnel src 10.148.15.16/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17073 mode tunnel src 10.148.7.36/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 17133 mode tunnel src 10.0.25.156/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.0/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 17285 mode tunnel src 10.148.15.4/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.14.0/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17317 mode tunnel src 10.148.14.0/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17405 mode tunnel src 10.148.15.8/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.36/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.32/30 dst 10.148.4.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17521 mode tunnel src 10.148.7.0/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17541 mode tunnel src 10.148.15.0/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.8/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.156/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.32/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.5.0/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.0/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.4/30 dst 10.148.3.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.20/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.16/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.40/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17753 mode tunnel src 10.0.25.156/30 dst 10.148.4.48/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.28/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.15.24/30 dst 10.148.3.0/28 dir out priority 2148 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.8/30 dst 10.148.4.16/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 17797 mode tunnel src 10.148.14.0/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17801 mode tunnel src 10.148.15.24/30 dst 10.148.3.32/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17805 mode tunnel src 10.148.15.0/30 dst 10.148.4.0/28 dir out priority 2148 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 17817 mode tunnel src 10.148.12.32/29 dst 10.148.12.48/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.12.48/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.12.64/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.12.64/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.12.40/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.12.40/29 dir out priority 2179 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.4.16/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.3.32/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.3.48/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.4.32/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.4.48/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.4.16/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.4.0/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.3.32/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.3.0/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.4.32/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.3.48/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.7.48/29 dst 10.148.3.0/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.4.0/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.32/29 dst 10.148.4.48/28 dir out priority 2180 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.12.48/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.12.48/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.12.40/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.12.64/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.12.64/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.12.64/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.12.64/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.12.40/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.12.48/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.12.48/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.12.40/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.12.40/29 dir out priority 2211 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.4.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.4.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.3.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.3.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.4.16/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.3.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.4.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.3.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.4.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.4.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.4.16/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.3.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.4.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.4.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.3.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.3.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.4.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.4.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.3.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.4.64/28 dst 10.148.4.16/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.3.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.4.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.3.0/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.16/28 dst 10.148.4.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.3.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.4.16/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.12.0/28 dst 10.148.3.32/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.0.25.192/28 dst 10.148.4.48/28 dir out priority 2212 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.12.64/29 dir out priority 2243 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.12.40/29 dir out priority 2243 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.12.48/29 dir out priority 2243 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.3.0/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.3.32/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.4.32/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.3.48/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.4.16/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.4.0/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.128/27 dst 10.148.4.48/28 dir out priority 2244 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.12.64/29 dir out priority 2307 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.12.40/29 dir out priority 2307 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.12.48/29 dir out priority 2307 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.4.32/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.4.48/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.3.0/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.4.16/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.4.0/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.3.32/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.8.0/25 dst 10.148.3.48/28 dir out priority 2308 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.12.40/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.12.48/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.12.40/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.12.64/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.12.48/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.12.64/29 dir out priority 2339 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.3.0/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16425 mode tunnel src 10.148.2.0/24 dst 10.148.4.0/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16697 mode tunnel src 192.28.246.0/24 dst 10.148.3.48/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.3.32/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 16857 mode tunnel src 192.28.246.0/24 dst 10.148.3.0/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.4.16/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 16917 mode tunnel src 192.28.246.0/24 dst 10.148.4.48/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.4.32/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17009 mode tunnel src 10.148.2.0/24 dst 10.148.3.48/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.2.0/24 dst 10.148.4.48/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.3.32/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.4.32/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 192.28.246.0/24 dst 10.148.4.16/28 dir out priority 2340 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 17669 mode tunnel src 192.28.246.0/24 dst 10.148.4.0/28 dir out priority 2340 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.12.48/29 dir out priority 2371 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.12.40/29 dir out priority 2371 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.12.64/29 dir out priority 2371 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.4.48/28 dir out priority 2372 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.4.16/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.99.29 proto esp spi 0x00000000 reqid 16501 mode tunnel src 10.148.0.0/23 dst 10.148.4.32/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 16509 mode tunnel src 10.148.0.0/23 dst 10.148.3.0/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16581 mode tunnel src 10.148.0.0/23 dst 10.148.4.0/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.9.237 proto esp spi 0x00000000 reqid 16845 mode tunnel src 10.148.0.0/23 dst 10.148.3.48/28 dir out priority 2372 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.0.0/23 dst 10.148.3.32/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17757 mode tunnel src 10.148.32.0/20 dst 10.148.12.40/29 dir out priority 2467 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.12.48/29 dir out priority 2467 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.12.64/29 dir out priority 2467 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.4.0/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.3.32/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.4.16/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.4.32/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.3.48/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.3.0/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 10.148.32.0/20 dst 10.148.4.48/28 dir out priority 2468 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp spi 0x00000000 reqid 0 mode transport src 0.0.0.0/0 dst 0.0.0.0/0 dir out action block priority 65535 src 10.148.32.0/20 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.32.0/20 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.0.0/23 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.40/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.4/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.2.0/24 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.16/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.229/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.4.64/28 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.7.0/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.32.0/20 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.0.0/23 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.40/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.4/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.2.0/24 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.16/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.229/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.4.64/28 dir fwd priority 0 src 192.28.246.0/24 dst 192.28.246.0/24 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.48/29 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.242/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.36/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.226/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.0/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.28/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.20/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.192/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.218/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.8.0/25 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.8.128/27 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.156/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.0/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.155/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.8/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.210/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.32/29 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.52/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.5.0/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.32/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.24/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.0.25.217/32 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.14.0/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.16/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.15.8/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.32/30 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.48/29 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.242/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.36/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.226/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.0/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.28/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.20/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.192/28 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.218/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.8.0/25 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.8.128/27 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.156/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.12.0/28 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.155/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.8/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.210/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.12.32/29 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.52/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.5.0/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.32/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.24/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.32.0/20 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.0.0/23 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.40/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.4/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.2.0/24 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.16/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.4.64/28 dir fwd priority 0 src 10.0.25.217/32 dst 192.28.246.0/24 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.48/29 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.36/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.0/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.28/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.20/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.8.0/25 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.8.128/27 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.0/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.8/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.32/29 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.52/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.5.0/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.32/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.24/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.14.0/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.16/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.15.8/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.32/30 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.14.0/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.12.16/28 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.15.8/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.32/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.32.0/20 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.0.0/23 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.40/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.4/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.2.0/24 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.16/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.229/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.4.64/28 dir fwd priority 0 src 10.148.7.0/30 dst 192.28.246.0/24 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.48/29 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.242/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.36/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.226/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.0/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.28/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.20/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.192/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.218/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.8.0/25 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.8.128/27 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.156/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.0/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.155/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.8/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.210/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.32/29 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.5.0/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.32/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.24/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.0.25.217/32 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.14.0/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.16/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.15.8/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.32/30 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.7.0/30 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.32.0/20 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.0.0/23 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.40/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.4/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.2.0/24 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.16/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.229/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.4.64/28 dst 10.148.12.64/29 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.40/29 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.4.0/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.3.0/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.48/29 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.4.32/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.3.32/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.4.16/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.4.48/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.3.48/28 dir fwd priority 0 src 192.28.246.0/24 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.48/29 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.242/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.36/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.226/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.0/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.28/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.20/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.192/28 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.218/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.8.0/25 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.8.128/27 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.156/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.12.0/28 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.155/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.8/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.210/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.12.32/29 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.52/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.5.0/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.32/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.24/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.40/29 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.4.0/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.3.0/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.48/29 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.4.32/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.3.32/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.4.16/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.4.48/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.3.48/28 dir fwd priority 0 src 10.0.25.217/32 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.14.0/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.12.16/28 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.15.8/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.32/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.40/29 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.4.0/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.3.0/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.48/29 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.4.32/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.3.32/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.4.16/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.4.48/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.3.48/28 dir fwd priority 0 src 10.148.7.0/30 dst 10.148.12.64/29 dir fwd priority 0 src 10.0.25.218/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.218/32 dir fwd priority 0 src 10.0.25.156/30 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.156/30 dir fwd priority 0 src 10.0.25.192/28 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.192/28 dir fwd priority 0 src 10.0.25.229/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.229/32 dir fwd priority 0 src 10.0.25.217/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.217/32 dir fwd priority 0 src 10.0.25.242/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.242/32 dir fwd priority 0 src 10.0.25.155/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.155/32 dir fwd priority 0 src 10.0.25.226/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.226/32 dir fwd priority 0 src 10.0.25.210/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.210/32 dir fwd priority 0 src 10.0.25.52/32 dst 0.0.0.0/0 dir fwd priority 0 src 0.0.0.0/0 dst 10.0.25.52/32 dir fwd priority 0 src 10.148.12.40/29 dst 10.0.25.155/32 dir fwd priority 2083 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17809 mode tunnel src 10.148.4.16/28 dst 10.0.25.210/32 dir fwd priority 2084 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16877 mode tunnel src 10.148.4.0/28 dst 10.0.25.210/32 dir fwd priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16465 mode tunnel src 10.148.4.32/28 dst 10.0.25.210/32 dir fwd priority 2084 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17141 mode tunnel src 10.148.4.0/28 dst 10.0.25.217/32 dir fwd priority 2084 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16873 mode tunnel src 10.148.4.16/28 dst 10.0.25.217/32 dir fwd priority 2084 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16665 mode tunnel src 10.148.4.32/28 dst 10.0.25.217/32 dir fwd priority 2084 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17181 mode tunnel src 10.148.4.0/28 dst 10.148.15.0/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17817 mode tunnel src 10.148.4.0/28 dst 10.148.7.0/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17541 mode tunnel src 10.148.4.16/28 dst 10.148.7.8/30 dir fwd priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17797 mode tunnel src 10.148.4.16/28 dst 10.148.7.0/30 dir fwd priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17133 mode tunnel src 10.148.4.16/28 dst 10.148.7.32/30 dir fwd priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17285 mode tunnel src 10.148.4.0/28 dst 10.148.7.40/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16569 mode tunnel src 10.148.4.0/28 dst 10.148.7.32/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17405 mode tunnel src 10.148.4.16/28 dst 10.148.7.40/30 dir fwd priority 2148 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16693 mode tunnel src 10.148.3.0/28 dst 10.148.7.0/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16729 mode tunnel src 10.148.3.32/28 dst 10.148.15.24/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17805 mode tunnel src 10.148.3.32/28 dst 10.148.14.0/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17801 mode tunnel src 10.148.4.32/28 dst 10.148.7.0/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16661 mode tunnel src 10.148.4.32/28 dst 10.148.7.32/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17521 mode tunnel src 10.148.4.32/28 dst 10.148.7.40/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16505 mode tunnel src 10.148.3.32/28 dst 10.148.7.40/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17753 mode tunnel src 10.148.3.32/28 dst 10.148.7.0/30 dir fwd priority 2148 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16485 mode tunnel src 10.148.4.0/28 dst 10.148.15.8/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17317 mode tunnel src 10.148.3.0/28 dst 10.148.7.40/30 dir fwd priority 2148 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17073 mode tunnel src 10.148.4.16/28 dst 192.28.246.0/24 dir fwd priority 2340 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17669 mode tunnel src 10.148.4.16/28 dst 10.148.2.0/24 dir fwd priority 2340 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16917 mode tunnel src 10.148.4.0/28 dst 10.148.2.0/24 dir fwd priority 2340 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16697 mode tunnel src 10.148.3.0/28 dst 10.148.2.0/24 dir fwd priority 2340 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16425 mode tunnel src 10.148.4.32/28 dst 10.148.2.0/24 dir fwd priority 2340 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17009 mode tunnel src 10.148.3.32/28 dst 10.148.2.0/24 dir fwd priority 2340 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16857 mode tunnel src 10.148.3.0/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16581 mode tunnel src 10.148.4.0/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.9.237 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16845 mode tunnel src 10.148.4.16/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.99.29 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16501 mode tunnel src 10.148.4.32/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 16509 mode tunnel src 10.148.3.32/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17757 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd action block priority 65535 --Boundary-00=_Qt7ZC/7Rq7CpG8G-- From ganesh.venkatesan@gmail.com Thu Apr 21 09:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 09:51:10 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LGp1dD018639 for ; Thu, 21 Apr 2005 09:51:04 -0700 Received: by zproxy.gmail.com with SMTP id 8so453529nzo for ; Thu, 21 Apr 2005 09:51:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hz2WN4H4hmFhqrmUqK8Eg0jewN9q6l/f4YCUPS5Kd9W/vZeEkK9j6ppMxnAy8ybZTyF9MfJIkA/G++fGbWUVdVY1I00LBI2L41T02aRIw06iq2J7VClmPv351kVKwP4w6o7NS60HIas5nTxIHvhnEhK5kClETXhScEbXkkXlHQY= Received: by 10.36.8.17 with SMTP id 17mr211392nzh; Thu, 21 Apr 2005 09:51:01 -0700 (PDT) Received: by 10.36.65.5 with HTTP; Thu, 21 Apr 2005 09:51:01 -0700 (PDT) Message-ID: <5fc59ff305042109514b792bbf@mail.gmail.com> Date: Thu, 21 Apr 2005 09:51:01 -0700 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: "Randy.Dunlap" Subject: Re: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Cc: Malli Chilakala , jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050420200524.3e284eb9.rddunlap@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050420200524.3e284eb9.rddunlap@osdl.org> X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3LGp1dD018639 X-archive-position: 196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 2266 Lines: 69 On 4/20/05, Randy.Dunlap wrote: > On Tue, 19 Apr 2005 22:50:31 -0700 (PDT) Malli Chilakala wrote: > > | > | -#define E100_WAIT_SCB_TIMEOUT 40 > | +#define E100_WAIT_SCB_TIMEOUT 20000 /* we might have to wait 100ms!!! */ > > What correlation is there between 20000 and 100 ms ? > This needs some review and fixing on our side. > | static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr) > | { > | unsigned long flags; > | @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni > | * because the controller is too busy, so > | * let's just queue the command and try again > | * when another command is scheduled. */ > | + if(err == -ENOSPC) { > if (err == -ENOSPC) { > is preferred (with space after if). > (same comment for below) Is there a clear directive on 'if(' versus 'if ('? I see both styles being used. We are trying to stay consistent with 'if('. > > | + //request a reset > Kernel comment style is /* ... */, not //. > (same comment for below) > Agreed. Will fix this. > | + schedule_work(&nic->tx_timeout_task); > | + } > | break; > | } else { > | nic->cuc_cmd = cuc_resume; > | @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str > | struct sk_buff *skb) > | { > | cb->command = nic->tx_command; > | + /* interrupt every 16 packets regardless of delay */ > | + if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i; > Don't put if() and statement on one line, please. > It tends to hide code unintentionally. Will fix this. > > | cb->u.tcb.tbd_array = cb->dma_addr + offsetof(struct cb, u.tcb.tbd); > | cb->u.tcb.tcb_byte_count = 0; > | cb->u.tcb.threshold = nic->tx_threshold; > | cb->u.tcb.tbd_count = 1; > | cb->u.tcb.tbd.buf_addr = cpu_to_le32(pci_map_single(nic->pdev, > | skb->data, skb->len, PCI_DMA_TODEVICE)); > | + // check for mapping failure? > | cb->u.tcb.tbd.size = cpu_to_le16(skb->len); > | } > > --- > ~Randy > > From sfeldma@pobox.com Thu Apr 21 09:55:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 09:55:53 -0700 (PDT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LGtndD019755 for ; Thu, 21 Apr 2005 09:55:51 -0700 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 1E03573F; Thu, 21 Apr 2005 12:55:46 -0400 (EDT) Received: from [192.168.0.2] (wbar2.sea1-4-5-058-148.sea1.dsl-verizon.net [4.5.58.148]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 6B7818A; Thu, 21 Apr 2005 12:55:43 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7e4e52dab6e50d8fc38c76651cac0f07@pobox.com> Content-Transfer-Encoding: 7bit Cc: netdev , "jgarzik@pobox.com" From: Scott Feldman Subject: Re: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Date: Thu, 21 Apr 2005 09:55:00 -0700 To: Malli Chilakala X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 34 On Apr 19, 2005, at 10:50 PM, Malli Chilakala wrote: > Performance optimizations to e100 Tx Path So what is the net performance improvement with these changes? > - nic->tx_command = cpu_to_le16(cb_tx | cb_i | cb_tx_sf | > - ((nic->mac >= mac_82558_D101_A4) ? cb_cid : 0)); > + /* no interrupt for every tx completion, delay = 256us if not 557*/ > + nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf | > + ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i)); Where is this 256us delay coming from? > /* Template for a freshly allocated RFD */ > nic->blank_rfd.command = cpu_to_le16(cb_el); > @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str > struct sk_buff *skb) > { > cb->command = nic->tx_command; > + /* interrupt every 16 packets regardless of delay */ > + if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i; You messed up Big Endian. So you send out 15 packets with no i-bit set. Then what? No interrupt means no NAPI means no cleanup of those 15 packet skbs. -scott P.S. I only saw this one patch for e100 but the subject line indicates there are 6. From rddunlap@osdl.org Thu Apr 21 10:11:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 10:11:07 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LHB4dD021047 for ; Thu, 21 Apr 2005 10:11:05 -0700 Received: from gargoyle.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3LHArs3007344 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Apr 2005 10:10:53 -0700 Date: Thu, 21 Apr 2005 10:10:52 -0700 From: "Randy.Dunlap" To: Ganesh Venkatesan Cc: mallikarjuna.chilakala@intel.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Message-Id: <20050421101052.4d212a17.rddunlap@osdl.org> In-Reply-To: <5fc59ff305042109514b792bbf@mail.gmail.com> References: <20050420200524.3e284eb9.rddunlap@osdl.org> <5fc59ff305042109514b792bbf@mail.gmail.com> Organization: OSDL X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: SvC&!/v_Hr`MvpQ*|}uez16KH[#EmO2Tn~(r-y+&Jb}?Zhn}c:Eee&zq`cMb_[5`tT(22ms (.P84,bq_GBdk@Kgplnrbj;Y`9IF`Q4;Iys|#3\?*[:ixU(UR.7qJT665DxUP%K}kC0j5,UI+"y-Sw mn?l6JGvyI^f~2sSJ8vd7s[/CDY]apD`a;s1Wf)K[,.|-yOLmBl0 | static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr) | > | { | > | unsigned long flags; | > | @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni | > | * because the controller is too busy, so | > | * let's just queue the command and try again | > | * when another command is scheduled. */ | > | + if(err == -ENOSPC) { | > if (err == -ENOSPC) { | > is preferred (with space after if). | > (same comment for below) | | Is there a clear directive on 'if(' versus 'if ('? I see both styles | being used. We are trying to stay consistent with 'if('. There's nothing explicit in CodingStyle, but all of the examples in CodingStyle use a space after 'if'. And a few if's in this driver use a space after 'if', but most don't iirc from counting them yesterday. Thanks, --- ~Randy From khc@pm.waw.pl Thu Apr 21 11:49:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 11:49:29 -0700 (PDT) Received: from khc.piap.pl (khc.piap.pl [195.187.100.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LInCdD025867 for ; Thu, 21 Apr 2005 11:49:14 -0700 Received: by khc.piap.pl (Postfix, from userid 500) id 34FE310829; Thu, 21 Apr 2005 15:57:25 +0200 (CEST) To: Jeff Garzik Cc: Subject: [PATCH][RESENT] Generic HDLC update From: Krzysztof Halasa Date: Thu, 21 Apr 2005 15:57:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 22264 Lines: 720 --=-=-= Hi, The attached patch updates generic HDLC to version 1.18. FR Cisco LMI production-tested. Please apply to Linux 2.6. Thanks. Changes: - doc updates - added Cisco LMI support to Frame-Relay code - cleaned hdlc_fr.c a bit, removed some orphaned #defines etc. - fixed a problem with non-functional LMI in FR DCE mode. - changed diagnostic messages to better conform to FR standards - all protocols: information about carrier changes (DCD line) is now printed to kernel logs. Signed-Off-By: Krzysztof Halasa -- Krzysztof Halasa --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hdlc-2.6-1.18.patch --- linux-2.6/Documentation/networking/generic-hdlc.txt 25 May 2003 22:13:37 -0000 1.4 +++ linux-2.6/Documentation/networking/generic-hdlc.txt 2 Apr 2005 13:12:18 -0000 @@ -1,21 +1,21 @@ Generic HDLC layer Krzysztof Halasa -January, 2003 Generic HDLC layer currently supports: -- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP). - Normal (routed) and Ethernet-bridged (Ethernet device emulation) - interfaces can share a single PVC. -- raw HDLC - either IP (IPv4) interface or Ethernet device emulation. -- Cisco HDLC, -- PPP (uses syncppp.c), -- X.25 (uses X.25 routines). - -There are hardware drivers for the following cards: -- C101 by Moxa Technologies Co., Ltd. -- RISCom/N2 by SDL Communications Inc. -- and others, some not in the official kernel. +1. Frame Relay (ANSI, CCITT, Cisco and no LMI). + - Normal (routed) and Ethernet-bridged (Ethernet device emulation) + interfaces can share a single PVC. + - ARP support (no InARP support in the kernel - there is an + experimental InARP user-space daemon available on: + http://www.kernel.org/pub/linux/utils/net/hdlc/). +2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation. +3. Cisco HDLC. +4. PPP (uses syncppp.c). +5. X.25 (uses X.25 routines). + +Generic HDLC is a protocol driver only - it needs a low-level driver +for your particular hardware. Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging). @@ -24,7 +24,7 @@ Make sure the hdlc.o and the hardware driver are loaded. It should create a number of "hdlc" (hdlc0 etc) network devices, one for each WAN port. You'll need the "sethdlc" utility, get it from: - http://hq.pm.waw.pl/hdlc/ + http://www.kernel.org/pub/linux/utils/net/hdlc/ Compile sethdlc.c utility: gcc -O2 -Wall -o sethdlc sethdlc.c @@ -52,12 +52,12 @@ * v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port if the card has software-selectable interfaces loopback - activate hardware loopback (for testing only) -* clock ext - external clock (uses DTE RX and TX clock) -* clock int - internal clock (provides clock signal on DCE clock output) -* clock txint - TX internal, RX external (provides TX clock on DCE output) -* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output) -* rate - sets clock rate in bps (not required for external clock or - for txfromrx) +* clock ext - both RX clock and TX clock external +* clock int - both RX clock and TX clock internal +* clock txint - RX clock external, TX clock internal +* clock txfromrx - RX clock external, TX clock derived from RX clock +* rate - sets clock rate in bps (for "int" or "txint" clock only) + Setting protocol: @@ -79,7 +79,7 @@ * x25 - sets X.25 mode * fr - Frame Relay mode - lmi ansi / ccitt / none - LMI (link management) type + lmi ansi / ccitt / cisco / none - LMI (link management) type dce - Frame Relay DCE (network) side LMI instead of default DTE (user). It has nothing to do with clocks! t391 - link integrity verification polling timer (in seconds) - user @@ -119,13 +119,14 @@ -If you have a problem with N2 or C101 card, you can issue the "private" -command to see port's packet descriptor rings (in kernel logs): +If you have a problem with N2, C101 or PLX200SYN card, you can issue the +"private" command to see port's packet descriptor rings (in kernel logs): sethdlc hdlc0 private -The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS. +The hardware driver has to be build with #define DEBUG_RINGS. Attaching this info to bug reports would be helpful. Anyway, let me know if you have problems using this. -For patches and other info look at http://hq.pm.waw.pl/hdlc/ +For patches and other info look at: +. --- linux-2.6/include/linux/hdlc.h 28 Oct 2004 06:16:08 -0000 1.12 +++ linux-2.6/include/linux/hdlc.h 2 Apr 2005 13:12:18 -0000 @@ -1,7 +1,7 @@ /* * Generic HDLC support routines for Linux * - * Copyright (C) 1999-2003 Krzysztof Halasa + * Copyright (C) 1999-2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -41,6 +41,7 @@ #define LMI_NONE 1 /* No LMI, all PVCs are static */ #define LMI_ANSI 2 /* ANSI Annex D */ #define LMI_CCITT 3 /* ITU-T Annex A */ +#define LMI_CISCO 4 /* The "original" LMI, aka Gang of Four */ #define HDLC_MAX_MTU 1500 /* Ethernet 1500 bytes */ #define HDLC_MAX_MRU (HDLC_MAX_MTU + 10 + 14 + 4) /* for ETH+VLAN over FR */ @@ -89,6 +90,7 @@ unsigned int deleted: 1; unsigned int fecn: 1; unsigned int becn: 1; + unsigned int bandwidth; /* Cisco LMI reporting only */ }state; }pvc_device; --- linux-2.6/drivers/net/wan/hdlc_fr.c 22 Jun 2004 03:25:28 -0000 1.13 +++ linux-2.6/drivers/net/wan/hdlc_fr.c 2 Apr 2005 13:12:18 -0000 @@ -2,7 +2,7 @@ * Generic HDLC support routines for Linux * Frame Relay support * - * Copyright (C) 1999 - 2003 Krzysztof Halasa + * Copyright (C) 1999 - 2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -27,6 +27,10 @@ active = open and "link reliable" exist = new = not used + CCITT LMI: ITU-T Q.933 Annex A + ANSI LMI: ANSI T1.617 Annex D + CISCO LMI: the original, aka "Gang of Four" LMI + */ #include @@ -49,45 +53,41 @@ #undef DEBUG_ECN #undef DEBUG_LINK -#define MAXLEN_LMISTAT 20 /* max size of status enquiry frame */ +#define FR_UI 0x03 +#define FR_PAD 0x00 + +#define NLPID_IP 0xCC +#define NLPID_IPV6 0x8E +#define NLPID_SNAP 0x80 +#define NLPID_PAD 0x00 +#define NLPID_CCITT_ANSI_LMI 0x08 +#define NLPID_CISCO_LMI 0x09 + + +#define LMI_CCITT_ANSI_DLCI 0 /* LMI DLCI */ +#define LMI_CISCO_DLCI 1023 + +#define LMI_CALLREF 0x00 /* Call Reference */ +#define LMI_ANSI_LOCKSHIFT 0x95 /* ANSI locking shift */ +#define LMI_ANSI_CISCO_REPTYPE 0x01 /* report type */ +#define LMI_CCITT_REPTYPE 0x51 +#define LMI_ANSI_CISCO_ALIVE 0x03 /* keep alive */ +#define LMI_CCITT_ALIVE 0x53 +#define LMI_ANSI_CISCO_PVCSTAT 0x07 /* PVC status */ +#define LMI_CCITT_PVCSTAT 0x57 + +#define LMI_FULLREP 0x00 /* full report */ +#define LMI_INTEGRITY 0x01 /* link integrity report */ +#define LMI_SINGLE 0x02 /* single PVC report */ -#define PVC_STATE_NEW 0x01 -#define PVC_STATE_ACTIVE 0x02 -#define PVC_STATE_FECN 0x08 /* FECN condition */ -#define PVC_STATE_BECN 0x10 /* BECN condition */ - - -#define FR_UI 0x03 -#define FR_PAD 0x00 - -#define NLPID_IP 0xCC -#define NLPID_IPV6 0x8E -#define NLPID_SNAP 0x80 -#define NLPID_PAD 0x00 -#define NLPID_Q933 0x08 - - -#define LMI_DLCI 0 /* LMI DLCI */ -#define LMI_PROTO 0x08 -#define LMI_CALLREF 0x00 /* Call Reference */ -#define LMI_ANSI_LOCKSHIFT 0x95 /* ANSI lockshift */ -#define LMI_REPTYPE 1 /* report type */ -#define LMI_CCITT_REPTYPE 0x51 -#define LMI_ALIVE 3 /* keep alive */ -#define LMI_CCITT_ALIVE 0x53 -#define LMI_PVCSTAT 7 /* pvc status */ -#define LMI_CCITT_PVCSTAT 0x57 -#define LMI_FULLREP 0 /* full report */ -#define LMI_INTEGRITY 1 /* link integrity report */ -#define LMI_SINGLE 2 /* single pvc report */ #define LMI_STATUS_ENQUIRY 0x75 #define LMI_STATUS 0x7D /* reply */ #define LMI_REPT_LEN 1 /* report type element length */ #define LMI_INTEG_LEN 2 /* link integrity element length */ -#define LMI_LENGTH 13 /* standard LMI frame length */ -#define LMI_ANSI_LENGTH 14 +#define LMI_CCITT_CISCO_LENGTH 13 /* LMI frame lengths */ +#define LMI_ANSI_LENGTH 14 typedef struct { @@ -223,51 +223,34 @@ } -static inline u16 status_to_dlci(u8 *status, int *active, int *new) -{ - *new = (status[2] & 0x08) ? 1 : 0; - *active = (status[2] & 0x02) ? 1 : 0; - - return ((status[0] & 0x3F) << 4) | ((status[1] & 0x78) >> 3); -} - - -static inline void dlci_to_status(u16 dlci, u8 *status, int active, int new) -{ - status[0] = (dlci >> 4) & 0x3F; - status[1] = ((dlci << 3) & 0x78) | 0x80; - status[2] = 0x80; - - if (new) - status[2] |= 0x08; - else if (active) - status[2] |= 0x02; -} - - - static int fr_hard_header(struct sk_buff **skb_p, u16 dlci) { u16 head_len; struct sk_buff *skb = *skb_p; switch (skb->protocol) { - case __constant_ntohs(ETH_P_IP): + case __constant_ntohs(NLPID_CCITT_ANSI_LMI): head_len = 4; skb_push(skb, head_len); - skb->data[3] = NLPID_IP; + skb->data[3] = NLPID_CCITT_ANSI_LMI; break; - case __constant_ntohs(ETH_P_IPV6): + case __constant_ntohs(NLPID_CISCO_LMI): head_len = 4; skb_push(skb, head_len); - skb->data[3] = NLPID_IPV6; + skb->data[3] = NLPID_CISCO_LMI; break; - case __constant_ntohs(LMI_PROTO): + case __constant_ntohs(ETH_P_IP): head_len = 4; skb_push(skb, head_len); - skb->data[3] = LMI_PROTO; + skb->data[3] = NLPID_IP; + break; + + case __constant_ntohs(ETH_P_IPV6): + head_len = 4; + skb_push(skb, head_len); + skb->data[3] = NLPID_IPV6; break; case __constant_ntohs(ETH_P_802_3): @@ -461,13 +444,14 @@ hdlc_device *hdlc = dev_to_hdlc(dev); struct sk_buff *skb; pvc_device *pvc = hdlc->state.fr.first_pvc; - int len = (hdlc->state.fr.settings.lmi == LMI_ANSI) ? LMI_ANSI_LENGTH - : LMI_LENGTH; - int stat_len = 3; + int lmi = hdlc->state.fr.settings.lmi; + int dce = hdlc->state.fr.settings.dce; + int len = lmi == LMI_ANSI ? LMI_ANSI_LENGTH : LMI_CCITT_CISCO_LENGTH; + int stat_len = (lmi == LMI_CISCO) ? 6 : 3; u8 *data; int i = 0; - if (hdlc->state.fr.settings.dce && fullrep) { + if (dce && fullrep) { len += hdlc->state.fr.dce_pvc_count * (2 + stat_len); if (len > HDLC_MAX_MRU) { printk(KERN_WARNING "%s: Too many PVCs while sending " @@ -484,29 +468,31 @@ } memset(skb->data, 0, len); skb_reserve(skb, 4); - skb->protocol = __constant_htons(LMI_PROTO); - fr_hard_header(&skb, LMI_DLCI); + if (lmi == LMI_CISCO) { + skb->protocol = __constant_htons(NLPID_CISCO_LMI); + fr_hard_header(&skb, LMI_CISCO_DLCI); + } else { + skb->protocol = __constant_htons(NLPID_CCITT_ANSI_LMI); + fr_hard_header(&skb, LMI_CCITT_ANSI_DLCI); + } data = skb->tail; data[i++] = LMI_CALLREF; - data[i++] = hdlc->state.fr.settings.dce - ? LMI_STATUS : LMI_STATUS_ENQUIRY; - if (hdlc->state.fr.settings.lmi == LMI_ANSI) + data[i++] = dce ? LMI_STATUS : LMI_STATUS_ENQUIRY; + if (lmi == LMI_ANSI) data[i++] = LMI_ANSI_LOCKSHIFT; - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_REPTYPE : LMI_REPTYPE; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_REPTYPE : + LMI_ANSI_CISCO_REPTYPE; data[i++] = LMI_REPT_LEN; data[i++] = fullrep ? LMI_FULLREP : LMI_INTEGRITY; - - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_ALIVE : LMI_ALIVE; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_ALIVE : LMI_ANSI_CISCO_ALIVE; data[i++] = LMI_INTEG_LEN; data[i++] = hdlc->state.fr.txseq =fr_lmi_nextseq(hdlc->state.fr.txseq); data[i++] = hdlc->state.fr.rxseq; - if (hdlc->state.fr.settings.dce && fullrep) { + if (dce && fullrep) { while (pvc) { - data[i++] = (hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_PVCSTAT : LMI_PVCSTAT; + data[i++] = lmi == LMI_CCITT ? LMI_CCITT_PVCSTAT : + LMI_ANSI_CISCO_PVCSTAT; data[i++] = stat_len; /* LMI start/restart */ @@ -523,8 +509,20 @@ fr_log_dlci_active(pvc); } - dlci_to_status(pvc->dlci, data + i, - pvc->state.active, pvc->state.new); + if (lmi == LMI_CISCO) { + data[i] = pvc->dlci >> 8; + data[i + 1] = pvc->dlci & 0xFF; + } else { + data[i] = (pvc->dlci >> 4) & 0x3F; + data[i + 1] = ((pvc->dlci << 3) & 0x78) | 0x80; + data[i + 2] = 0x80; + } + + if (pvc->state.new) + data[i + 2] |= 0x08; + else if (pvc->state.active) + data[i + 2] |= 0x02; + i += stat_len; pvc = pvc->next; } @@ -569,6 +567,8 @@ pvc_carrier(0, pvc); pvc->state.exist = pvc->state.active = 0; pvc->state.new = 0; + if (!hdlc->state.fr.settings.dce) + pvc->state.bandwidth = 0; pvc = pvc->next; } } @@ -583,11 +583,12 @@ int i, cnt = 0, reliable; u32 list; - if (hdlc->state.fr.settings.dce) + if (hdlc->state.fr.settings.dce) { reliable = hdlc->state.fr.request && time_before(jiffies, hdlc->state.fr.last_poll + hdlc->state.fr.settings.t392 * HZ); - else { + hdlc->state.fr.request = 0; + } else { hdlc->state.fr.last_errors <<= 1; /* Shift the list */ if (hdlc->state.fr.request) { if (hdlc->state.fr.reliable) @@ -634,65 +635,88 @@ static int fr_lmi_recv(struct net_device *dev, struct sk_buff *skb) { hdlc_device *hdlc = dev_to_hdlc(dev); - int stat_len; pvc_device *pvc; - int reptype = -1, error, no_ram; u8 rxseq, txseq; - int i; + int lmi = hdlc->state.fr.settings.lmi; + int dce = hdlc->state.fr.settings.dce; + int stat_len = (lmi == LMI_CISCO) ? 6 : 3, reptype, error, no_ram, i; - if (skb->len < ((hdlc->state.fr.settings.lmi == LMI_ANSI) - ? LMI_ANSI_LENGTH : LMI_LENGTH)) { + if (skb->len < (lmi == LMI_ANSI ? LMI_ANSI_LENGTH : + LMI_CCITT_CISCO_LENGTH)) { printk(KERN_INFO "%s: Short LMI frame\n", dev->name); return 1; } - if (skb->data[5] != (!hdlc->state.fr.settings.dce ? - LMI_STATUS : LMI_STATUS_ENQUIRY)) { - printk(KERN_INFO "%s: LMI msgtype=%x, Not LMI status %s\n", - dev->name, skb->data[2], - hdlc->state.fr.settings.dce ? "enquiry" : "reply"); + if (skb->data[3] != (lmi == LMI_CISCO ? NLPID_CISCO_LMI : + NLPID_CCITT_ANSI_LMI)) { + printk(KERN_INFO "%s: Received non-LMI frame with LMI" + " DLCI\n", dev->name); return 1; } - i = (hdlc->state.fr.settings.lmi == LMI_ANSI) ? 7 : 6; + if (skb->data[4] != LMI_CALLREF) { + printk(KERN_INFO "%s: Invalid LMI Call reference (0x%02X)\n", + dev->name, skb->data[4]); + return 1; + } + + if (skb->data[5] != (dce ? LMI_STATUS_ENQUIRY : LMI_STATUS)) { + printk(KERN_INFO "%s: Invalid LMI Message type (0x%02X)\n", + dev->name, skb->data[5]); + return 1; + } + + if (lmi == LMI_ANSI) { + if (skb->data[6] != LMI_ANSI_LOCKSHIFT) { + printk(KERN_INFO "%s: Not ANSI locking shift in LMI" + " message (0x%02X)\n", dev->name, skb->data[6]); + return 1; + } + i = 7; + } else + i = 6; - if (skb->data[i] != - ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_REPTYPE : LMI_REPTYPE)) { - printk(KERN_INFO "%s: Not a report type=%x\n", + if (skb->data[i] != (lmi == LMI_CCITT ? LMI_CCITT_REPTYPE : + LMI_ANSI_CISCO_REPTYPE)) { + printk(KERN_INFO "%s: Not an LMI Report type IE (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - i++; /* Skip length field */ + if (skb->data[++i] != LMI_REPT_LEN) { + printk(KERN_INFO "%s: Invalid LMI Report type IE length" + " (%u)\n", dev->name, skb->data[i]); + return 1; + } - reptype = skb->data[i++]; + reptype = skb->data[++i]; + if (reptype != LMI_INTEGRITY && reptype != LMI_FULLREP) { + printk(KERN_INFO "%s: Unsupported LMI Report type (0x%02X)\n", + dev->name, reptype); + return 1; + } - if (skb->data[i]!= - ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_ALIVE : LMI_ALIVE)) { - printk(KERN_INFO "%s: Unsupported status element=%x\n", - dev->name, skb->data[i]); + if (skb->data[++i] != (lmi == LMI_CCITT ? LMI_CCITT_ALIVE : + LMI_ANSI_CISCO_ALIVE)) { + printk(KERN_INFO "%s: Not an LMI Link integrity verification" + " IE (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - i++; /* Skip length field */ + if (skb->data[++i] != LMI_INTEG_LEN) { + printk(KERN_INFO "%s: Invalid LMI Link integrity verification" + " IE length (%u)\n", dev->name, skb->data[i]); + return 1; + } + i++; hdlc->state.fr.rxseq = skb->data[i++]; /* TX sequence from peer */ rxseq = skb->data[i++]; /* Should confirm our sequence */ txseq = hdlc->state.fr.txseq; - if (hdlc->state.fr.settings.dce) { - if (reptype != LMI_FULLREP && reptype != LMI_INTEGRITY) { - printk(KERN_INFO "%s: Unsupported report type=%x\n", - dev->name, reptype); - return 1; - } + if (dce) hdlc->state.fr.last_poll = jiffies; - } error = 0; if (!hdlc->state.fr.reliable) @@ -703,7 +727,7 @@ error = 1; } - if (hdlc->state.fr.settings.dce) { + if (dce) { if (hdlc->state.fr.fullrep_sent && !error) { /* Stop sending full report - the last one has been confirmed by DTE */ hdlc->state.fr.fullrep_sent = 0; @@ -725,6 +749,7 @@ hdlc->state.fr.dce_changed = 0; } + hdlc->state.fr.request = 1; /* got request */ fr_lmi_send(dev, reptype == LMI_FULLREP ? 1 : 0); return 0; } @@ -739,7 +764,6 @@ if (reptype != LMI_FULLREP) return 0; - stat_len = 3; pvc = hdlc->state.fr.first_pvc; while (pvc) { @@ -750,24 +774,35 @@ no_ram = 0; while (skb->len >= i + 2 + stat_len) { u16 dlci; + u32 bw; unsigned int active, new; - if (skb->data[i] != ((hdlc->state.fr.settings.lmi == LMI_CCITT) - ? LMI_CCITT_PVCSTAT : LMI_PVCSTAT)) { - printk(KERN_WARNING "%s: Invalid PVCSTAT ID: %x\n", - dev->name, skb->data[i]); + if (skb->data[i] != (lmi == LMI_CCITT ? LMI_CCITT_PVCSTAT : + LMI_ANSI_CISCO_PVCSTAT)) { + printk(KERN_INFO "%s: Not an LMI PVC status IE" + " (0x%02X)\n", dev->name, skb->data[i]); return 1; } - i++; - if (skb->data[i] != stat_len) { - printk(KERN_WARNING "%s: Invalid PVCSTAT length: %x\n", - dev->name, skb->data[i]); + if (skb->data[++i] != stat_len) { + printk(KERN_INFO "%s: Invalid LMI PVC status IE length" + " (%u)\n", dev->name, skb->data[i]); return 1; } i++; - dlci = status_to_dlci(skb->data + i, &active, &new); + new = !! (skb->data[i + 2] & 0x08); + active = !! (skb->data[i + 2] & 0x02); + if (lmi == LMI_CISCO) { + dlci = (skb->data[i] << 8) | skb->data[i + 1]; + bw = (skb->data[i + 3] << 16) | + (skb->data[i + 4] << 8) | + (skb->data[i + 5]); + } else { + dlci = ((skb->data[i] & 0x3F) << 4) | + ((skb->data[i + 1] & 0x78) >> 3); + bw = 0; + } pvc = add_pvc(dev, dlci); @@ -783,9 +818,11 @@ pvc->state.deleted = 0; if (active != pvc->state.active || new != pvc->state.new || + bw != pvc->state.bandwidth || !pvc->state.exist) { pvc->state.new = new; pvc->state.active = active; + pvc->state.bandwidth = bw; pvc_carrier(active, pvc); fr_log_dlci_active(pvc); } @@ -801,6 +838,7 @@ pvc_carrier(0, pvc); pvc->state.active = pvc->state.new = 0; pvc->state.exist = 0; + pvc->state.bandwidth = 0; fr_log_dlci_active(pvc); } pvc = pvc->next; @@ -829,22 +867,15 @@ dlci = q922_to_dlci(skb->data); - if (dlci == LMI_DLCI) { - if (hdlc->state.fr.settings.lmi == LMI_NONE) - goto rx_error; /* LMI packet with no LMI? */ - - if (data[3] == LMI_PROTO) { - if (fr_lmi_recv(ndev, skb)) - goto rx_error; - else { - dev_kfree_skb_any(skb); - return NET_RX_SUCCESS; - } - } - - printk(KERN_INFO "%s: Received non-LMI frame with LMI DLCI\n", - ndev->name); - goto rx_error; + if ((dlci == LMI_CCITT_ANSI_DLCI && + (hdlc->state.fr.settings.lmi == LMI_ANSI || + hdlc->state.fr.settings.lmi == LMI_CCITT)) || + (dlci == LMI_CISCO_DLCI && + hdlc->state.fr.settings.lmi == LMI_CISCO)) { + if (fr_lmi_recv(ndev, skb)) + goto rx_error; + dev_kfree_skb_any(skb); + return NET_RX_SUCCESS; } pvc = find_pvc(hdlc, dlci); @@ -1170,7 +1201,8 @@ if ((new_settings.lmi != LMI_NONE && new_settings.lmi != LMI_ANSI && - new_settings.lmi != LMI_CCITT) || + new_settings.lmi != LMI_CCITT && + new_settings.lmi != LMI_CISCO) || new_settings.t391 < 1 || new_settings.t392 < 2 || new_settings.n391 < 1 || --- linux-2.6/drivers/net/wan/hdlc_generic.c 3 Jun 2004 05:04:21 -0000 1.15 +++ linux-2.6/drivers/net/wan/hdlc_generic.c 2 Apr 2005 13:12:18 -0000 @@ -1,7 +1,7 @@ /* * Generic HDLC support routines for Linux * - * Copyright (C) 1999 - 2003 Krzysztof Halasa + * Copyright (C) 1999 - 2005 Krzysztof Halasa * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License @@ -38,7 +38,7 @@ #include -static const char* version = "HDLC support module revision 1.17"; +static const char* version = "HDLC support module revision 1.18"; #undef DEBUG_LINK @@ -126,10 +126,13 @@ if (!hdlc->open) goto carrier_exit; - if (hdlc->carrier) + if (hdlc->carrier) { + printk(KERN_INFO "%s: Carrier detected\n", dev->name); __hdlc_set_carrier_on(dev); - else + } else { + printk(KERN_INFO "%s: Carrier lost\n", dev->name); __hdlc_set_carrier_off(dev); + } carrier_exit: spin_unlock_irqrestore(&hdlc->state_lock, flags); @@ -157,8 +160,11 @@ spin_lock_irq(&hdlc->state_lock); - if (hdlc->carrier) + if (hdlc->carrier) { + printk(KERN_INFO "%s: Carrier detected\n", dev->name); __hdlc_set_carrier_on(dev); + } else + printk(KERN_INFO "%s: No carrier\n", dev->name); hdlc->open = 1; --=-=-=-- From jesse.brandeburg@intel.com Thu Apr 21 11:59:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 11:59:36 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LIxUdD026731 for ; Thu, 21 Apr 2005 11:59:31 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3LIxUdh003075; Thu, 21 Apr 2005 18:59:30 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3LIxDm2002160; Thu, 21 Apr 2005 18:59:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042111592918948 ; Thu, 21 Apr 2005 11:59:29 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:59:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Date: Thu, 21 Apr 2005 11:59:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Thread-Index: AcVGkyyPHj7NiBeoTwmFFcF2mKKBOgAD3Egg From: "Brandeburg, Jesse" To: "Scott Feldman" Cc: , "Chilakala, Mallikarjuna" , "Venkatesan, Ganesh" X-OriginalArrivalTime: 21 Apr 2005 18:59:29.0809 (UTC) FILETIME=[3F27F010:01C546A4] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3LIxUdD026731 X-archive-position: 202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 1748 Lines: 51 From: Scott Feldman >On Apr 19, 2005, at 10:50 PM, Malli Chilakala wrote: > >> Performance optimizations to e100 Tx Path > >So what is the net performance improvement with these changes? A massive drop in the number of transmit interrupts per second (yielding more cpu) when sending lots of frames (like forwarding). I don't remember my data specifically (stoopid brain). >> - nic->tx_command = cpu_to_le16(cb_tx | cb_i | cb_tx_sf | >> - ((nic->mac >= mac_82558_D101_A4) ? cb_cid : 0)); >> + /* no interrupt for every tx completion, delay = 256us >if not 557*/ >> + nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf | >> + ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i)); > >Where is this 256us delay coming from? Turning off the 'I' bit allows the transmit interrupt moderation to come on, and setting the cid (which was already set) to all 1's indicates the max delay (256 us) >> /* Template for a freshly allocated RFD */ >> nic->blank_rfd.command = cpu_to_le16(cb_el); >> @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str >> struct sk_buff *skb) >> { >> cb->command = nic->tx_command; >> + /* interrupt every 16 packets regardless of delay */ >> + if((nic->cbs_avail & ~15) == nic->cbs_avail) >cb->command |= cb_i; > >You messed up Big Endian. Yes, I did. Doh. >So you send out 15 packets with no i-bit set. Then what? No >interrupt >means no NAPI means no cleanup of those 15 packet skbs. This doesn't mean what you said. The i-bit setting every 15 is an optimization for minimzing latency. i-bit means interrupt immediately ignoring cid delay. This means every packet gets worst case a 256us delay before interrupt. If a receive or watchdog fires the interrupt they will get cleaned up sooner. From sfeldma@pobox.com Thu Apr 21 12:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 12:18:50 -0700 (PDT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LJIjdD027985 for ; Thu, 21 Apr 2005 12:18:47 -0700 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id B77BC7D8; Thu, 21 Apr 2005 15:18:42 -0400 (EDT) Received: from [192.168.0.2] (wbar2.sea1-4-5-058-148.sea1.dsl-verizon.net [4.5.58.148]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id E64C889; Thu, 21 Apr 2005 15:18:38 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70101da07ff38bf0de89894e91987702@pobox.com> Content-Transfer-Encoding: 7bit Cc: "Chilakala, Mallikarjuna" , "Venkatesan, Ganesh" , From: Scott Feldman Subject: Re: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path Date: Thu, 21 Apr 2005 12:17:56 -0700 To: "Brandeburg, Jesse" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 410 Lines: 16 On Apr 21, 2005, at 11:59 AM, Brandeburg, Jesse wrote: >> Where is this 256us delay coming from? > > Turning off the 'I' bit allows the transmit interrupt moderation to > come > on, and setting the cid (which was already set) to all 1's indicates > the > max delay (256 us) This makes sense. I forgot about the cid delay. I was afraid the "CPU Saver" microcode was coming back. Thanks Jesse. -scott From asimshankar@gmail.com Thu Apr 21 12:21:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 12:21:10 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LJL7dD031880 for ; Thu, 21 Apr 2005 12:21:08 -0700 Received: by wproxy.gmail.com with SMTP id 68so626613wri for ; Thu, 21 Apr 2005 12:21:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DCovcoWISgmTCBrZWiABUOF8qaRgwIMT16y61yz5p29vUOCFeBnmJCUefbgPjBxvKVFrACp+J8FKgfAbi9mrH+rHxpSXw2xrLThREzU+t594/18z3/r3NYjTOaj+WUwQXAU4yINE0lb8IDfPJFEv5CR2tkXrxqHjNWUW2P7FV18= Received: by 10.54.16.52 with SMTP id 52mr31784wrp; Thu, 21 Apr 2005 12:21:07 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Thu, 21 Apr 2005 12:21:07 -0700 (PDT) Message-ID: <7bca1cb50504211221655fd54c@mail.gmail.com> Date: Thu, 21 Apr 2005 14:21:07 -0500 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: BUG: HTB? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3LJL7dD031880 X-archive-position: 204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 1037 Lines: 38 Hi, I think there is a bug in htb_enqueue() (net/sched/sch_htb.c) Specifically, in the lines: if (cl == HTB_DIRECT) { /* enqueue to helper queue */ if (q->direct_queue.qlen < q->direct_qlen) { __skb_queue_tail(&q->direct_queue, skb); q->direct_pkts++; } } If a packet is classified as HTB_DIRECT but the direct_queue is already full, then the packet doesn't get enqueued but sch->q.qlen++ will happen a few lines later. Overflowing of the direct_queue probably rarely happens in practice, but I was playing around and noticed it happen in some corner cases of my testing. Should the packet be dropped instead? Like: if (cl == HTB_DIRECT) { /* enqueue to helper queue */ if (q->direct_queue.qlen < q->direct_qlen) { __skb_queue_tail(&q->direct_queue, skb); q->direct_pkts++; } else { sch->qstats.drops++; kfree_skb(skb); return NET_XMIT_DROP; } } Thanks, -- Asim From tgraf@suug.ch Thu Apr 21 12:55:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 12:56:01 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LJtkdD001657 for ; Thu, 21 Apr 2005 12:55:49 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 546C91C0EB; Thu, 21 Apr 2005 21:56:05 +0200 (CEST) Date: Thu, 21 Apr 2005 21:56:05 +0200 From: Thomas Graf To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: BUG: HTB? Message-ID: <20050421195605.GJ577@postel.suug.ch> References: <7bca1cb50504211221655fd54c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bca1cb50504211221655fd54c@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1128 Lines: 35 Hi, * Asim Shankar <7bca1cb50504211221655fd54c@mail.gmail.com> 2005-04-21 14:21 > Specifically, in the lines: > if (cl == HTB_DIRECT) { > /* enqueue to helper queue */ > if (q->direct_queue.qlen < q->direct_qlen) { > __skb_queue_tail(&q->direct_queue, skb); > q->direct_pkts++; > } > } > > If a packet is classified as HTB_DIRECT but the direct_queue is > already full, then the packet doesn't get enqueued but sch->q.qlen++ > will happen a few lines later. Overflowing of the direct_queue > probably rarely happens in practice, but I was playing around and > noticed it happen in some corner cases of my testing. Yes, that's a bug. > Should the packet be dropped instead? Like: > > if (cl == HTB_DIRECT) { > /* enqueue to helper queue */ > if (q->direct_queue.qlen < q->direct_qlen) { > __skb_queue_tail(&q->direct_queue, skb); > q->direct_pkts++; > } else { > sch->qstats.drops++; > kfree_skb(skb); > return NET_XMIT_DROP; > } > } Can you send a patch? From asimshankar@gmail.com Thu Apr 21 13:42:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 13:42:32 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LKgRdD004097 for ; Thu, 21 Apr 2005 13:42:29 -0700 Received: by wproxy.gmail.com with SMTP id 68so654902wri for ; Thu, 21 Apr 2005 13:42:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fN7mEtDU1VXd2rEySHrpLL4a94yHBhyHXVrTEyyAGEYJw69VGl10bgNaG5VB6ykfl3N5uPTyoM8FqBEVSIy8yLrsoHIQyaTcDB1yjcMTChfjDWDK+jvAKQ9/oJOyjNgqYcckSe7pWZGG+KKyE1+LzzUtaz52a9+Byj+tGh10lj4= Received: by 10.54.153.15 with SMTP id a15mr43968wre; Thu, 21 Apr 2005 13:41:26 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Thu, 21 Apr 2005 13:41:24 -0700 (PDT) Message-ID: <7bca1cb505042113417a5d9f59@mail.gmail.com> Date: Thu, 21 Apr 2005 15:41:24 -0500 From: Asim Shankar Reply-To: Asim Shankar To: Thomas Graf Subject: [PATCH] - sch_htb: Drop packet when direct queue overflows Cc: netdev@oss.sgi.com In-Reply-To: <20050421195605.GJ577@postel.suug.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_721_21838107.1114116084952" References: <7bca1cb50504211221655fd54c@mail.gmail.com> <20050421195605.GJ577@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/847/Thu Apr 21 09:26:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 2314 Lines: 61 ------=_Part_721_21838107.1114116084952 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > If a packet is classified as HTB_DIRECT but the direct_queue is > > already full, then the packet doesn't get enqueued but sch->q.qlen++ > > will happen a few lines later. Overflowing of the direct_queue > > probably rarely happens in practice, but I was playing around and > > noticed it happen in some corner cases of my testing. >=20 > Yes, that's a bug. >=20 > > Should the packet be dropped instead? Like: > > > > if (cl =3D=3D HTB_DIRECT) { > > /* enqueue to helper queue */ > > if (q->direct_queue.qlen < q->direct_qlen) { > > __skb_queue_tail(&q->direct_queue, skb); > > q->direct_pkts++; > > } else { > > sch->qstats.drops++; > > kfree_skb(skb); > > return NET_XMIT_DROP; > > } > > } >=20 > Can you send a patch? >=20 Patched pasted and attached: --- linux-2.6.11.7/net/sched/sch_htb.c=092005-04-07 13:57:45.000000000 -050= 0 +++ linux-2.6.11.7-new/net/sched/sch_htb.c=092005-04-21 14:17:36.272065816 = -0500 @@ -717,6 +717,10 @@ =09if (q->direct_queue.qlen < q->direct_qlen) { =09 __skb_queue_tail(&q->direct_queue, skb); =09 q->direct_pkts++; +=09} else { +=09 kfree_skb (skb); +=09 sch->qstats.drops++; +=09 return NET_XMIT_DROP; =09} #ifdef CONFIG_NET_CLS_ACT } else if (!cl) { ------=_Part_721_21838107.1114116084952 Content-Type: text/plain; name="patch-htb-2.6.11.7" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-htb-2.6.11.7" LS0tIGxpbnV4LTIuNi4xMS43L25ldC9zY2hlZC9zY2hfaHRiLmMJMjAwNS0wNC0wNyAxMzo1Nzo0 NS4wMDAwMDAwMDAgLTA1MDAKKysrIGxpbnV4LTIuNi4xMS43LW5ldy9uZXQvc2NoZWQvc2NoX2h0 Yi5jCTIwMDUtMDQtMjEgMTQ6MTc6MzYuMjcyMDY1ODE2IC0wNTAwCkBAIC03MTcsNiArNzE3LDEw IEBACiAJaWYgKHEtPmRpcmVjdF9xdWV1ZS5xbGVuIDwgcS0+ZGlyZWN0X3FsZW4pIHsKIAkgICAg X19za2JfcXVldWVfdGFpbCgmcS0+ZGlyZWN0X3F1ZXVlLCBza2IpOwogCSAgICBxLT5kaXJlY3Rf cGt0cysrOworCX0gZWxzZSB7CisJICAgIGtmcmVlX3NrYiAoc2tiKTsKKwkgICAgc2NoLT5xc3Rh dHMuZHJvcHMrKzsKKwkgICAgcmV0dXJuIE5FVF9YTUlUX0RST1A7CiAJfQogI2lmZGVmIENPTkZJ R19ORVRfQ0xTX0FDVAogICAgIH0gZWxzZSBpZiAoIWNsKSB7Cg== ------=_Part_721_21838107.1114116084952-- From herbert@gondor.apana.org.au Thu Apr 21 14:49:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 14:50:02 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LLnudD007856 for ; Thu, 21 Apr 2005 14:49:57 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOjVM-0002NP-00; Fri, 22 Apr 2005 07:46:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOjV4-0007ox-00; Fri, 22 Apr 2005 07:46:18 +1000 Date: Fri, 22 Apr 2005 07:46:18 +1000 To: Wolfgang Walter Cc: netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050421214618.GA29991@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1179 Lines: 35 On Thu, Apr 21, 2005 at 04:40:16PM +0200, Wolfgang Walter wrote: > > 10.148.0.0/23 dev eth2.1001 scope link src 10.148.0.1 > 10.148.32.0/20 via 10.148.15.30 dev eth0.1014 src 10.148.15.29 > default via 192.168.77.162 dev eth3 src 192.168.77.161 Although you probably have rp_filter turned, but please check cat /proc/sys/net/ipv4/conf/eth3/rp_filter anway. > src 10.148.0.0/23 dst 10.0.25.210/32 > dir fwd priority 0 There you go. This policy trumps your other policy. This one says that forwarded traffic matching it must carry no tunnel IPsec transforms. Therefore all IPsec packets matching it will be dropped. > src 10.148.4.0/28 dst 10.0.25.210/32 > dir fwd priority 2084 > tmpl src 192.168.9.237 dst 192.168.77.161 > proto esp spi 0x00000000 reqid 16465 mode tunnel The reason it worked with the old setkey and 2.6.7* is that all forwarded traffic would've been allowed, regardless of whether they matched the IPsec policy or not. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Thu Apr 21 14:54:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 14:54:24 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LLsIdD008462 for ; Thu, 21 Apr 2005 14:54:19 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3D4B31C0EB; Thu, 21 Apr 2005 23:54:40 +0200 (CEST) Date: Thu, 21 Apr 2005 23:54:40 +0200 From: Thomas Graf To: Asim Shankar Cc: netdev@oss.sgi.com, devik@cdi.cz Subject: Re: [PATCH] - sch_htb: Drop packet when direct queue overflows Message-ID: <20050421215440.GL577@postel.suug.ch> References: <7bca1cb50504211221655fd54c@mail.gmail.com> <20050421195605.GJ577@postel.suug.ch> <7bca1cb505042113417a5d9f59@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bca1cb505042113417a5d9f59@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 835 Lines: 30 [CCed Martin Devera] * Asim Shankar <7bca1cb505042113417a5d9f59@mail.gmail.com> 2005-04-21 15:41 > Patched pasted and attached: For patch formatting details see http://linux.yyz.us/patch-format.html A short description of the patch would be helpful. Besides of that... Signed-off-by: Thomas Graf > --- linux-2.6.11.7/net/sched/sch_htb.c 2005-04-07 13:57:45.000000000 -0500 > +++ linux-2.6.11.7-new/net/sched/sch_htb.c 2005-04-21 14:17:36.272065816 -0500 > @@ -717,6 +717,10 @@ > if (q->direct_queue.qlen < q->direct_qlen) { > __skb_queue_tail(&q->direct_queue, skb); > q->direct_pkts++; > + } else { > + kfree_skb (skb); Could you write this without the whitespace? > + sch->qstats.drops++; > + return NET_XMIT_DROP; > } > #ifdef CONFIG_NET_CLS_ACT > } else if (!cl) { Thanks. From kaber@trash.net Thu Apr 21 15:12:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 15:12:28 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LMCOdD010168 for ; Thu, 21 Apr 2005 15:12:25 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOjtn-0002Fr-Iu; Fri, 22 Apr 2005 00:11:51 +0200 Message-ID: <42682527.3000709@trash.net> Date: Fri, 22 Apr 2005 00:11:51 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic References: <20050421050815.GA23133@gondor.apana.org.au> In-Reply-To: <20050421050815.GA23133@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------010406000205090409080507" X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1885 Lines: 54 This is a multi-part message in MIME format. --------------010406000205090409080507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Here is a trivial patch to make the skb_under_panic/skb_over_panic > messages to look nicer. As it is their printk is joined onto the > first line of the BUG output because of a missing newline. How about this one instead? Besides the missing newlines, it adds head/data/tail/end to the output, which can give valuable hints about what happend before. Signed-off-by: Patrick McHardy --------------010406000205090409080507 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/core/skbuff.c 1.44 vs edited ===== --- 1.44/net/core/skbuff.c 2005-03-11 21:32:26 +01:00 +++ edited/net/core/skbuff.c 2005-04-22 00:08:09 +02:00 @@ -86,8 +86,10 @@ */ void skb_over_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:over: %p:%d put:%d dev:%s", - here, skb->len, sz, skb->dev ? skb->dev->name : ""); + printk(KERN_INFO "skb_over_panic: text:%p len:%d put:%d head:%p " + "data:%p tail:%p end:%p dev:%s\n", + here, skb->len, sz, skb->head, skb->data, skb->tail, skb->end, + skb->dev ? skb->dev->name : ""); BUG(); } @@ -102,8 +104,10 @@ void skb_under_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:under: %p:%d put:%d dev:%s", - here, skb->len, sz, skb->dev ? skb->dev->name : ""); + printk(KERN_INFO "skb_under_panic: text:%p len:%d put:%d head:%p " + "data:%p tail:%p end:%p dev:%s\n", + here, skb->len, sz, skb->head, skb->data, skb->tail, skb->end, + skb->dev ? skb->dev->name : ""); BUG(); } --------------010406000205090409080507-- From kaber@trash.net Thu Apr 21 15:20:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 15:20:48 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LMKidD011142 for ; Thu, 21 Apr 2005 15:20:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOk1o-0002Ia-6C; Fri, 22 Apr 2005 00:20:08 +0200 Message-ID: <42682718.3060601@trash.net> Date: Fri, 22 Apr 2005 00:20:08 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Patrick McHardy CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> In-Reply-To: <42682527.3000709@trash.net> Content-Type: multipart/mixed; boundary="------------080708050204060005010301" X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1805 Lines: 55 This is a multi-part message in MIME format. --------------080708050204060005010301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > How about this one instead? Besides the missing newlines, it adds > head/data/tail/end to the output, which can give valuable hints > about what happend before. While we're at it, lets also replace KERN_INFO by KERN_EMERG to make sure the user gets to see it. > Signed-off-by: Patrick McHardy --------------080708050204060005010301 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/core/skbuff.c 1.44 vs edited ===== --- 1.44/net/core/skbuff.c 2005-03-11 21:32:26 +01:00 +++ edited/net/core/skbuff.c 2005-04-22 00:18:53 +02:00 @@ -86,8 +86,10 @@ */ void skb_over_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:over: %p:%d put:%d dev:%s", - here, skb->len, sz, skb->dev ? skb->dev->name : ""); + printk(KERN_EMERG "skb_over_panic: text:%p len:%d put:%d head:%p " + "data:%p tail:%p end:%p dev:%s\n", + here, skb->len, sz, skb->head, skb->data, skb->tail, skb->end, + skb->dev ? skb->dev->name : ""); BUG(); } @@ -102,8 +104,10 @@ void skb_under_panic(struct sk_buff *skb, int sz, void *here) { - printk(KERN_INFO "skput:under: %p:%d put:%d dev:%s", - here, skb->len, sz, skb->dev ? skb->dev->name : ""); + printk(KERN_EMERG "skb_under_panic: text:%p len:%d put:%d head:%p " + "data:%p tail:%p end:%p dev:%s\n", + here, skb->len, sz, skb->head, skb->data, skb->tail, skb->end, + skb->dev ? skb->dev->name : ""); BUG(); } --------------080708050204060005010301-- From asimshankar@gmail.com Thu Apr 21 16:02:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:02:59 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LN2udD013525 for ; Thu, 21 Apr 2005 16:02:57 -0700 Received: by wproxy.gmail.com with SMTP id 68so687381wri for ; Thu, 21 Apr 2005 16:02:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EtlYhY3+LCih2JjkCg4GJ25wModGlo37Ojh/r04+22vohkRgtf2hzH2WLC4usmFg5+ZO09RZ+mgDrlewgxoyRmSEi7ZtgxD8Oy6RuPx2lGcQcDJvEzOb83XVtd4JIMRf+AJeZpwMuvs9XJ88XmBwC6Mv3jJWIpdGaBTULWeLkiI= Received: by 10.54.77.3 with SMTP id z3mr143424wra; Thu, 21 Apr 2005 16:02:55 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Thu, 21 Apr 2005 16:02:55 -0700 (PDT) Message-ID: <7bca1cb505042116022f64a87e@mail.gmail.com> Date: Thu, 21 Apr 2005 18:02:55 -0500 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: [PATCH 2.6.11.7] sch_htb: Drop packet when direct queue is full Cc: devik@cdi.cz, Thomas Graf In-Reply-To: <20050421215440.GL577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7bca1cb50504211221655fd54c@mail.gmail.com> <20050421195605.GJ577@postel.suug.ch> <7bca1cb505042113417a5d9f59@mail.gmail.com> <20050421215440.GL577@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3LN2udD013525 X-archive-position: 212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 740 Lines: 21 htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is destined for the direct_queue but the direct_queue is full. (Before this: erroneously returned NET_XMIT_SUCCESS even though the packet was not enqueued) Signed-off-by: Asim Shankar --- linux-2.6.11.7/net/sched/sch_htb.c.orig 2005-04-21 17:40:05.305709014 -0500 +++ linux-2.6.11.7/net/sched/sch_htb.c 2005-04-21 17:35:27.872624173 -0500 @@ -717,6 +717,10 @@ static int htb_enqueue(struct sk_buff *s if (q->direct_queue.qlen < q->direct_qlen) { __skb_queue_tail(&q->direct_queue, skb); q->direct_pkts++; + } else { + kfree_skb(skb); + sch->qstats.drops++; + return NET_XMIT_DROP; } #ifdef CONFIG_NET_CLS_ACT } else if (!cl) { From kaber@trash.net Thu Apr 21 16:10:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:10:40 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNAYdD014367 for ; Thu, 21 Apr 2005 16:10:35 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOkoT-0002RX-H6; Fri, 22 Apr 2005 01:10:25 +0200 Message-ID: <426832E1.7020003@trash.net> Date: Fri, 22 Apr 2005 01:10:25 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> In-Reply-To: <20050421132020.41858bc4@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 525 Lines: 13 Stephen Hemminger wrote: > So duplication is a no go... > Unless there is a different way of accounting for qlen (like a callback). Instead of a callback you could store parent pointers in struct Qdisc and walk up the tree. One place that would need additional changes to cope with qlen changes of more than 1 is HFSC. It uses q.qlen == 1 as indication that a leaf qdisc was activated by the last enqueue operation. An increment of 2 when q.qlen was 0 before would cause HFSC to forget to activate a class. Regards Patrick From herbert@gondor.apana.org.au Thu Apr 21 16:14:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:14:57 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNEpdD015048 for ; Thu, 21 Apr 2005 16:14:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOksb-0003BL-00; Fri, 22 Apr 2005 09:14:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOksX-0002dW-00; Fri, 22 Apr 2005 09:14:37 +1000 Date: Fri, 22 Apr 2005 09:14:37 +1000 To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic Message-ID: <20050421231437.GA10119@gondor.apana.org.au> References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> <42682718.3060601@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42682718.3060601@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 607 Lines: 15 On Fri, Apr 22, 2005 at 12:20:08AM +0200, Patrick McHardy wrote: > Patrick McHardy wrote: > >How about this one instead? Besides the missing newlines, it adds > >head/data/tail/end to the output, which can give valuable hints > >about what happend before. > > While we're at it, lets also replace KERN_INFO by KERN_EMERG to > make sure the user gets to see it. Thanks Patrick, this looks great. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rick.jones2@hp.com Thu Apr 21 16:14:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:15:00 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNEwdD015058 for ; Thu, 21 Apr 2005 16:14:58 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 9F01B402261 for ; Thu, 21 Apr 2005 16:14:57 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA17280 for ; Thu, 21 Apr 2005 16:14:57 -0700 (PDT) Message-ID: <426833F0.9010803@hp.com> Date: Thu, 21 Apr 2005 16:14:56 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev Subject: is UDP_CORK "real" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1755 Lines: 31 I've been messing about with the latest netperf, and by accident specified -D for TCP_NODELAY on a UDP_RR test. In the past, and even today on HP-UX at least, that results in an error on the setsockopt(). However, with the getaddrinfo() changes to netperf and the addtion of SCTP support, setsockopt() is now called with the ai_protocol from the getaddrinfo() call rather than a hard-coded IPPROTO_TCP. Sooo, for UDP tests that becomes an IPPROTO_UDP. When I run the UDP_RR test with -D set on a 2.6 kernel, netperf stops cold until the test timer expires. It seems there is an overlap in the setsockopt() option numbers between TCP and UDP under Linux 2.6 at least, I've not gone back to check 2.4. TCP_NODELAY and UDP_CORK are both defined as "1". Those seem to be the only two options that overlap. The other UDP_mumble option is defined to be 100, which is presently outside the range of the TCP_mumble options. So, instead of trying to set TCP_NODELAY on a UDP socket, which would fail; netperf was unwittingly setting UDP_CORK on a UDP socket, which would succede. Is UDP_CORK going to be an ongoing feature? Is it a "real" feature today? While man tcp described TCP_CORK, on the two places I've checked thusfar, man udp does not describe UDP_CORK. I'm not sure if that means UDP_CORK is "unreal" or just that the udp manpage needs repair (or was out of date on my systems). I _can_ go in and have netperf check for IPPROTO_TCP and/or IPPROTO_SCTP before making the _NODELAY setsockopt, and I suppose I probably should, but if UDP_CORK isn't going to be around, or if TCP and UDP socket options were not _really_ meant to overlap... although the level option would seem to be there to allow it... thanks, rick jones From shemminger@osdl.org Thu Apr 21 16:23:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:23:11 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNN6dD019910 for ; Thu, 21 Apr 2005 16:23:08 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3LNMws4007735 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Apr 2005 16:23:02 -0700 Date: Fri, 22 Apr 2005 09:22:21 +1000 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen Message-ID: <20050422092221.4950e23c@localhost.localdomain> In-Reply-To: <426832E1.7020003@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> <426832E1.7020003@trash.net> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 216 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: 929 Lines: 28 On Fri, 22 Apr 2005 01:10:25 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > So duplication is a no go... > > Unless there is a different way of accounting for qlen (like a callback). > > Instead of a callback you could store parent pointers in struct Qdisc > and walk up the tree. One place that would need additional changes to > cope with qlen changes of more than 1 is HFSC. It uses q.qlen == 1 as > indication that a leaf qdisc was activated by the last enqueue > operation. An increment of 2 when q.qlen was 0 before would cause HFSC > to forget to activate a class. I'm thinking of changing enqueue (and maybe later dequeue) API to decouple the qlen assumption. Either: rc = qdisc->enqueue(skb, qdisc, &my->qlen) or add NET_XMIT_DUPPED rc = qdisc->enqueue(skb, qdisc); if (rc < NET_XMIT_SUCCESS) { ++my->dropped; } else { my->qlen++; if (rc == NET_XMIT_DUPPED) my->qlen++; } From kaber@trash.net Thu Apr 21 16:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:25:25 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNPMdD020374 for ; Thu, 21 Apr 2005 16:25:23 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOl2w-0002TF-Fl; Fri, 22 Apr 2005 01:25:22 +0200 Message-ID: <42683662.6060003@trash.net> Date: Fri, 22 Apr 2005 01:25:22 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> <42682718.3060601@trash.net> <20050421231437.GA10119@gondor.apana.org.au> In-Reply-To: <20050421231437.GA10119@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 322 Lines: 11 Herbert Xu wrote: > Thanks Patrick, this looks great. BTW, Do you know if that ppp problem (Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91) was already fixed? Otherwise I'd suggest that the reporter should capture a crash again with this patch applied. Regards Patrick From davem@davemloft.net Thu Apr 21 16:32:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:32:13 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNW9dD021422 for ; Thu, 21 Apr 2005 16:32:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOl2f-0003M3-00; Thu, 21 Apr 2005 16:25:05 -0700 Date: Thu, 21 Apr 2005 16:25:05 -0700 From: "David S. Miller" To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: is UDP_CORK "real" Message-Id: <20050421162505.3db8ed7c.davem@davemloft.net> In-Reply-To: <426833F0.9010803@hp.com> References: <426833F0.9010803@hp.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 289 Lines: 10 On Thu, 21 Apr 2005 16:14:56 -0700 Rick Jones wrote: > Is UDP_CORK going to be an ongoing feature? Yes, it's there and it's real. If netperf is passing a TCP socket option number in for a setsockopt() on a UDP socket, how in the world is that the kernel's problem? From kaber@trash.net Thu Apr 21 16:39:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:39:46 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNdfdD022582 for ; Thu, 21 Apr 2005 16:39:43 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOlGe-0002UA-86; Fri, 22 Apr 2005 01:39:32 +0200 Message-ID: <426839B4.2090502@trash.net> Date: Fri, 22 Apr 2005 01:39:32 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> <426832E1.7020003@trash.net> <20050422092221.4950e23c@localhost.localdomain> In-Reply-To: <20050422092221.4950e23c@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 821 Lines: 26 Stephen Hemminger wrote: > I'm thinking of changing enqueue (and maybe later dequeue) API to decouple > the qlen assumption. > > Either: > rc = qdisc->enqueue(skb, qdisc, &my->qlen) > or add NET_XMIT_DUPPED > rc = qdisc->enqueue(skb, qdisc); > if (rc < NET_XMIT_SUCCESS) { > ++my->dropped; > } else { > my->qlen++; > if (rc == NET_XMIT_DUPPED) > my->qlen++; > } To be frank, I don't like either one. Both have the same problem wrt. HFSC, the first solution requires changes all over the place, the second one is unflexible and also requires lots of changes. I don't see what could benefit from this API change besides netem, so I'd vote to go with my proposed solution: store the parent pointers in struct Qdisc, add code to walk up the tree and adjust the qlen to netem, and fix up HFSC. Regards Patrick From davem@davemloft.net Thu Apr 21 16:42:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:42:51 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNgmdD023253 for ; Thu, 21 Apr 2005 16:42:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlCg-0003Qw-00; Thu, 21 Apr 2005 16:35:26 -0700 Date: Thu, 21 Apr 2005 16:35:26 -0700 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-Id: <20050421163526.7a29a76f.davem@davemloft.net> In-Reply-To: <20050406022155.GA12952@gondor.apana.org.au> References: <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> <4252EEA2.5020107@trash.net> <20050406022155.GA12952@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 722 Lines: 16 On Wed, 6 Apr 2005 12:21:55 +1000 Herbert Xu wrote: > On Tue, Apr 05, 2005 at 10:01:38PM +0200, Patrick McHardy wrote: > > > > Good idea, I didn't think of this. This patch is without replacement of > > xfrm_init_tempsel(), it caused an "unused function" warning and, as I > > mentioned before, I still need the function. > > Thanks. Just one more issue that I can think of, the check should > only be done when tmpl->id.spi != 0. Otherwise the presence of > valid states with differing state selectors will prevent new > sessions from starting up. Is it really worthwhile, right now, to change that tmpl->id.daddr to daddr? That seems to be all that Patrick's most recent patch does. From herbert@gondor.apana.org.au Thu Apr 21 16:51:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:51:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNp0dD024128 for ; Thu, 21 Apr 2005 16:51:01 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOlRe-0003L7-00; Fri, 22 Apr 2005 09:50:54 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOlRc-0002hf-00; Fri, 22 Apr 2005 09:50:52 +1000 Date: Fri, 22 Apr 2005 09:50:52 +1000 To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic Message-ID: <20050421235052.GA10371@gondor.apana.org.au> References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> <42682718.3060601@trash.net> <20050421231437.GA10119@gondor.apana.org.au> <42683662.6060003@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42683662.6060003@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1153 Lines: 28 On Fri, Apr 22, 2005 at 01:25:22AM +0200, Patrick McHardy wrote: > > BTW, Do you know if that ppp problem (Fw: [Bugme-new] [Bug 4381] New: > When i try to start a pppoe conn., crash at net/core/skbuff.c:91) was > already fixed? Otherwise I'd suggest that the reporter should capture > a crash again with this patch applied. Unfortunately the reporter says that he can't reproduce it. However, I have the suspicion that this is really the same as the vpnc/tun bug (4279) that prompted you to make the self-modification fix to tun.c. Now there is no doubt that your patch fixed a real bug in tun.c. However, I don't think it could have caused the crash in 4279. The reason is that the crash dump shows that the length that was supplied to skb_put is in fact positive (0xe4 in one case and 0xf4 in another). As soon as I get confirmation from the submitter that he can still reproduce this I'll get him to try your debugging patch. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Thu Apr 21 16:50:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:50:29 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNoPdD024093 for ; Thu, 21 Apr 2005 16:50:25 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DOlRE-0004Sb-Mq for netdev@oss.sgi.com; Thu, 21 Apr 2005 19:50:28 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOlRA-0003zz-AW; Thu, 21 Apr 2005 19:50:24 -0400 Subject: Re: Problem with IPSEC tunnel mode From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Wolfgang Walter , netdev@oss.sgi.com In-Reply-To: <20050421214618.GA29991@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Thu, 21 Apr 2005 19:50:19 -0400 Message-Id: <1114127419.10572.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 221 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: 1497 Lines: 53 On Fri, 2005-22-04 at 07:46 +1000, Herbert Xu wrote: > > > src 10.148.0.0/23 dst 10.0.25.210/32 > > dir fwd priority 0 > > There you go. This policy trumps your other policy. This one > says that forwarded traffic matching it must carry no tunnel > IPsec transforms. Therefore all IPsec packets matching it will > be dropped. > > > src 10.148.4.0/28 dst 10.0.25.210/32 > > dir fwd priority 2084 > > tmpl src 192.168.9.237 dst 192.168.77.161 > > proto esp spi 0x00000000 reqid 16465 mode tunnel > > The reason it worked with the old setkey and 2.6.7* is that all > forwarded traffic would've been allowed, regardless of whether > they matched the IPsec policy or not. > Herbert, What was the reason there exist a FWD direction in the policies? Also - shouldnt the FWD policies closely match the OUT ones instead of the IN direction (browsing the forwarding code)? i.e does this look odd to you (picking a sample from Wolfgangs output): ------------ src 10.148.0.0/23 dst 10.148.3.32/28 dir out priority 2372 tmpl src 192.168.77.161 dst 192.168.99.93 proto esp spi 0x00000000 reqid 17757 mode tunnel src 10.148.3.32/28 dst 10.148.0.0/23 dir fwd priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17757 mode tunnel src 10.148.3.32/28 dst 10.148.0.0/23 dir in priority 2372 tmpl src 192.168.99.93 dst 192.168.77.161 proto esp spi 0x00000000 reqid 17757 mode tunnel ------ Just matched against reqid. cheers, jamal From davem@davemloft.net Thu Apr 21 16:51:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:51:23 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNpIdD024195 for ; Thu, 21 Apr 2005 16:51:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlLG-0003TU-00; Thu, 21 Apr 2005 16:44:18 -0700 Date: Thu, 21 Apr 2005 16:44:18 -0700 From: "David S. Miller" To: Patrick McHardy Cc: kaber@trash.net, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic Message-Id: <20050421164418.34cc81a2.davem@davemloft.net> In-Reply-To: <42682718.3060601@trash.net> References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> <42682718.3060601@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 459 Lines: 14 On Fri, 22 Apr 2005 00:20:08 +0200 Patrick McHardy wrote: > Patrick McHardy wrote: > > How about this one instead? Besides the missing newlines, it adds > > head/data/tail/end to the output, which can give valuable hints > > about what happend before. > > While we're at it, lets also replace KERN_INFO by KERN_EMERG to > make sure the user gets to see it. > > > Signed-off-by: Patrick McHardy Applied, thanks Patrick. From davem@davemloft.net Thu Apr 21 16:52:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:52:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNqodD025091 for ; Thu, 21 Apr 2005 16:52:50 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlMg-0003Vj-00; Thu, 21 Apr 2005 16:45:46 -0700 Date: Thu, 21 Apr 2005 16:45:46 -0700 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 1/1][ATM]: sk_atm() conversion missed subtle change of vcc Message-Id: <20050421164546.45d6cfb6.davem@davemloft.net> In-Reply-To: <200504141748.j3EHm6Q0022689@ginger.cmf.nrl.navy.mil> References: <200504141748.j3EHm6Q0022689@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 152 Lines: 6 On Thu, 14 Apr 2005 13:48:06 -0400 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From herbert@gondor.apana.org.au Thu Apr 21 16:53:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:53:33 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNrSdD025439 for ; Thu, 21 Apr 2005 16:53:29 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOlTf-0003Lw-00; Fri, 22 Apr 2005 09:52:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOlTb-0002in-00; Fri, 22 Apr 2005 09:52:55 +1000 Date: Fri, 22 Apr 2005 09:52:55 +1000 To: "David S. Miller" Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-ID: <20050421235255.GA10451@gondor.apana.org.au> References: <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> <4252EEA2.5020107@trash.net> <20050406022155.GA12952@gondor.apana.org.au> <20050421163526.7a29a76f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050421163526.7a29a76f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 730 Lines: 18 On Thu, Apr 21, 2005 at 04:35:26PM -0700, David S. Miller wrote: > > > Thanks. Just one more issue that I can think of, the check should > > only be done when tmpl->id.spi != 0. Otherwise the presence of > > valid states with differing state selectors will prevent new > > sessions from starting up. > > Is it really worthwhile, right now, to change that tmpl->id.daddr to > daddr? That seems to be all that Patrick's most recent patch does. Yes, because tmpl->id.daddr can be zero when daddr is not zero. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Thu Apr 21 16:54:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:54:32 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNsSdD026017 for ; Thu, 21 Apr 2005 16:54:28 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOlUN-0002YM-VD; Fri, 22 Apr 2005 01:53:43 +0200 Message-ID: <42683D07.6090808@trash.net> Date: Fri, 22 Apr 2005 01:53:43 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel References: <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> <4252EEA2.5020107@trash.net> <20050406022155.GA12952@gondor.apana.org.au> <20050421163526.7a29a76f.davem@davemloft.net> In-Reply-To: <20050421163526.7a29a76f.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------010608010000090806080304" X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1757 Lines: 49 This is a multi-part message in MIME format. --------------010608010000090806080304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Wed, 6 Apr 2005 12:21:55 +1000 > Herbert Xu wrote: > >>Thanks. Just one more issue that I can think of, the check should >>only be done when tmpl->id.spi != 0. Otherwise the presence of >>valid states with differing state selectors will prevent new >>sessions from starting up. > > Is it really worthwhile, right now, to change that tmpl->id.daddr to > daddr? That seems to be all that Patrick's most recent patch does. Yes, tmpl->id.daddr might be 0, in which case the destination of the packet or previous tunnel mode transforms is used. daddr always contains the correct adress, so we should use it to check for duplicate SPIs. But as Herbert noted, we shouldn't perform the check if tmpl->id.spi == 0, so here is a new patch. Signed-off-by: Patrick McHardy --------------010608010000090806080304 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/xfrm/xfrm_state.c 1.60 vs edited ===== --- 1.60/net/xfrm/xfrm_state.c 2005-04-01 07:19:54 +02:00 +++ edited/net/xfrm/xfrm_state.c 2005-04-22 01:51:37 +02:00 @@ -357,8 +357,9 @@ x = best; if (!x && !error && !acquire_in_progress) { - x0 = afinfo->state_lookup(&tmpl->id.daddr, tmpl->id.spi, tmpl->id.proto); - if (x0 != NULL) { + if (tmpl->id.spi && + (x0 = afinfo->state_lookup(daddr, tmpl->id.spi, + tmpl->id.proto)) != NULL) { xfrm_state_put(x0); error = -EEXIST; goto out; --------------010608010000090806080304-- From rick.jones2@hp.com Thu Apr 21 16:53:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:53:50 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNrjdD025586 for ; Thu, 21 Apr 2005 16:53:45 -0700 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id E739D2CF3 for ; Thu, 21 Apr 2005 16:53:44 -0700 (PDT) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA17571 for ; Thu, 21 Apr 2005 16:53:44 -0700 (PDT) Message-ID: <42683D08.7030201@hp.com> Date: Thu, 21 Apr 2005 16:53:44 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: is UDP_CORK "real" References: <426833F0.9010803@hp.com> <20050421162505.3db8ed7c.davem@davemloft.net> In-Reply-To: <20050421162505.3db8ed7c.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 765 Lines: 23 David S. Miller wrote: > On Thu, 21 Apr 2005 16:14:56 -0700 > Rick Jones wrote: > > >>Is UDP_CORK going to be an ongoing feature? > > > Yes, it's there and it's real. > > If netperf is passing a TCP socket option number in for > a setsockopt() on a UDP socket, how in the world is that > the kernel's problem? I didn't really mean to say that it was a kernel problem per se. I was trying to understand the space, make sure that it was deliberate that there were actual overlaps between the TCP_mumble and UDP_mumble options and such. The release bits for netperf 2.4.0 will have checks to make sure it does not try to set "TCP_NODLEAY" on a UDP socket. Call it a 13 year lingering misfeature in netperf if you like :) rick jones From davem@davemloft.net Thu Apr 21 16:56:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:56:12 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNu8dD027344 for ; Thu, 21 Apr 2005 16:56:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlPy-0003X7-00; Thu, 21 Apr 2005 16:49:10 -0700 Date: Thu, 21 Apr 2005 16:49:10 -0700 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 1/3][ATM]: net/atm/resources.c: remove __free_atm_dev Message-Id: <20050421164910.6688db42.davem@davemloft.net> In-Reply-To: <200504101526.j3AFQlPS007582@ginger.cmf.nrl.navy.mil> References: <200504101526.j3AFQlPS007582@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 147 Lines: 6 On Sun, 10 Apr 2005 11:26:48 -0400 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks. From davem@davemloft.net Thu Apr 21 16:54:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 16:54:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3LNsqdD026352 for ; Thu, 21 Apr 2005 16:54:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlOa-0003WH-00; Thu, 21 Apr 2005 16:47:44 -0700 Date: Thu, 21 Apr 2005 16:47:43 -0700 From: "David S. Miller" To: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) Cc: ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH 1/2][AX25] make ax25_queue_xmit a net_device parameter Message-Id: <20050421164743.43ff2e49.davem@davemloft.net> In-Reply-To: <20050404194835.GI640@conectiva.com.br> References: <20050404194835.GI640@conectiva.com.br> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 226 Lines: 9 On Mon, 4 Apr 2005 16:48:35 -0300 acme@ghostprotocols.net (Arnaldo Carvalho de Melo) wrote: > Hi David, Ralf, > > This one is just in preparation for the second, that introduces > ax25_type_trans. Applied, thanks Arnaldo. From herbert@gondor.apana.org.au Thu Apr 21 17:01:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:01:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M01jdD029752 for ; Thu, 21 Apr 2005 17:01:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOlYr-0003QZ-00; Fri, 22 Apr 2005 09:58:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOlYa-0002je-00; Fri, 22 Apr 2005 09:58:04 +1000 Date: Fri, 22 Apr 2005 09:58:02 +1000 To: jamal Cc: Wolfgang Walter , netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050421235802.GB10451@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> <1114127419.10572.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114127419.10572.4.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1033 Lines: 23 On Thu, Apr 21, 2005 at 07:50:19PM -0400, jamal wrote: > What was the reason there exist a FWD direction in the policies? You should really ask Alexey about that :) I myself had the same question when I first started in this area. However, since it has been present since the very beginning and people are already relying on it, we will have to live with it. > Also - shouldnt the FWD policies closely match the OUT ones instead of > the IN direction (browsing the forwarding code)? i.e > does this look odd to you (picking a sample from Wolfgangs output): The FWD policies are analogous to the FORWARD table in netfilter. The FWD policies apply to forwarded packet, meaning packets that end up in ip_forward instead of ip_local_deliver. The IN policies only apply to packets that end up in ip_local_deliver. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Thu Apr 21 17:02:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:02:34 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M02UdD029794 for ; Thu, 21 Apr 2005 17:02:32 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOlcs-0002aA-38; Fri, 22 Apr 2005 02:02:30 +0200 Message-ID: <42683F15.8000908@trash.net> Date: Fri, 22 Apr 2005 02:02:29 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: [NET] Add missing newline for skb_*_panic References: <20050421050815.GA23133@gondor.apana.org.au> <42682527.3000709@trash.net> <42682718.3060601@trash.net> <20050421231437.GA10119@gondor.apana.org.au> <42683662.6060003@trash.net> <20050421235052.GA10371@gondor.apana.org.au> In-Reply-To: <20050421235052.GA10371@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1173 Lines: 32 Herbert Xu wrote: > On Fri, Apr 22, 2005 at 01:25:22AM +0200, Patrick McHardy wrote: > >>BTW, Do you know if that ppp problem (Fw: [Bugme-new] [Bug 4381] New: >>When i try to start a pppoe conn., crash at net/core/skbuff.c:91) was >>already fixed? Otherwise I'd suggest that the reporter should capture >>a crash again with this patch applied. > > > Unfortunately the reporter says that he can't reproduce it. > > However, I have the suspicion that this is really the same as the > vpnc/tun bug (4279) that prompted you to make the self-modification > fix to tun.c. > > Now there is no doubt that your patch fixed a real bug in tun.c. > However, I don't think it could have caused the crash in 4279. > The reason is that the crash dump shows that the length that > was supplied to skb_put is in fact positive (0xe4 in one case > and 0xf4 in another). You're probably right, I only spent a few minutes looking for a possible reason. Unfortunately the skb_over_panic() output wasn't included in the report. > As soon as I get confirmation from the submitter that he can > still reproduce this I'll get him to try your debugging patch. Great, thanks. Regards Patrick From davem@davemloft.net Thu Apr 21 17:10:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:10:25 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0AMdD001316 for ; Thu, 21 Apr 2005 17:10:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOldj-0003fO-00; Thu, 21 Apr 2005 17:03:23 -0700 Date: Thu, 21 Apr 2005 17:03:23 -0700 From: "David S. Miller" To: "John W. Linville" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc2 8/10] tg3: use TG3_FLG2_57{05,50}_PLUS flags in tg3_get_invariants Message-Id: <20050421170323.64e19505.davem@davemloft.net> In-Reply-To: <04132005193845.8775@laptop> References: <04132005193845.8720@laptop> <04132005193845.8775@laptop> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 256 Lines: 9 On Wed, 13 Apr 2005 19:38:45 -0400 "John W. Linville" wrote: > Rewrite checks in tg3_get_invariants to use TG3_FLG2_5705_PLUS and > TG3_FLG2_5750_PLUS flags. > > Signed-off-by: John W. Linville Applied. From davem@davemloft.net Thu Apr 21 17:06:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:06:54 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M06pdD031601 for ; Thu, 21 Apr 2005 17:06:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlaO-0003dO-00; Thu, 21 Apr 2005 16:59:56 -0700 Date: Thu, 21 Apr 2005 16:59:56 -0700 From: "David S. Miller" To: "John W. Linville" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc2 3/10] tg3: add bcm5752 entry to pci_ids.h Message-Id: <20050421165956.55bdcb14.davem@davemloft.net> In-Reply-To: <04132005193844.8474@laptop> References: <04132005193844.8410@laptop> <04132005193844.8474@laptop> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 411 Lines: 12 On Wed, 13 Apr 2005 19:38:44 -0400 "John W. Linville" wrote: > Add proper entry for bcm5752 PCI ID to pci_ids.h, and use it in tg3. > > Signed-off-by: John W. Linville > --- > I did this separately in case patches like this (i.e. new PCI IDs) > need to come from more "official" sources. Applied, thanks. Don't we need a drivers/pci/pci.ids update as well? From kaber@trash.net Thu Apr 21 17:10:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:10:48 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0AjdD001698 for ; Thu, 21 Apr 2005 17:10:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOlkJ-0002b6-Bt; Fri, 22 Apr 2005 02:10:11 +0200 Message-ID: <426840E3.8000203@trash.net> Date: Fri, 22 Apr 2005 02:10:11 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> <426832E1.7020003@trash.net> <20050422092221.4950e23c@localhost.localdomain> <426839B4.2090502@trash.net> <1114128336.10572.12.camel@localhost.localdomain> In-Reply-To: <1114128336.10572.12.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 379 Lines: 11 jamal wrote: > Duplication of packets would be trivial to do with mirred mirror option > attached to the qdisc. The problem with duplication and queueing to the device is that the packet needs to take the same classification-path as the original packet to end up in the same leaf-queue. This can only be guaranteed by restricting which classifiers can be used. Regards Patrick From kaber@trash.net Thu Apr 21 17:14:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:14:16 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0EDdD003615 for ; Thu, 21 Apr 2005 17:14:14 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DOlnb-0002bd-Ex; Fri, 22 Apr 2005 02:13:36 +0200 Message-ID: <426841AF.2060404@trash.net> Date: Fri, 22 Apr 2005 02:13:35 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: jamal , Wolfgang Walter , netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> <1114127419.10572.4.camel@localhost.localdomain> <20050421235802.GB10451@gondor.apana.org.au> In-Reply-To: <20050421235802.GB10451@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 585 Lines: 16 Herbert Xu wrote: > On Thu, Apr 21, 2005 at 07:50:19PM -0400, jamal wrote: > >>What was the reason there exist a FWD direction in the policies? > > You should really ask Alexey about that :) I myself had the same > question when I first started in this area. However, since it > has been present since the very beginning and people are already > relying on it, we will have to live with it. I guess it was for performance reasons. A router that only needs IPsec for management doesn't need to perform policy checks for forwarded packets, which makes sense too me. Regards Patrick From davem@davemloft.net Thu Apr 21 17:11:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:11:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0BpdE002181 for ; Thu, 21 Apr 2005 17:11:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOleK-0003fd-00; Thu, 21 Apr 2005 17:04:00 -0700 Date: Thu, 21 Apr 2005 17:04:00 -0700 From: "David S. Miller" To: "John W. Linville" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc2 9/10] tg3: check TG3_FLG2_5750_PLUS flag to set TG3_FLG2_5705_PLUS flag Message-Id: <20050421170400.6a6fd892.davem@davemloft.net> In-Reply-To: <04132005193846.8835@laptop> References: <04132005193845.8775@laptop> <04132005193846.8835@laptop> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 249 Lines: 9 On Wed, 13 Apr 2005 19:38:46 -0400 "John W. Linville" wrote: > Use check of TG3_FLG2_5750_PLUS in tg3_get_invariants to set > TG3_FLG2_5705_PLUS flag. > > Signed-off-by: John W. Linville Applied. From davem@davemloft.net Thu Apr 21 17:11:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:11:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0BpdD002181 for ; Thu, 21 Apr 2005 17:11:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlfF-0003fq-00; Thu, 21 Apr 2005 17:04:57 -0700 Date: Thu, 21 Apr 2005 17:04:57 -0700 From: "David S. Miller" To: "John W. Linville" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.12-rc2 10/10] tg3: add support for bcm5752 rev a1 Message-Id: <20050421170457.3e49665c.davem@davemloft.net> In-Reply-To: <04132005193846.8893@laptop> References: <04132005193846.8835@laptop> <04132005193846.8893@laptop> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 396 Lines: 10 On Wed, 13 Apr 2005 19:38:46 -0400 "John W. Linville" wrote: > Replace existing ASIC_REV_5752 definition with ASIC_REV_5752_A0, > and add definition for ASIC_REV_5752_A1. Then, add ASIC_REV_5752_A1 > to check for setting TG3_FLG2_5750_PLUS in tg3_get_invariants. > > Signed-off-by: John W. Linville Applied, now off to Michael's additions :-) From hadi@cyberus.ca Thu Apr 21 17:18:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:18:27 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0IOdD005214 for ; Thu, 21 Apr 2005 17:18:25 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DOlsL-0002k8-2u for netdev@oss.sgi.com; Thu, 21 Apr 2005 20:18:29 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOlsF-00088L-Hz; Thu, 21 Apr 2005 20:18:23 -0400 Subject: Re: Problem with IPSEC tunnel mode From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Wolfgang Walter , netdev@oss.sgi.com In-Reply-To: <20050421235802.GB10451@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> <1114127419.10572.4.camel@localhost.localdomain> <20050421235802.GB10451@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Thu, 21 Apr 2005 20:18:19 -0400 Message-Id: <1114129099.10572.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 245 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: 1591 Lines: 37 On Fri, 2005-22-04 at 09:58 +1000, Herbert Xu wrote: > On Thu, Apr 21, 2005 at 07:50:19PM -0400, jamal wrote: > > What was the reason there exist a FWD direction in the policies? > > You should really ask Alexey about that :) I myself had the same > question when I first started in this area. However, since it > has been present since the very beginning and people are already > relying on it, we will have to live with it. > I am sure if Alexey did it theres a good reason - I am not sure i get it. CCing mr Kuznet. > > Also - shouldnt the FWD policies closely match the OUT ones instead of > > the IN direction (browsing the forwarding code)? i.e > > does this look odd to you (picking a sample from Wolfgangs output): > > The FWD policies are analogous to the FORWARD table in netfilter. > The FWD policies apply to forwarded packet, meaning packets that > end up in ip_forward instead of ip_local_deliver. The IN policies > only apply to packets that end up in ip_local_deliver. > Heres what confused me when i browsed: looking at ip_forward() - it does a xfrm4_policy_check(NULL, XFRM_POLICY_FWD, skb) - this leads to a flow cache creation based on FWD direction. Later on in the path (still in ip_forward) xfrm4_route_forward() gets invoked which does a flow_cache build again based on XFRM_POLICY_OUT. So i was wondering whether they OUT shouldnt be just a duplicate of FWD (instead FWD seems to be the dup of IN). Look at that sample i posted - all his policies look like that. What gives? Why are the IN and FWD exactly the same? bug in racoon/setkey? cheers, jamal From davem@davemloft.net Thu Apr 21 17:22:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:22:32 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0MTdD005924 for ; Thu, 21 Apr 2005 17:22:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOlpV-0003jx-00; Thu, 21 Apr 2005 17:15:33 -0700 Date: Thu, 21 Apr 2005 17:15:33 -0700 From: "David S. Miller" To: "Michael Chan" Cc: linville@tuxdriver.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc2 0/11] tg3: Add complete support for 5752 Message-Id: <20050421171533.6296be09.davem@davemloft.net> In-Reply-To: <1113806551.6504.11.camel@rh4> References: <04132005193843.8300@laptop> <1113806551.6504.11.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 709 Lines: 17 On Sun, 17 Apr 2005 23:42:31 -0700 "Michael Chan" wrote: > These patches should be applied on top of John Linville's patches posted > a few days ago. > > The last 2 patches are MSI patches for 5751 C0 and 5752. They are very > similar to the MSI patches posted a few weeks ago. I've modified the MSI > test patch to display a warning message to ask the user to report the > failure if the MSI test fails. If Jeff still objects to this, then just > skip patch 11 but apply patch 10 which enables MSI on the latest chips. I decided to apply everything, even the MSI test stuff, it seems perfectly reasonable to me. I'll work on backporting all of this 5752 stuff to 2.4.x later today. From hadi@cyberus.ca Thu Apr 21 17:32:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:32:24 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0WLdD007619 for ; Thu, 21 Apr 2005 17:32:22 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DOm5j-0003EM-AQ for netdev@oss.sgi.com; Thu, 21 Apr 2005 18:32:19 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOm5n-0001Xq-HA; Thu, 21 Apr 2005 20:32:23 -0400 Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <426840E3.8000203@trash.net> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> <426832E1.7020003@trash.net> <20050422092221.4950e23c@localhost.localdomain> <426839B4.2090502@trash.net> <1114128336.10572.12.camel@localhost.localdomain> <426840E3.8000203@trash.net> Content-Type: text/plain Organization: unknown Date: Thu, 21 Apr 2005 20:32:19 -0400 Message-Id: <1114129939.10572.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 248 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: 659 Lines: 17 On Fri, 2005-22-04 at 02:10 +0200, Patrick McHardy wrote: > jamal wrote: > > Duplication of packets would be trivial to do with mirred mirror option > > attached to the qdisc. > > The problem with duplication and queueing to the device is that > the packet needs to take the same classification-path as the > original packet to end up in the same leaf-queue. This can only > be guaranteed by restricting which classifiers can be used. What i described happens before the queueing. So packets should end up in the same leaf queue because the same classifier rule is used to select the dup action. I should actually try to make sure it works; cheers, jamal From wolfgang.walter@studentenwerk.mhn.de Thu Apr 21 17:40:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:40:36 -0700 (PDT) Received: from email.studentenwerk.mhn.de (mailin.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0eXdD008436 for ; Thu, 21 Apr 2005 17:40:34 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 20F7858002; Fri, 22 Apr 2005 02:40:32 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 1B19E54002; Fri, 22 Apr 2005 02:40:32 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: Herbert Xu Subject: Re: Problem with IPSEC tunnel mode Date: Fri, 22 Apr 2005 02:40:31 +0200 User-Agent: KMail/1.7.2 References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> In-Reply-To: <20050421214618.GA29991@gondor.apana.org.au> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200504220240.31280.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3M0eXdD008436 X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 1326 Lines: 43 Am Donnerstag, 21. April 2005 23:46 schrieben Sie: > On Thu, Apr 21, 2005 at 04:40:16PM +0200, Wolfgang Walter wrote: > > 10.148.0.0/23 dev eth2.1001 scope link src 10.148.0.1 > > 10.148.32.0/20 via 10.148.15.30 dev eth0.1014 src 10.148.15.29 > > default via 192.168.77.162 dev eth3 src 192.168.77.161 > > Although you probably have rp_filter turned, but please check > > cat /proc/sys/net/ipv4/conf/eth3/rp_filter > > anway. > > > src 10.148.0.0/23 dst 10.0.25.210/32 > > dir fwd priority 0 > > There you go. This policy trumps your other policy. This one > says that forwarded traffic matching it must carry no tunnel > IPsec transforms. Therefore all IPsec packets matching it will > be dropped. I don't understand that. 10.148.0.0/23 is 10.148.0.0-10.148.1.255, isn't it? But 10.148.4.0/28 (is 10.148.4.0-10.148.4.15) is not within it. > > > src 10.148.4.0/28 dst 10.0.25.210/32 > > dir fwd priority 2084 > > tmpl src 192.168.9.237 dst 192.168.77.161 > > proto esp spi 0x00000000 reqid 16465 mode tunnel > > The reason it worked with the old setkey and 2.6.7* is that all > forwarded traffic would've been allowed, regardless of whether > they matched the IPsec policy or not. > > Cheers, Greetings, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From hadi@cyberus.ca Thu Apr 21 17:40:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:40:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0eMdD008413 for ; Thu, 21 Apr 2005 17:40:22 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DOmDa-0002RT-HG for netdev@oss.sgi.com; Thu, 21 Apr 2005 20:40:26 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOmDX-0002TY-PB; Thu, 21 Apr 2005 20:40:24 -0400 Subject: Re: [PATCH] netem: account for packets in delayed queue in qlen From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <1114129939.10572.29.camel@localhost.localdomain> References: <20050329152110.38d50653@dxpl.pdx.osdl.net> <4252EB9D.9070305@trash.net> <20050407120417.4297cd14@dxpl.pdx.osdl.net> <42628300.9010007@trash.net> <20050419110639.47767113@localhost.localdomain> <42666098.5060409@trash.net> <20050421132020.41858bc4@localhost.localdomain> <426832E1.7020003@trash.net> <20050422092221.4950e23c@localhost.localdomain> <426839B4.2090502@trash.net> <1114128336.10572.12.camel@localhost.localdomain> <426840E3.8000203@trash.net> <1114129939.10572.29.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Thu, 21 Apr 2005 20:40:18 -0400 Message-Id: <1114130419.10572.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 249 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: 233 Lines: 11 On Thu, 2005-21-04 at 20:32 -0400, jamal wrote: > I should actually try to make sure it works; > Never mind - it wont work at the moment ;-> A missing feature described at the top should get it to work though ;-> cheers, jamal From baruch@ev-en.org Thu Apr 21 17:48:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:48:16 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0mCdD009959 for ; Thu, 21 Apr 2005 17:48:13 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id EA34511A5D1; Fri, 22 Apr 2005 03:48:11 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 63B1011A5CE; Fri, 22 Apr 2005 03:48:07 +0300 (IDT) Message-ID: <426849C2.7000409@ev-en.org> Date: Fri, 22 Apr 2005 01:48:02 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: "David S.Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, Douglas Leith Subject: Re: [RFC INTRO 0/5] H-TCP congestion control References: <20050311160734.30424.67955.65942@galon.ev-en.org> <20050311094239.4c59c29d@dxpl.pdx.osdl.net> In-Reply-To: <20050311094239.4c59c29d@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1611 Lines: 42 Stephen Hemminger wrote: > On Fri, 11 Mar 2005 18:07:34 +0200 (IST) > Baruch Even wrote: > > >>The following patches are the result of the work of Douglas Leith to implement >>the H-TCP congestion control proposal. They have since been modified by me >>(Baruch Even) to port them to kernel 2.6.x, test them and tune them. >> >>All patches are against Linux kernel version 2.6.11-bk6. This is currently >>a preliminary work and is presented for review in order to receive comments to >>improve this work so it can be accepted to mainline Linux Kernel. >> >>The initial development was to add H-TCP to the Linux kernel for testing >>purposes, it became evident that on 1 Gbit/s links Linux is unable to process >>the received ack stream fast enough to handle the load. We have patches for >>that but they proved too hard to be ported to 2.6.11+, we are currently working >>on them. >> >>Baruch > > > Are there any IPR encumberance to this like FAST TCP. Earlier versions of > this patch said: > > >>This patch is covered by a pending patent, a license is being worked on to >>enable the inclusion in Linux. Comments and suggestions on this are also >>solicited. > > > Has this changed? This has changed now. The code is now released under the GNU GPL v2, according to what I was told this effectively implies that any patent right that the university will have regarding this technology is effectively licensed for use with this code. Please let me know if there is anything else that we need to do to let the review and possible inclusion of our contribution to proceed. Baruch From herbert@gondor.apana.org.au Thu Apr 21 17:58:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 17:58:18 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M0w8dD010839 for ; Thu, 21 Apr 2005 17:58:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOmRY-0003vU-00; Fri, 22 Apr 2005 10:54:52 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOmRU-0002p4-00; Fri, 22 Apr 2005 10:54:48 +1000 Date: Fri, 22 Apr 2005 10:54:48 +1000 To: jamal Cc: Wolfgang Walter , netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050422005448.GA10819@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> <1114127419.10572.4.camel@localhost.localdomain> <20050421235802.GB10451@gondor.apana.org.au> <1114129099.10572.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114129099.10572.24.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 682 Lines: 18 On Thu, Apr 21, 2005 at 08:18:19PM -0400, jamal wrote: > > So i was wondering whether they OUT shouldnt be just a duplicate of > FWD (instead FWD seems to be the dup of IN). Look at that sample i > posted - all his policies look like that. What gives? Why are the IN and > FWD exactly the same? bug in racoon/setkey? FWD checks inbound IPsec policies while OUT determines the outbound IPsec policies. The IN direction is not used at all for forwarded packets. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Apr 21 18:04:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 18:04:57 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M14pdD011713 for ; Thu, 21 Apr 2005 18:04:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOmb8-0003xe-00; Fri, 22 Apr 2005 11:04:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOmb7-0002qM-00; Fri, 22 Apr 2005 11:04:45 +1000 Date: Fri, 22 Apr 2005 11:04:45 +1000 To: Wolfgang Walter Cc: netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050422010445.GA10918@gondor.apana.org.au> References: <200504211640.16742.wolfgang.walter@studentenwerk.mhn.de> <20050421214618.GA29991@gondor.apana.org.au> <200504220240.31280.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504220240.31280.wolfgang.walter@studentenwerk.mhn.de> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1066 Lines: 35 On Fri, Apr 22, 2005 at 02:40:31AM +0200, Wolfgang Walter wrote: > > > Although you probably have rp_filter turned, but please check > > > > cat /proc/sys/net/ipv4/conf/eth3/rp_filter > > > > anway. Please do this check. > > > src 10.148.0.0/23 dst 10.0.25.210/32 > > > dir fwd priority 0 > > > > There you go. This policy trumps your other policy. This one > > says that forwarded traffic matching it must carry no tunnel > > IPsec transforms. Therefore all IPsec packets matching it will > > be dropped. > > I don't understand that. 10.148.0.0/23 is 10.148.0.0-10.148.1.255, isn't it? > But 10.148.4.0/28 (is 10.148.4.0-10.148.4.15) is not within it. Sorry, I misread the netmask. I was right about the problem though :) Further down it says src 0.0.0.0/0 dst 10.0.25.210/32 dir fwd priority 0 which still trumps your IPsec policy. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From proski@gnu.org Thu Apr 21 19:23:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 19:23:34 -0700 (PDT) Received: from localhost.localdomain (h-64-105-159-118.phlapafg.covad.net [64.105.159.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M2NRdD015730 for ; Thu, 21 Apr 2005 19:23:30 -0700 Received: by localhost.localdomain (Postfix, from userid 500) id 39EE1EFF72; Thu, 21 Apr 2005 22:23:23 -0400 (EDT) Subject: [PATCH] Mailing lists, homepage for orinoco driver From: Pavel Roskin To: David Gibson , netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Apr 2005 22:23:23 -0400 Message-Id: <1114136603.18091.5.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: proski@gnu.org Precedence: bulk X-list: netdev Content-Length: 554 Lines: 26 Hello! Please add mailing list addresses for Orinoco and update its homepage. Signed-off-by: Pavel Roskin MAINTAINERS: 4333b69e56bdefdbc30858e0d4ccaf887d9b2ae0 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1699,7 +1699,9 @@ P: Pavel Roskin M: proski@gnu.org P: David Gibson M: hermes@gibson.dropbear.id.au -W: http://www.ozlabs.org/people/dgibson/dldwd +L: orinoco-users@lists.sourceforge.net +L: orinoco-devel@lists.sourceforge.net +W: http://www.nongnu.org/orinoco/ S: Maintained PARALLEL PORT SUPPORT -- Regards, Pavel Roskin From jamie@shareable.org Thu Apr 21 20:15:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 20:15:35 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M3FUdD018288 for ; Thu, 21 Apr 2005 20:15:31 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j3M3FEmf013970; Fri, 22 Apr 2005 04:15:14 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j3M3FBHM013968; Fri, 22 Apr 2005 04:15:11 +0100 Date: Fri, 22 Apr 2005 04:15:10 +0100 From: Jamie Lokier To: Baruch Even Cc: Stephen Hemminger , "David S.Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, Douglas Leith Subject: Re: [RFC INTRO 0/5] H-TCP congestion control Message-ID: <20050422031510.GA13508@mail.shareable.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> <20050311094239.4c59c29d@dxpl.pdx.osdl.net> <426849C2.7000409@ev-en.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426849C2.7000409@ev-en.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 1874 Lines: 41 Baruch Even wrote: > >>This patch is covered by a pending patent, a license is being worked on to > >>enable the inclusion in Linux. Comments and suggestions on this are also > >>solicited. > > > > > >Has this changed? > > This has changed now. The code is now released under the GNU GPL v2, > according to what I was told this effectively implies that any patent > right that the university will have regarding this technology is > effectively licensed for use with this code. > > Please let me know if there is anything else that we need to do to let > the review and possible inclusion of our contribution to proceed. The patents must be licensed for _all_ GPL v2 implementations of that algorithm, not just in this specific code. (And it would be friendlier if you granted a patent license for GPL v2 and later). That's because it's necessary for derivative works to have the patent license too, and derivative works includes taking the code and totally rewriting it for a different operating system or a different application. Otherwise, section 7 of the GPL kicks in, and although you the authors could distribute the code, nobody could _redistribute_ it because they couldn't satisfy the requirements of section 7. Also, just because you, the authors, are distributing the code under GPLv2, that doesn't automatically grant a patent license (unless that's the university's policy). The GPL does _not_ state that you grant patent licenses by distributing the program. Rather, it _forbids_ redistributing the code if a patent license does not permit royalty-free distribution by all those who receive copies directly or indirectly, and that's the situation in the absence of a patent license being granted. You, as the authors, are exempt simply by being the copyright holders and therefore not bound by the GPL terms applying to your own code. -- Jamie From davem@davemloft.net Thu Apr 21 20:20:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 20:21:00 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M3KvdD022422 for ; Thu, 21 Apr 2005 20:20:57 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DOobj-0004yL-00; Thu, 21 Apr 2005 20:13:31 -0700 Date: Thu, 21 Apr 2005 20:13:31 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPSEC]: Kill nested read lock by deleting xfrm_init_tempsel Message-Id: <20050421201331.349f214b.davem@davemloft.net> In-Reply-To: <42683D07.6090808@trash.net> References: <20050328233917.GB15369@gondor.apana.org.au> <424B40C2.90304@trash.net> <20050331004658.GA26395@gondor.apana.org.au> <20050331212325.5e996432.davem@davemloft.net> <20050402004956.GA24339@gondor.apana.org.au> <20050401172007.7296eced.davem@davemloft.net> <20050402020947.GA24998@gondor.apana.org.au> <42501E51.3000401@trash.net> <20050405103918.GA24863@gondor.apana.org.au> <4252EEA2.5020107@trash.net> <20050406022155.GA12952@gondor.apana.org.au> <20050421163526.7a29a76f.davem@davemloft.net> <42683D07.6090808@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 503 Lines: 12 On Fri, 22 Apr 2005 01:53:43 +0200 Patrick McHardy wrote: > Yes, tmpl->id.daddr might be 0, in which case the destination > of the packet or previous tunnel mode transforms is used. daddr > always contains the correct adress, so we should use it to check > for duplicate SPIs. But as Herbert noted, we shouldn't perform > the check if tmpl->id.spi == 0, so here is a new patch. > > Signed-off-by: Patrick McHardy Ok, that makes sense. Patch applied, thanks guys. From dgibson@ozlabs.org Thu Apr 21 20:57:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 20:57:47 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M3vfdD024720 for ; Thu, 21 Apr 2005 20:57:43 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id C174E67AC6; Fri, 22 Apr 2005 13:57:39 +1000 (EST) Date: Fri, 22 Apr 2005 13:57:31 +1000 From: David Gibson To: Pavel Roskin Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Mailing lists, homepage for orinoco driver Message-ID: <20050422035731.GA10141@localhost.localdomain> References: <1114136603.18091.5.camel@dv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114136603.18091.5.camel@dv> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 448 Lines: 14 On Thu, Apr 21, 2005 at 10:23:23PM -0400, Pavel Roskin wrote: > Hello! > > Please add mailing list addresses for Orinoco and update its homepage. > > Signed-off-by: Pavel Roskin Acked-by: David Gibson -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson From lark@linux.net.cn Thu Apr 21 21:11:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 21:11:58 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M4BodD026282 for ; Thu, 21 Apr 2005 21:11:51 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id A79573F9CA; Fri, 22 Apr 2005 12:11:49 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 31178-03-4; Fri, 22 Apr 2005 12:11:45 +0800 (CST) Received: from [192.168.0.120] (unknown [61.49.99.205]) by mx.linux.net.cn (Postfix) with ESMTP id CCC5C3F9C7; Fri, 22 Apr 2005 12:11:44 +0800 (CST) Date: Fri, 22 Apr 2005 12:11:44 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Cc: jamal , netdev In-Reply-To: <20050418184029.GV4114@postel.suug.ch> References: <20050419012147.038F.LARK@linux.net.cn> <20050418184029.GV4114@postel.suug.ch> Message-Id: <20050422115230.03E0.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 3013 Lines: 88 Hi Thomas Graf, Due to some reason, I was removed from this list and I wait for sometime to make sure this. On Mon, 18 Apr 2005 20:40:29 +0200, Thomas Graf wrote: > * Wang Jian <20050419012147.038F.LARK@linux.net.cn> 2005-04-19 02:01 > > In your big piture, > > > > 1. the dynamic allocated classids prepresent streams (I avoid using flow > > here ntentionally) > > 2. the dynamic created TBFs are mapped 1:1 to classids, to provide rate > > control > > > > Let's simplify it to > > > > 1. namespace represent streams > > 2. rate controls for every name in the namespace (1:1 map) > > This is only true for use 1 where the allocator creates indepdendent > qdiscs. Look at use case 2 where a major classid of 11: and 12: create > htb class siblings, this even allows to divided one big flow > namespaces into various group but still respecting global policies. > Yes, the use case 2 you refer to is not in my original design. > > I understand all of your arguments but I would like to, if possible, > avoid to add yet another quite specific qdisc which could have been > implemented in a generic way for everyone to use. Your FRG basically > does what the alloctor + classifier + action + qdiscs can do but it > is orientied at one specific use case. Agree. I will maintain my code out of kernel tree, in case someone feels my frg is usefull for his/her special case. > > Let's analyze your enqueue() > > 1) perflow_is_valid() // BTW, I think you have a typo in there, 2 times TCP ;-> > Should be done in the classifier with ematches: > ... ematch meta(PROTOCOL eq IP) AND > (cmp(ip_proto eq TCP) OR cmp(ip_proto eq UDP) ..) > > 2) perflow_(fill|find|new)_tuple() > Should be done in the classifier as an action > > 3) qsch->q.qlen >= q->qlen > Must be done in the qdisc after classification so this would > go into the allocator. > > 4) flow->timer > Must be handled by the alloctor > > 5) rate limiting > IMHO: Should be done in separate qdiscs > > Advantages? > - What happens if you want to allow yet another protocol > in your flow? You have to change sources etc. > - Protocol specific flow hashing? No problem, replace the action. > - ... > > The only disadvantage I can see is a possible performance bottleneck > but this must be proved first by numbers. The other disadvantage is that the dynamic classid used is not predicted by user space, it is very tricky for user space to handle the classid allocation then (I mean for the management system like web management). That is what I try to avoid so far. > > So basically the direction we want to go is to strict separate the > classification from the queueing to allow the user to customize > everything by replacing small components. It might be worth to read > up on the discussion on "ematch" and "action" over the last 3 months. > I agree to this. But I must iterate one thing: the design should be friendly to user space management for a heavy usage. -- lark From 64vn@cardvn.net Thu Apr 21 21:11:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 21:11:17 -0700 (PDT) Received: from isp-go.FPT.NET (isp-go.fpt.net [210.245.0.153]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M4BAdD025988 for ; Thu, 21 Apr 2005 21:11:11 -0700 Received: from isp-mta2.fpt.vn ([210.245.0.151]) by isp-go.FPT.NET with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Apr 2005 11:11:09 +0700 Received: from [203.210.148.126] by isp-mta2.fpt.vn [210.245.0.151] Message-ID: <4268795B.6010801@cardvn.net> Date: Fri, 22 Apr 2005 11:11:07 +0700 From: Nguyen Dinh Nam <64vn@cardvn.net> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: manage netdev subscription Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2005 04:11:09.0789 (UTC) FILETIME=[504810D0:01C546F1] X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: 64vn@cardvn.net Precedence: bulk X-list: netdev Content-Length: 84 Lines: 2 Please help pointing me to the place to manage subscription to netdev mailing list From rddunlap@osdl.org Thu Apr 21 21:48:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 21:48:13 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M4m9dD029216 for ; Thu, 21 Apr 2005 21:48:09 -0700 Received: from midway.verizon.net (wbar2.sea1-4-5-049-023.sea1.dsl-verizon.net [4.5.49.23]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3M4m4s3001266 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Apr 2005 21:48:05 -0700 Date: Thu, 21 Apr 2005 21:47:59 -0700 From: "Randy.Dunlap" To: Nguyen Dinh Nam <64vn@cardvn.net> Cc: netdev@oss.sgi.com Subject: Re: manage netdev subscription Message-Id: <20050421214759.5490d316.rddunlap@osdl.org> In-Reply-To: <4268795B.6010801@cardvn.net> References: <4268795B.6010801@cardvn.net> Organization: OSDL X-Mailer: Sylpheed version 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 188 Lines: 9 On Fri, 22 Apr 2005 11:11:07 +0700 Nguyen Dinh Nam wrote: | Please help pointing me to the place to manage subscription to netdev | mailing list http://oss.sgi.com/ecartis/ --- ~Randy From lark@linux.net.cn Thu Apr 21 22:11:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Apr 2005 22:11:39 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M5BVdD031022 for ; Thu, 21 Apr 2005 22:11:36 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 71B5F3F9CC for ; Fri, 22 Apr 2005 13:11:25 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 09335-03-5 for ; Fri, 22 Apr 2005 13:11:21 +0800 (CST) Received: from [192.168.0.120] (unknown [61.49.99.205]) by mx.linux.net.cn (Postfix) with ESMTP id 408C53F9A6 for ; Fri, 22 Apr 2005 13:11:21 +0800 (CST) Date: Fri, 22 Apr 2005 13:11:21 +0800 From: Wang Jian To: netdev@oss.sgi.com Subject: Re: manage netdev subscription In-Reply-To: <20050421214759.5490d316.rddunlap@osdl.org> References: <4268795B.6010801@cardvn.net> <20050421214759.5490d316.rddunlap@osdl.org> Message-Id: <20050422130823.03E3.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 420 Lines: 20 IMHO, there should be a link in http://oss.sgi.com/ and http://oss.sgi.com/archives/ to mailling list management page. On Thu, 21 Apr 2005 21:47:59 -0700, "Randy.Dunlap" wrote: > On Fri, 22 Apr 2005 11:11:07 +0700 Nguyen Dinh Nam wrote: > > | Please help pointing me to the place to manage subscription to netdev > | mailing list > > http://oss.sgi.com/ecartis/ > > --- > ~Randy -- lark From wolfgang.walter@studentenwerk.mhn.de Fri Apr 22 02:37:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 02:37:57 -0700 (PDT) Received: from email.studentenwerk.mhn.de (mailin.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3M9bidD019809 for ; Fri, 22 Apr 2005 02:37:46 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 0612558002; Fri, 22 Apr 2005 11:37:43 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id F091454002; Fri, 22 Apr 2005 11:37:42 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: Herbert Xu Subject: Re: Problem with IPSEC tunnel mode Date: Fri, 22 Apr 2005 11:37:38 +0200 User-Agent: KMail/1.7.2 References: <200504220240.31280.wolfgang.walter@studentenwerk.mhn.de> <20050422010445.GA10918@gondor.apana.org.au> In-Reply-To: <20050422010445.GA10918@gondor.apana.org.au> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200504221137.38939.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3M9bidD019809 X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 1714 Lines: 53 Am Freitag, 22. April 2005 03:04 schrieben Sie: > On Fri, Apr 22, 2005 at 02:40:31AM +0200, Wolfgang Walter wrote: > > > Although you probably have rp_filter turned, but please check > > > > > > cat /proc/sys/net/ipv4/conf/eth3/rp_filter > > > > > > anway. > > Please do this check. > > > > > src 10.148.0.0/23 dst 10.0.25.210/32 > > > > dir fwd priority 0 > > > > > > There you go. This policy trumps your other policy. This one > > > says that forwarded traffic matching it must carry no tunnel > > > IPsec transforms. Therefore all IPsec packets matching it will > > > be dropped. > > > > I don't understand that. 10.148.0.0/23 is 10.148.0.0-10.148.1.255, isn't > > it? But 10.148.4.0/28 (is 10.148.4.0-10.148.4.15) is not within it. > > Sorry, I misread the netmask. I was right about the problem though :) > Further down it says > > src 0.0.0.0/0 dst 10.0.25.210/32 > dir fwd priority 0 > > which still trumps your IPsec policy. > > Cheers, Oh yes, me stupid. They are needed (these hosts are allowed to communicate with outside world unencrypted), but priority is wrong. Our rules are generated from a description of the network. And if we connect 10.0.25.210 directly to C and change netmask to 30 instead of 32 our generator assumes that this system is not allowed to communicate with outside world and does not generate this rule. Thanks a lot, sorry for bothering you. I should have seen this difference. But probably I would not have recognized that as a problemebecause I assumed that in and fwd allow-rules only applies to non-ipsec packets which of course is not logical :-). -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From cranium2003@yahoo.com Fri Apr 22 03:37:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 03:37:55 -0700 (PDT) Received: from web41403.mail.yahoo.com (web41403.mail.yahoo.com [66.218.93.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3MAbndD023881 for ; Fri, 22 Apr 2005 03:37:50 -0700 Received: (qmail 43326 invoked by uid 60001); 22 Apr 2005 10:37:49 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=nBedNVhlUW6gT0LoounblTkOi6hsqYS4iCcIH5orUhM54+gcgC7hdnNhpJq/oEjZTMNv4JFEW3U+cPCK4yqIshav7kyckB5vfn+qcu2FQCXsHBDosOXV6zkmC2ePWoI0J8gfUKwnViJEicACtVn0DS5ZPlJZdfPETXGY2qZeUb8= ; Message-ID: <20050422103749.43324.qmail@web41403.mail.yahoo.com> Received: from [203.199.141.99] by web41403.mail.yahoo.com via HTTP; Fri, 22 Apr 2005 03:37:48 PDT Date: Fri, 22 Apr 2005 03:37:48 -0700 (PDT) From: cranium2003 Subject: Help getting Neighbour table overflow a lot messages To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2451 Lines: 83 hello, I want to know what happed to my system RedHat linux 9. I brought kernel in tar.gz format from other pc rebuild it and recompile it after that i am getting following messages. I have configured 2.4.20, 2.4.30,2.6.11 kernels and the kernel after which it happened is 2.4.20. NET: 3809 messages suppressed. Neighbour table overflow. NET: 2663 messages suppressed. Neighbour table overflow. NET: 10553 messages suppressed. Neighbour table overflow. NET: 11910 messages suppressed. Neighbour table overflow. NET: 11324 messages suppressed. Neighbour table overflow. NET: 11294 messages suppressed. Neighbour table overflow. NET: 1778 messages suppressed. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. Neighbour table overflow. NET: 33 messages suppressed. Neighbour table overflow. Please help. My ifconfig is eth0 Link encap:Ethernet HWaddr 00:08:A1:43:61:F5 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:43 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:2580 (2.5 Kb) Interrupt:9 Base address:0x7c00 eth1 Link encap:Ethernet HWaddr 00:80:48:C3:11:94 inet addr:10.1.1.30 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1739765 errors:0 dropped:0 overruns:0 frame:1 TX packets:270 errors:0 dropped:0 overruns:0 carrier:0 collisions:60 txqueuelen:100 RX bytes:109742910 (104.6 Mb) TX bytes:24318 (23.7 Kb) Interrupt:11 Base address:0xdc00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1344 (1.3 Kb) TX bytes:1344 (1.3 Kb) Thanks, cranium. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tgraf@suug.ch Fri Apr 22 04:10:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:10:56 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBAfdD026187 for ; Fri, 22 Apr 2005 04:10:42 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 18C351C0EB; Fri, 22 Apr 2005 13:11:01 +0200 (CEST) Date: Fri, 22 Apr 2005 13:11:00 +0200 From: Thomas Graf To: Wang Jian Cc: jamal , netdev Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Message-ID: <20050422111100.GN577@postel.suug.ch> References: <20050419012147.038F.LARK@linux.net.cn> <20050418184029.GV4114@postel.suug.ch> <20050422115230.03E0.LARK@linux.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050422115230.03E0.LARK@linux.net.cn> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1537 Lines: 32 > > I understand all of your arguments but I would like to, if possible, > > avoid to add yet another quite specific qdisc which could have been > > implemented in a generic way for everyone to use. Your FRG basically > > does what the alloctor + classifier + action + qdiscs can do but it > > is orientied at one specific use case. > > Agree. I will maintain my code out of kernel tree, in case someone feels > my frg is usefull for his/her special case. Definitely, I think your work is very valuable and if the generic approach doesn't work out I'll be all for including your work. Well, maybe move the flow id generation into an action but leave the class allocation in frg. > The other disadvantage is that the dynamic classid used is not predicted > by user space, it is very tricky for user space to handle the classid > allocation then (I mean for the management system like web management). > That is what I try to avoid so far. Good point, we can make the handle of the allocated classes/qdiscs be derived from the flow id we get and additionaly broadcast any change in the qdisc/class management to userspace for it to keep track. Let me develop some more thoughts on this and get back to you. > I agree to this. But I must iterate one thing: the design should be > friendly to user space management for a heavy usage. Agreed. I had another look at your code and noticed the GFP_KERNEL masked kmalloc call in perflow_new_flow() called from perflow_enqueue(), you must change that to GFP_ATOMIC due to softirq context. From matti.aarnio@zmailer.org Fri Apr 22 04:33:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:33:50 -0700 (PDT) Received: from mail.zmailer.org (van-1-67.lab.dnainternet.fi [62.78.96.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBXadD032082 for ; Fri, 22 Apr 2005 04:33:38 -0700 Received: (mea@mea-ext) by mail.zmailer.org id S1610387AbVDVLdE (ORCPT ); Fri, 22 Apr 2005 14:33:04 +0300 Date: Fri, 22 Apr 2005 14:32:59 +0300 From: Matti Aarnio To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: kernel BUG at net/ipv6/exthdrs_core.c:80! Message-ID: <20050422113259.GX3858@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matti.aarnio@zmailer.org Precedence: bulk X-list: netdev Content-Length: 3170 Lines: 63 Kernel is FC4 development series: 2.6.11-1.1191_FC4smp #1 SMP Sun Mar 20 19:48:24 EST 2005 i686 i686 i386 GNU/Linux and it reports following. This isn't the first time it has done that either. /Matti Aarnio kernel BUG at net/ipv6/exthdrs_core.c:80! invalid operand: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: parport_pc lp parport w83627hf eeprom i2c_sensor i2c_isa ip_conntrack_ftp ipt_conntrack iptable_mangle ipt_state ip_conntrack ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables md5 ipv6 dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd ehci_hcd hw_random i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e100 mii sk98lin dummy floppy ext3 jbd raid1 sata_sil ata_piix libata aic7xxx sd_mod scsi_mod CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00010282 (2.6.11-1.1191_FC4smp) EIP is at ipv6_skip_exthdr+0xb0/0x15f eax: fffffff2 ebx: 0000002c ecx: f4ba0abe edx: c5c3ef48 esi: 000000d8 edi: 00000000 ebp: 000000da esp: f4ba0ab0 ds: 007b es: 007b ss: 0068 Process named (pid: 2498, threadinfo=f4ba0000 task=f4ba3ad0) Stack: 00000002 f4ba0b17 c5c3ef48 80000000 c5c3ef48 00000028 f4ba0b58 00000000 c01bd46e 00000038 c9081080 001733f8 00000001 c2017c60 c2017c60 00000001 854830d2 f4ba3ad0 00000096 f4ba0afc f4ba0afc c0404488 00000001 f4ba0b2c Call Trace: [] selinux_parse_skb_ipv6+0x8a/0x14a [] selinux_parse_skb+0x61/0x8b [] selinux_ip_postroute_last+0xc9/0x222 [] selinux_ipv6_postroute_last+0x20/0x25 [] ip6_output_finish+0x0/0xf0 [ipv6] [] nf_iterate+0x60/0x84 [] ip6_output_finish+0x0/0xf0 [ipv6] [] nf_hook_slow+0x4d/0xed [] ip6_output_finish+0x0/0xf0 [ipv6] [] ip6_output2+0x71/0x2bb [ipv6] [] ip6_output_finish+0x0/0xf0 [ipv6] [] dst_output+0x0/0x1f [ipv6] [] ip6_push_pending_frames+0x28f/0x42c [ipv6] [] dst_output+0x0/0x1f [ipv6] [] ip_generic_getfrag+0x0/0x94 [] udp_v6_push_pending_frames+0x124/0x1ac [ipv6] [] udpv6_sendmsg+0x738/0x943 [ipv6] [] skb_dequeue+0x4c/0x52 [] udpv6_recvmsg+0x9e/0x365 [ipv6] [] inet_sendmsg+0x2e/0x4c [] sock_sendmsg+0xe4/0xff [] poison_obj+0x20/0x3d [] dbg_redzone1+0x11/0x22 [] cache_alloc_debugcheck_after+0x35/0x16b [] autoremove_wake_function+0x0/0x37 [] kmem_cache_alloc+0x59/0x85 [] avc_alloc_node+0x16/0x168 [] avc_alloc_node+0x16/0x168 [] copy_from_user+0x42/0x80 [] sys_sendmsg+0x11e/0x213 [] try_to_wake_up+0x6e/0x2b1 [] current_fs_time+0x5a/0x75 [] inode_update_time+0x2d/0xa2 [] pipe_writev+0x432/0x4fd [] sys_socketcall+0x24f/0x271 [] syscall_call+0x7/0xb Code: 90 c7 04 24 02 00 00 00 8d 4c 24 0e 89 f2 8b 44 24 08 e8 c4 2e fa ff 31 ff 85 c0 78 0e 8d 7c 24 0e 89 f8 85 c0 0f 85 78 ff ff ff <0f> 0b 50 00 e6 93 34 c0 80 fb 2c 0f 85 70 ff ff ff 8b 54 24 08 From ak@muc.de Fri Apr 22 04:36:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:37:06 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBawdD032713 for ; Fri, 22 Apr 2005 04:36:59 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 22879D033E; Fri, 22 Apr 2005 13:36:56 +0200 (CEST) To: Greg Banks Cc: Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> From: Andi Kleen Date: Fri, 22 Apr 2005 13:36:56 +0200 In-Reply-To: <20050419055535.GA12211@sgi.com> (Greg Banks's message of "Tue, 19 Apr 2005 15:55:35 +1000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 268 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: 673 Lines: 18 Greg Banks writes: > > An inordinate amount of CPU is being spent running around polling the > device instead of dealing with the packets in IP, TCP and NFS land. > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix > box with slower CPUs. We have seen similar behaviour. With NAPI some benchmarks run a lot slower than on a driver on the same hardware/NIC without NAPI. This can be even observed with simple tests like netperf single stream between two boxes. There seems to be also some problems with bidirectional traffic, although I have not fully tracked them down to NAPI yet. There is definitely some problem in NAPI land ... -Andi From wolfgang.walter@studentenwerk.mhn.de Fri Apr 22 04:42:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:42:19 -0700 (PDT) Received: from email.studentenwerk.mhn.de (dresden.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBgDdD001377 for ; Fri, 22 Apr 2005 04:42:13 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 7766358002; Fri, 22 Apr 2005 13:42:11 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 7263354002; Fri, 22 Apr 2005 13:42:11 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: hadi@cyberus.ca Subject: Re: Problem with IPSEC tunnel mode Date: Fri, 22 Apr 2005 13:42:10 +0200 User-Agent: KMail/1.7.2 Cc: Herbert Xu , netdev@oss.sgi.com References: <20050421235802.GB10451@gondor.apana.org.au> <1114129099.10572.24.camel@localhost.localdomain> In-Reply-To: <1114129099.10572.24.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3MBgDdD001377 X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 2625 Lines: 62 Am Freitag, 22. April 2005 02:18 schrieb jamal: > On Fri, 2005-22-04 at 09:58 +1000, Herbert Xu wrote: > > On Thu, Apr 21, 2005 at 07:50:19PM -0400, jamal wrote: > > > What was the reason there exist a FWD direction in the policies? > > > > You should really ask Alexey about that :) I myself had the same > > question when I first started in this area. However, since it > > has been present since the very beginning and people are already > > relying on it, we will have to live with it. > > I am sure if Alexey did it theres a good reason - I am not sure i get > it. CCing mr Kuznet. > > > > Also - shouldnt the FWD policies closely match the OUT ones instead of > > > the IN direction (browsing the forwarding code)? i.e > > > does this look odd to you (picking a sample from Wolfgangs output): > > > > The FWD policies are analogous to the FORWARD table in netfilter. > > The FWD policies apply to forwarded packet, meaning packets that > > end up in ip_forward instead of ip_local_deliver. The IN policies > > only apply to packets that end up in ip_local_deliver. > > Heres what confused me when i browsed: > looking at ip_forward() - it does a xfrm4_policy_check(NULL, > XFRM_POLICY_FWD, skb) - this leads to a flow cache creation based on > FWD direction. Later on in the path (still in ip_forward) > xfrm4_route_forward() gets invoked which does a flow_cache build again > based on XFRM_POLICY_OUT. > So i was wondering whether they OUT shouldnt be just a duplicate of > FWD (instead FWD seems to be the dup of IN). Look at that sample i > posted - all his policies look like that. What gives? Why are the IN and > FWD exactly the same? bug in racoon/setkey? > > cheers, > jamal No. XFRM_POLICY_IN is only checked for incoming packets which are delivered locally. XFRM_POLICY_FWD is checked for incoming packets which are routed. That our XFRM_POLICY_IN matches XFRM_POLICY_FWD is more for convenience: if a subnet is connected directly to a router we want to treat the interface address of the router itself the same way. Instead of constructing special rules which exactly match the interface address we simply use the same rule as for forwarding. XFRM_POLICY_OUT ist checked for every outgoing packet, be it locally generated be it routed (which is different from netfilter). This asymmetry is a little bit inconsequent. Probably one should really have XFRM_POLICY_FWD_IN and XFRM_POLICY_FWD_OUT. But XFRM_POLICY_OUT would mainly be a copy of XFRM_POLICY_FWD_OUT then, I think. Greetings, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From ak@muc.de Fri Apr 22 04:39:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:39:59 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBdkdD001070 for ; Fri, 22 Apr 2005 04:39:47 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 28670D033F; Fri, 22 Apr 2005 13:39:46 +0200 (CEST) To: Rick Jones Cc: Neil Horman , jamal , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Must every packet have a creating socket? References: <20050420172944.69275.qmail@web51501.mail.yahoo.com> <4266FFC4.6020305@hp.com> From: Andi Kleen Date: Fri, 22 Apr 2005 13:39:46 +0200 In-Reply-To: <4266FFC4.6020305@hp.com> (Rick Jones's message of "Wed, 20 Apr 2005 18:20:04 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 269 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: 616 Lines: 16 Rick Jones writes: >> Can I think that every packet (e.g. IP packet) must >> have a corresponding creating socket? (i.e. Must every >> packet be created by a socket?) > > No. ICMP messages come to mind - although I _suppose_ that since > those are in response to other traffic, you could claim it was in > response to something sent from a "socket" or "endpoint" - depends on > how far away you consider it to still be from a socket. Actually Linux has kernel private sockets for ICMP. Very old Linux didnt, but it required ugly special cases in the transmit path, so it was removed. -Andi From yoshfuji@linux-ipv6.org Fri Apr 22 04:43:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:43:58 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBhidD001798 for ; Fri, 22 Apr 2005 04:43:45 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CDA9533D10; Fri, 22 Apr 2005 20:46:10 +0900 (JST) Date: Fri, 22 Apr 2005 20:46:10 +0900 (JST) Message-Id: <20050422.204610.96031992.yoshfuji@linux-ipv6.org> To: matti.aarnio@zmailer.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: kernel BUG at net/ipv6/exthdrs_core.c:80! From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050422113259.GX3858@mea-ext.zmailer.org> References: <20050422113259.GX3858@mea-ext.zmailer.org> 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-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 271 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: 1846 Lines: 34 In article <20050422113259.GX3858@mea-ext.zmailer.org> (at Fri, 22 Apr 2005 14:32:59 +0300), Matti Aarnio says: > kernel BUG at net/ipv6/exthdrs_core.c:80! > invalid operand: 0000 [#1] > SMP DEBUG_PAGEALLOC > Modules linked in: parport_pc lp parport w83627hf eeprom i2c_sensor i2c_isa ip_conntrack_ftp ipt_conntrack iptable_mangle ipt_state ip_conntrack ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables md5 ipv6 dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd ehci_hcd hw_random i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e100 mii sk98lin dummy floppy ext3 jbd raid1 sata_sil ata_piix libata aic7xxx sd_mod scsi_mod > CPU: 1 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010282 (2.6.11-1.1191_FC4smp) > EIP is at ipv6_skip_exthdr+0xb0/0x15f > eax: fffffff2 ebx: 0000002c ecx: f4ba0abe edx: c5c3ef48 > esi: 000000d8 edi: 00000000 ebp: 000000da esp: f4ba0ab0 > ds: 007b es: 007b ss: 0068 > Process named (pid: 2498, threadinfo=f4ba0000 task=f4ba3ad0) > Stack: 00000002 f4ba0b17 c5c3ef48 80000000 c5c3ef48 00000028 f4ba0b58 00000000 > c01bd46e 00000038 c9081080 001733f8 00000001 c2017c60 c2017c60 00000001 > 854830d2 f4ba3ad0 00000096 f4ba0afc f4ba0afc c0404488 00000001 f4ba0b2c > Call Trace: > [] selinux_parse_skb_ipv6+0x8a/0x14a > [] selinux_parse_skb+0x61/0x8b > [] selinux_ip_postroute_last+0xc9/0x222 > [] selinux_ipv6_postroute_last+0x20/0x25 > [] ip6_output_finish+0x0/0xf0 [ipv6] : I assume that BUG was raised because of skb_header_pointer()'s failure; which means, skb_copy_bits()'s failure. Strange to me. Do you know what caused this? How about disabling selinux / ip6tables? Thanks. --yoshfuji From baruch@ev-en.org Fri Apr 22 04:58:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 04:58:22 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MBwIdD003544 for ; Fri, 22 Apr 2005 04:58:18 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id E521411A5D1; Fri, 22 Apr 2005 14:58:14 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 092E311A5CF; Fri, 22 Apr 2005 14:58:06 +0300 (IDT) Message-ID: <4268E6CC.6060703@ev-en.org> Date: Fri, 22 Apr 2005 12:58:04 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Cc: Stephen Hemminger , "David S.Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, Douglas Leith Subject: Re: [RFC INTRO 0/5] H-TCP congestion control References: <20050311160734.30424.67955.65942@galon.ev-en.org> <20050311094239.4c59c29d@dxpl.pdx.osdl.net> <426849C2.7000409@ev-en.org> <20050422031510.GA13508@mail.shareable.org> In-Reply-To: <20050422031510.GA13508@mail.shareable.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1616 Lines: 44 Jamie Lokier wrote: > Baruch Even wrote: > >>>>This patch is covered by a pending patent, a license is being worked on to >>>>enable the inclusion in Linux. Comments and suggestions on this are also >>>>solicited. >>> >>> >>>Has this changed? >> >>This has changed now. The code is now released under the GNU GPL v2, >>according to what I was told this effectively implies that any patent >>right that the university will have regarding this technology is >>effectively licensed for use with this code. >> >>Please let me know if there is anything else that we need to do to let >>the review and possible inclusion of our contribution to proceed. > > > The patents must be licensed for _all_ GPL v2 implementations of that > algorithm, not just in this specific code. (And it would be > friendlier if you granted a patent license for GPL v2 and later). > > That's because it's necessary for derivative works to have the patent > license too, and derivative works includes taking the code and totally > rewriting it for a different operating system or a different > application. > > [snipped] We are trying to get this sorted in the proper way, even as authors the issue here is also of dealing with the university bureaucracy so we'd prefer to avoid that and the associated paperwork as much as possible. Is more paperwork/licenses really necessary? What is it that we need to provide for this contribution to be acceptable for the kernel? Specifics please. David, Can you comment on this and say if what was provided so far is sufficient to be accepted and if not what is needed? Thanks, Baruch From lark@linux.net.cn Fri Apr 22 05:04:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 05:04:53 -0700 (PDT) Received: from mx.linux.net.cn ([211.100.11.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MC4kdD004361 for ; Fri, 22 Apr 2005 05:04:47 -0700 Received: from localhost (master.linux.net.cn [127.0.0.1]) by mx.linux.net.cn (Postfix) with ESMTP id 260BD3F9D6; Fri, 22 Apr 2005 20:04:43 +0800 (CST) Received: from mx.linux.net.cn ([127.0.0.1]) by localhost (master.linux.net.cn [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 25893-03-6; Fri, 22 Apr 2005 20:04:39 +0800 (CST) Received: from [192.168.0.120] (unknown [61.49.99.205]) by mx.linux.net.cn (Postfix) with ESMTP id 0741D3F9AF; Fri, 22 Apr 2005 20:04:39 +0800 (CST) Date: Fri, 22 Apr 2005 20:04:38 +0800 From: Wang Jian To: Thomas Graf Subject: Re: [RFC] QoS: frg queue (was [RFC] QoS: new per flow queue) Cc: jamal , netdev In-Reply-To: <20050422111100.GN577@postel.suug.ch> References: <20050422115230.03E0.LARK@linux.net.cn> <20050422111100.GN577@postel.suug.ch> Message-Id: <20050422200327.03E6.LARK@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [CN] X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at linux.net.cn X-Virus-Status: Clean X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lark@linux.net.cn Precedence: bulk X-list: netdev Content-Length: 366 Lines: 16 Hi Thomas Graf, On Fri, 22 Apr 2005 13:11:00 +0200, Thomas Graf wrote: > > I had another look at your code and noticed the GFP_KERNEL masked > kmalloc call in perflow_new_flow() called from perflow_enqueue(), > you must change that to GFP_ATOMIC due to softirq context. Acked. I will prepare another patch and put it online later. -- lark From hadi@cyberus.ca Fri Apr 22 05:14:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 05:14:52 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MCEmdD005613 for ; Fri, 22 Apr 2005 05:14:49 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DOx3Z-0008PT-Uw for netdev@oss.sgi.com; Fri, 22 Apr 2005 08:14:49 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOx3V-0003o9-Vg; Fri, 22 Apr 2005 08:14:46 -0400 Subject: Re: Problem with IPSEC tunnel mode From: jamal Reply-To: hadi@cyberus.ca To: Wolfgang Walter Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> References: <20050421235802.GB10451@gondor.apana.org.au> <1114129099.10572.24.camel@localhost.localdomain> <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> Content-Type: multipart/mixed; boundary="=-M5oQ++3HCrAQcioPTK1S" Organization: unknown Date: Fri, 22 Apr 2005 08:14:44 -0400 Message-Id: <1114172084.7679.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 274 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: 3252 Lines: 106 --=-M5oQ++3HCrAQcioPTK1S Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-22-04 at 13:42 +0200, Wolfgang Walter wrote: > Am Freitag, 22. April 2005 02:18 schrieb jamal: [..] > > So i was wondering whether they OUT shouldnt be just a duplicate of > > FWD (instead FWD seems to be the dup of IN). Look at that sample i > > posted - all his policies look like that. What gives? Why are the IN and > > FWD exactly the same? bug in racoon/setkey? > No. XFRM_POLICY_IN is only checked for incoming packets which are delivered > locally. > For encrypted packets > XFRM_POLICY_FWD is checked for incoming packets which are routed. > For non-encrypted packets to be forwarded. > That our XFRM_POLICY_IN matches XFRM_POLICY_FWD is more for convenience: if a > subnet is connected directly to a router we want to treat the interface > address of the router itself the same way. Instead of constructing special > rules which exactly match the interface address we simply use the same rule > as for forwarding. > Ok, so it was design intent then. > XFRM_POLICY_OUT ist checked for every outgoing packet, be it locally generated > be it routed (which is different from netfilter). > > This asymmetry is a little bit inconsequent. Probably one should really have > XFRM_POLICY_FWD_IN and XFRM_POLICY_FWD_OUT. But XFRM_POLICY_OUT would mainly > be a copy of XFRM_POLICY_FWD_OUT then, I think. > I did notice racoon or even setkey (version 0.5) for some rules (need to investigate) would install two policy rules when i installed only one i.e racoon will install one in OUT and other in FWD direction. Example script and setkey -DP output attached. In this case i install two rules, but for one of them an extra rule is installed. Actually the pattern is quiet repeatable as you add more rules. This may also be what is happening to you maybe? cheers, jamal --=-M5oQ++3HCrAQcioPTK1S Content-Disposition: attachment; filename=sample.conf Content-Type: text/plain; name=sample.conf; charset=utf-8 Content-Transfer-Encoding: 7bit #!/usr/sbin/setkey -f # Flush the SAD and SPD flush; spdflush; spdadd 192.168.3.10 192.168.2.100 any -P out ipsec esp/transport//require ah/transport//require; spdadd 192.168.2.100 192.168.3.10 any -P in ipsec esp/transport//require ah/transport//require; --=-M5oQ++3HCrAQcioPTK1S Content-Disposition: attachment; filename=setkey_output Content-Type: text/plain; name=setkey_output; charset=utf-8 Content-Transfer-Encoding: 7bit 192.168.2.100[any] 192.168.3.10[any] any in ipsec esp/transport//require ah/transport//require created: Apr 22 08:06:28 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=8 seq=2 pid=8236 refcnt=1 192.168.3.10[any] 192.168.2.100[any] any out ipsec esp/transport//require ah/transport//require created: Apr 22 08:06:28 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=1 seq=1 pid=8236 refcnt=1 192.168.2.100[any] 192.168.3.10[any] any fwd ipsec esp/transport//require ah/transport//require created: Apr 22 08:06:28 2005 lastused: lifetime: 0(s) validtime: 0(s) spid=18 seq=0 pid=8236 refcnt=1 --=-M5oQ++3HCrAQcioPTK1S-- From hadi@cyberus.ca Fri Apr 22 05:33:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 05:33:31 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MCXIdD007323 for ; Fri, 22 Apr 2005 05:33:19 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DOxLU-0001xl-5K for netdev@oss.sgi.com; Fri, 22 Apr 2005 08:33:20 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DOxLR-0006sq-Cs; Fri, 22 Apr 2005 08:33:17 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com In-Reply-To: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 08:33:15 -0400 Message-Id: <1114173195.7679.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 275 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: 2049 Lines: 53 On Fri, 2005-22-04 at 13:36 +0200, Andi Kleen wrote: > Greg Banks writes: > > > > An inordinate amount of CPU is being spent running around polling the > > device instead of dealing with the packets in IP, TCP and NFS land. > > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix > > box with slower CPUs. > > We have seen similar behaviour. With NAPI some benchmarks run > a lot slower than on a driver on the same hardware/NIC without NAPI. They should not run slower - but they may consume more CPU. > This can be even observed with simple tests like netperf single stream > between two boxes. > Yes, slow traffic coming into the system would chew more CPU if you have a fast CPU ;-> You should know this Andi, but let me explain the reason for about the 100th time: If your CPU is fast enough such that the interupt only causes 1-2 packets to be processed before reenabling, then you will have anywhere between 1-2 extra IO calls (recall dis/reenabling interupts) - this will be noticed in the CPU % chewed. It shouldnt be really a lot of CPU. If you use non-NAPI then you dont have the extra IO happening and therefore you will see less CPU used at those rates. OTOH, Try more than 1 netperfs and it becomes beneficial to have NAPI around. Yes, for low rates - this will make some of those benchmarks look bad. But for such cases you can use mitigation in addition to NAPi - except your latency in the benchmark will now look bad ;-> > There seems to be also some problems with bidirectional traffic, although > I have not fully tracked them down to NAPI yet. > doubt it has to do with NAPI. > There is definitely some problem in NAPI land ... > this is a design choice - a solution could be created to "fix" this but hasnt happened because there has not been a good reason to complicate things. The people who are bitching about this are benchmarkers who want to win at both high and low rates and they are not happy because while they can win at high rates, they cant at low rates. cheers, jamal From wolfgang.walter@studentenwerk.mhn.de Fri Apr 22 06:22:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 06:23:08 -0700 (PDT) Received: from email.studentenwerk.mhn.de (dresden.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MDMsdD010147 for ; Fri, 22 Apr 2005 06:22:55 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 5CABD58002; Fri, 22 Apr 2005 15:22:50 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 5064B54002; Fri, 22 Apr 2005 15:22:50 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: hadi@cyberus.ca Subject: Re: Problem with IPSEC tunnel mode Date: Fri, 22 Apr 2005 15:22:49 +0200 User-Agent: KMail/1.7.2 Cc: Herbert Xu , netdev@oss.sgi.com References: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> <1114172084.7679.15.camel@localhost.localdomain> In-Reply-To: <1114172084.7679.15.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3MDMsdD010147 X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 4322 Lines: 105 Am Freitag, 22. April 2005 14:14 schrieb jamal: > On Fri, 2005-22-04 at 13:42 +0200, Wolfgang Walter wrote: > > Am Freitag, 22. April 2005 02:18 schrieb jamal: > > [..] > > > > So i was wondering whether they OUT shouldnt be just a duplicate of > > > FWD (instead FWD seems to be the dup of IN). Look at that sample i > > > posted - all his policies look like that. What gives? Why are the IN > > > and FWD exactly the same? bug in racoon/setkey? > > > > No. XFRM_POLICY_IN is only checked for incoming packets which are > > delivered locally. > > For encrypted packets I think for all packets otherwise it would not make sense to have allow and block rules. I'm not sure how packets of tunnels ending at a host are treated exactly. Probably the tunnel-packet itself is checked against XFRM_POLICY_IN because its destination is the host itself. Then it gets decrypted if an entry appropriate in the sad in (dst,spi) exists. The inner packet gets extracted and decrypted and is then rerouted. I think it is like that because * you see those packets twice in PREROUTING (mangle) i.e. for an esp-tunnel: first as esp-packet than the inner decrypted packet. If the inner packet is to be routed, XFRM_POLICY_FWD is relevant, otherwise XFRM_POLICY_IN. But maybe XFRM_POLICY_IN is bypassed for ipsec-packets. I didn't try out transport-mode. > > > XFRM_POLICY_FWD is checked for incoming packets which are routed. > > For non-encrypted packets to be forwarded. Again: for all packets. Packets to be routed which are still encrypted here are ipsec-packets which are not destinated or originating from this host. Of course they may came in via a tunnel ending at this host: a<--->N1<--->b<----ipsec-tunnel--->c<--->N2<--->d If a communicates with d via esp (tunnel or transportmode) and b and c tunnel all packets between network N1 and N2 via ipsec then, on c, a ipsec packet from a to d would come in via the tunnel packed into another ipsec packet, is extracted from the tunnel packet and is routed to d if XFRM_POLICY_FWD allows esp packets from a to d and XFRM_POLICY_OUT allows unencrypted communication between c and d for esp-packets from a to d. > > > That our XFRM_POLICY_IN matches XFRM_POLICY_FWD is more for convenience: > > if a subnet is connected directly to a router we want to treat the > > interface address of the router itself the same way. Instead of > > constructing special rules which exactly match the interface address we > > simply use the same rule as for forwarding. > > Ok, so it was design intent then. > > > XFRM_POLICY_OUT ist checked for every outgoing packet, be it locally > > generated be it routed (which is different from netfilter). > > > > This asymmetry is a little bit inconsequent. Probably one should really > > have XFRM_POLICY_FWD_IN and XFRM_POLICY_FWD_OUT. But XFRM_POLICY_OUT > > would mainly be a copy of XFRM_POLICY_FWD_OUT then, I think. > > I did notice racoon or even setkey (version 0.5) for some rules (need to > investigate) would install two policy rules when i installed only one i.e > racoon will install one in OUT and other in FWD direction. > > Example script and setkey -DP output attached. In this case i install > two rules, but for one of them an extra rule is installed. Actually the > pattern is quiet repeatable as you add more rules. This may also be what > is happening to you maybe? spdadd 192.168.2.100 192.168.3.10 any -P in ipsec esp/transport//require ah/transport//require; installs both in and fwd rules (in RFC-mode). Use option -k for only setting in rules (RFC only knows IN and OUT rules). This behaviour was added to ipsec-tools. As far as I know earlier kernels had a bug and didn't check fwd ruleset so that setkey and racoon worked by accident under linux. racoon now behaves like pluto: it inserts always in and fwd rules. Its easier than to check if a in or fwd rule or both is needed. And no, we do not use setkey any more but ip xfrm (though setkey displays more information, i.e. it tells you if a policy is socket-specific). Reason is that neither setkey nor racoon can handle large rule sets. And for most fwd rules we also set an in rule (as pluto does). Greetings -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From herbert@gondor.apana.org.au Fri Apr 22 06:31:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 06:31:54 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MDVedD011134 for ; Fri, 22 Apr 2005 06:31:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOyCa-0007ha-00; Fri, 22 Apr 2005 23:28:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOyCM-0005vf-00; Fri, 22 Apr 2005 23:27:58 +1000 Date: Fri, 22 Apr 2005 23:27:58 +1000 To: Wolfgang Walter Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050422132758.GA22772@gondor.apana.org.au> References: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> <1114172084.7679.15.camel@localhost.localdomain> <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 792 Lines: 18 On Fri, Apr 22, 2005 at 03:22:49PM +0200, Wolfgang Walter wrote: > > I'm not sure how packets of tunnels ending at a host are treated exactly. > Probably the tunnel-packet itself is checked against XFRM_POLICY_IN because > its destination is the host itself. Then it gets decrypted if an entry > appropriate in the sad in (dst,spi) exists. The inner packet gets extracted > and decrypted and is then rerouted. Actually it only gets checked once, after all IPsec decapsulation has been completed. So forwarded packets only ever get checked against the FWD direction. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From wolfgang.walter@studentenwerk.mhn.de Fri Apr 22 06:48:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 06:49:06 -0700 (PDT) Received: from email.studentenwerk.mhn.de (mailin.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MDmrdD013255 for ; Fri, 22 Apr 2005 06:48:54 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 0C86858002; Fri, 22 Apr 2005 15:48:53 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 04F1F54002; Fri, 22 Apr 2005 15:48:53 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: Herbert Xu Subject: Re: Problem with IPSEC tunnel mode Date: Fri, 22 Apr 2005 15:48:43 +0200 User-Agent: KMail/1.7.2 Cc: hadi@cyberus.ca, netdev@oss.sgi.com References: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <20050422132758.GA22772@gondor.apana.org.au> In-Reply-To: <20050422132758.GA22772@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200504221548.44560.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3MDmrdD013255 X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 1123 Lines: 27 Am Freitag, 22. April 2005 15:27 schrieb Herbert Xu: > On Fri, Apr 22, 2005 at 03:22:49PM +0200, Wolfgang Walter wrote: > > I'm not sure how packets of tunnels ending at a host are treated exactly. > > Probably the tunnel-packet itself is checked against XFRM_POLICY_IN > > because its destination is the host itself. Then it gets decrypted if an > > entry appropriate in the sad in (dst,spi) exists. The inner packet gets > > extracted and decrypted and is then rerouted. > > Actually it only gets checked once, after all IPsec decapsulation has been > completed. So forwarded packets only ever get checked against the FWD > direction. > So linux implements things like i.e. ipcomp in esp-tunnel in ah-tunnel as bundle instead of feeding it for every transformation into the packet receive code again? I assume that incoming packets which are subject to several ipsec-transformations are exactly seen twice in netfilter PREROUTING: first before decapsulation and then after complete decapsulation? Greetings, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From herbert@gondor.apana.org.au Fri Apr 22 06:53:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 06:53:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MDrgdD014704 for ; Fri, 22 Apr 2005 06:53:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOyav-0007ti-00; Fri, 22 Apr 2005 23:53:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOyah-0000hK-00; Fri, 22 Apr 2005 23:53:07 +1000 Date: Fri, 22 Apr 2005 23:53:07 +1000 To: Wolfgang Walter Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-ID: <20050422135307.GA2667@gondor.apana.org.au> References: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <20050422132758.GA22772@gondor.apana.org.au> <200504221548.44560.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504221548.44560.wolfgang.walter@studentenwerk.mhn.de> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 859 Lines: 18 On Fri, Apr 22, 2005 at 03:48:43PM +0200, Wolfgang Walter wrote: > > So linux implements things like i.e. ipcomp in esp-tunnel in ah-tunnel as > bundle instead of feeding it for every transformation into the packet receive > code again? I assume that incoming packets which are subject to several > ipsec-transformations are exactly seen twice in netfilter PREROUTING: first > before decapsulation and then after complete decapsulation? The packet is fed into each transform as you would expect. However, the policy check is done only once at the very end (unless raw sockets are involved in which case it can occur multiple times). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Apr 22 06:59:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 07:00:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MDxsdD015649 for ; Fri, 22 Apr 2005 06:59:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOyg8-0007xU-00; Fri, 22 Apr 2005 23:58:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOyg4-0000iB-00; Fri, 22 Apr 2005 23:58:40 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: kernel BUG at net/ipv6/exthdrs_core.c:80! Cc: matti.aarnio@zmailer.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, davem@davemloft.net Organization: Core In-Reply-To: <20050422.204610.96031992.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.net,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 22 Apr 2005 23:58:40 +1000 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1163 Lines: 34 YOSHIFUJI Hideaki / ???? wrote: > > I assume that BUG was raised because of skb_header_pointer()'s failure; > which means, skb_copy_bits()'s failure. Strange to me. > > Do you know what caused this? > How about disabling selinux / ip6tables? Indeed, it's a bug in selinux. The length should be skb->tail - skb->data, and not skb->tail - skb->head. In fact, we could be vulgar and write it as skb->len :) Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== security/selinux/hooks.c 1.95 vs edited ===== --- 1.95/security/selinux/hooks.c 2005-04-02 07:30:16 +10:00 +++ edited/security/selinux/hooks.c 2005-04-22 23:55:19 +10:00 @@ -2853,8 +2853,7 @@ nexthdr = ip6->nexthdr; offset += sizeof(_ipv6h); - offset = ipv6_skip_exthdr(skb, offset, &nexthdr, - skb->tail - skb->head - offset); + offset = ipv6_skip_exthdr(skb, offset, &nexthdr, skb->len - offset); if (offset < 0) goto out; From herbert@gondor.apana.org.au Fri Apr 22 07:20:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 07:20:54 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MEKbdD017571 for ; Fri, 22 Apr 2005 07:20:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DOz0b-00082q-00; Sat, 23 Apr 2005 00:19:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DOz0Y-0000y4-00; Sat, 23 Apr 2005 00:19:50 +1000 Date: Sat, 23 Apr 2005 00:19:50 +1000 To: YOSHIFUJI Hideaki / ???? Cc: matti.aarnio@zmailer.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: kernel BUG at net/ipv6/exthdrs_core.c:80! Message-ID: <20050422141950.GA2791@gondor.apana.org.au> References: <20050422.204610.96031992.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4106 Lines: 129 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 22, 2005 at 11:58:40PM +1000, Herbert Xu wrote: > > Indeed, it's a bug in selinux. The length should be skb->tail - skb->data, > and not skb->tail - skb->head. In fact, we could be vulgar and write it as > skb->len :) I was just reading ipv6_skip_exthdr and it occured to me that we can get rid of len altogether. The only place where len is used is to check whether the skb has two bytes for ipv6_opt_hdr. This check is done by skb_header_pointer/skb_copy_bits anyway. Now it might appear that we've made the code slower by deferring the check to skb_copy_bits. However, this check should not trigger in the common case so this is OK. Signed-off-by: Herbert Xu This patch supercedes the previous one. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/ipv6.h 1.44 vs edited ===== --- 1.44/include/net/ipv6.h 2005-03-03 16:12:44 +11:00 +++ edited/include/net/ipv6.h 2005-04-23 00:13:21 +10:00 @@ -416,7 +416,7 @@ u8 *proto); extern int ipv6_skip_exthdr(const struct sk_buff *, int start, - u8 *nexthdrp, int len); + u8 *nexthdrp); extern int ipv6_ext_hdr(u8 nexthdr); ===== net/ipv6/exthdrs_core.c 1.2 vs edited ===== --- 1.2/net/ipv6/exthdrs_core.c 2004-08-19 10:14:54 +10:00 +++ edited/net/ipv6/exthdrs_core.c 2005-04-23 00:06:11 +10:00 @@ -41,8 +41,8 @@ * when Linux implements ESP (and maybe AUTH) headers. * --AK * - * This function parses (probably truncated) exthdr set "hdr" - * of length "len". "nexthdrp" initially points to some place, + * This function parses (probably truncated) exthdr set "hdr". + * "nexthdrp" initially points to some place, * where type of the first header can be found. * * It skips all well-known exthdrs, and returns pointer to the start @@ -63,7 +63,7 @@ * --ANK (980726) */ -int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp, int len) +int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp) { u8 nexthdr = *nexthdrp; @@ -71,13 +71,11 @@ struct ipv6_opt_hdr _hdr, *hp; int hdrlen; - if (len < (int)sizeof(struct ipv6_opt_hdr)) - return -1; if (nexthdr == NEXTHDR_NONE) return -1; hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr); if (hp == NULL) - BUG(); + return -1; if (nexthdr == NEXTHDR_FRAGMENT) { unsigned short _frag_off, *fp; fp = skb_header_pointer(skb, @@ -97,7 +95,6 @@ hdrlen = ipv6_optlen(hp); nexthdr = hp->nexthdr; - len -= hdrlen; start += hdrlen; } ===== net/ipv6/icmp.c 1.62 vs edited ===== --- 1.62/net/ipv6/icmp.c 2005-03-03 16:12:38 +11:00 +++ edited/net/ipv6/icmp.c 2005-04-23 00:19:13 +10:00 @@ -135,7 +135,7 @@ if (len < 0) return 1; - ptr = ipv6_skip_exthdr(skb, ptr, &nexthdr, len); + ptr = ipv6_skip_exthdr(skb, ptr, &nexthdr); if (ptr < 0) return 0; if (nexthdr == IPPROTO_ICMPV6) { @@ -514,7 +514,7 @@ nexthdr = ((struct ipv6hdr *)skb->data)->nexthdr; if (ipv6_ext_hdr(nexthdr)) { /* now skip over extension headers */ - inner_offset = ipv6_skip_exthdr(skb, sizeof(struct ipv6hdr), &nexthdr, skb->len - sizeof(struct ipv6hdr)); + inner_offset = ipv6_skip_exthdr(skb, sizeof(struct ipv6hdr), &nexthdr); if (inner_offset<0) return; } else { ===== security/selinux/hooks.c 1.95 vs edited ===== --- 1.95/security/selinux/hooks.c 2005-04-02 07:30:16 +10:00 +++ edited/security/selinux/hooks.c 2005-04-23 00:13:46 +10:00 @@ -2853,8 +2853,7 @@ nexthdr = ip6->nexthdr; offset += sizeof(_ipv6h); - offset = ipv6_skip_exthdr(skb, offset, &nexthdr, - skb->tail - skb->head - offset); + offset = ipv6_skip_exthdr(skb, offset, &nexthdr); if (offset < 0) goto out; --TB36FDmn/VVEgNH/-- From Robert.Olsson@data.slu.se Fri Apr 22 07:53:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 07:53:12 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MEqxdD020353 for ; Fri, 22 Apr 2005 07:53:01 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3MEqoXJ029730; Fri, 22 Apr 2005 16:52:50 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 46A19EE1E9; Fri, 22 Apr 2005 16:52:50 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.4034.250460.397016@robur.slu.se> Date: Fri, 22 Apr 2005 16:52:50 +0200 To: Andi Kleen Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 284 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: 1556 Lines: 36 Andi Kleen writes: > We have seen similar behaviour. With NAPI some benchmarks run > a lot slower than on a driver on the same hardware/NIC without NAPI. > This can be even observed with simple tests like netperf single stream > between two boxes. > > There seems to be also some problems with bidirectional traffic, although > I have not fully tracked them down to NAPI yet. > > There is definitely some problem in NAPI land ... Well NAPI enforces very little policy it leaves a lot of freedom for driver writers. Driver design i.e do work in interrupt or softirq, use of interrupt mitigation etc etc. It's minimal approach to solve some very severe problem we had with networking stack at a time were linux OS was not an option at all. Knowing also a bit about the background as we experimented quite a bit about possible options. Alexey did the final kernel design it got very well integrated into the kernel and softirq linux model. Dave understood directly and included the framework directly. So help us sort out the problems. And of course there are some differences or "issues" as we know every design has it's trade-off is bit Jamal said you can't optimize in both ends. Or help us replace it with something thats solves the same problems even better. Cheers. --ro BTW We talked with Intel folks about leaving irq disabled when reading ISR and some status bit were. This can save some PCI-accesses I don't if any experiments are done. MSI is also interesting in this aspect... From hadi@cyberus.ca Fri Apr 22 08:37:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 08:37:32 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MFbTdD027524 for ; Fri, 22 Apr 2005 08:37:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DP0Dg-0006Tx-3p for netdev@oss.sgi.com; Fri, 22 Apr 2005 09:37:28 -0600 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DP0Dg-00075r-7r; Fri, 22 Apr 2005 11:37:28 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Robert Olsson Cc: Andi Kleen , Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <17001.4034.250460.397016@robur.slu.se> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <17001.4034.250460.397016@robur.slu.se> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 11:37:25 -0400 Message-Id: <1114184245.7978.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 286 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: 563 Lines: 18 On Fri, 2005-22-04 at 16:52 +0200, Robert Olsson wrote: > > BTW We talked with Intel folks about leaving irq disabled when reading > ISR and some status bit were. You caught me just before i said this ;-> Now - if those intel folks listened they would be making a killing with their NICs on Linux. They have a paper at OLS to talk about how they get influenced by the Linux people on how to improve their hardware - so maybe they took the advice;-> Jesse? Note, this would entirely solve what Andi and the SGI people are talking about. cheers, jamal From cfriesen@nortel.com Fri Apr 22 08:48:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 08:48:36 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MFmNdD028925 for ; Fri, 22 Apr 2005 08:48:24 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3MFmL404239 for ; Fri, 22 Apr 2005 11:48:21 -0400 (EDT) Received: from nortel.com (acart285.ca.nortel.com [47.130.17.148]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLTPLD; Fri, 22 Apr 2005 11:48:21 -0400 Message-ID: <42691CC3.7000108@nortel.com> Date: Fri, 22 Apr 2005 09:48:19 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: 2.6.9 BUG in tcp_transmit_skb at net/ipv4/tcp_output.c Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: netdev Content-Length: 419 Lines: 14 I've got an error report for a problem with 2.6.9 networking. We seem to be intermittently hitting the above error after at least a couple hours or so of runtime, sometimes it takes up to 14 hrs or so, sometimes it doesn't happen. Network load is minimal. Anyone have any ideas on what this might be or how I can track it down? Has it been fixed in later releases? Thanks for any help you can give, Chris From cfriesen@nortel.com Fri Apr 22 08:56:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 08:57:01 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MFumdD029839 for ; Fri, 22 Apr 2005 08:56:49 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j3MFuXs28184 for ; Fri, 22 Apr 2005 11:56:34 -0400 (EDT) Received: from nortel.com (acart285.ca.nortel.com [47.130.17.148]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLTP37; Fri, 22 Apr 2005 11:56:46 -0400 Message-ID: <42691EBC.9040106@nortel.com> Date: Fri, 22 Apr 2005 09:56:44 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: 2.6.9 BUG in tcp_transmit_skb at net/ipv4/tcp_output.c -- full output References: <42691CC3.7000108@nortel.com> In-Reply-To: <42691CC3.7000108@nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 12:37:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: netdev Content-Length: 1797 Lines: 31 Here's the full output of the bug kernel BUG in tcp_transmit_skb at net/ipv4/tcp_output.c:277! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2 NIP: C00000000033D538 XER: 0000000000000000 LR: C00000000033CAEC REGS: c00000012d91f410 TRAP: 0700 Not tainted (2.6.9) MSR: 9000000000029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK: c00000016c8e6ae0[1211] 'peel' THREAD: c00000012d91c000 CPU: 0 GPR00: 0000000000000001 C00000012D91F6E0 C000000000623A60 FFFFFFFFFFFFFF97 GPR04: C000000123582980 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000001 C00000000FFC2900 GPR12: C000000123582980 C000000000492400 0000000000000001 000000001C0D9EE8 GPR16: 0000000000000000 0000000000000001 0000000000001015 0000000000009F5C GPR20: 0000000000000005 0000000000000005 000000000000008F C00000016CA9E3D8 GPR24: 0000000000000020 C0000001235829F0 C00000016CA9E180 C000000123582980 GPR28: C00000016CA9E180 0000000000000218 C000000000530650 C00000016CA9E488 NIP [c00000000033d538] .tcp_transmit_skb+0x7c/0xa44 LR [c00000000033caec] .tcp_rcv_state_process+0xdb4/0x13bc Call Trace: [c00000012d91f6e0] [0000000000000028] 0x28 (unreliable) [c00000012d91f800] [c00000000033caec] .tcp_rcv_state_process+0xdb4/0x13bc [c00000012d91f920] [c000000000347190] .tcp_v4_do_rcv+0x164/0x434 [c00000012d91f9f0] [c0000000002fee64] .__release_sock+0x78/0xc4 [c00000012d91fa90] [c0000000002fef38] .release_sock+0x88/0xdc [c00000012d91fb10] [c000000000359cb0] .inet_stream_connect+0x90/0x3ac [c00000012d91fc20] [c0000000002fc9c8] .sys_connect+0x94/0xc8 [c00000012d91fd40] [c000000000319710] .compat_sys_socketcall+0x134/0x2ac [c00000012d91fde0] [c000000000010434] syscall_exit+0x0/0x18 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 180 seconds.. From jmoyer@redhat.com Fri Apr 22 10:17:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 10:17:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MHHbdD003381 for ; Fri, 22 Apr 2005 10:17:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3MHHbJ4011849; Fri, 22 Apr 2005 13:17:37 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3MHHbO22359; Fri, 22 Apr 2005 13:17:37 -0400 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j3MHHa2t018188; Fri, 22 Apr 2005 13:17:36 -0400 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j3MHGMBS007761; Fri, 22 Apr 2005 13:16:22 -0400 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j3MHGME7007758; Fri, 22 Apr 2005 13:16:22 -0400 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.12645.981316.510106@segfault.boston.redhat.com> Date: Fri, 22 Apr 2005 13:16:21 -0400 To: mpm@selenic.com CC: netdev@oss.sgi.com Subject: napi poll and dev->weight X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 751 Lines: 20 Hi, Matt, I recently debugged an issue we had with netdump, where a NAPI poll would exhaust the network card's budget. In this case, the budget was never reset (since we are in a panicked state), and so the card's poll routine would always return immediately without doing any work. While other netpoll users may not have exactly the same problems, this could become an issue in the places where you call netpoll_poll in a loop (such as in find_skb and netpoll_send_skb). You might consider a check like the following in such cases: if (dev->quota <= 0) dev->quota += dev->weight; This will at least make it possible for the poll routine to make progress. If any of this is unclear, feel free to tell me so. I'll gladly elaborate. -Jeff From ak@muc.de Fri Apr 22 10:21:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 10:21:24 -0700 (PDT) Received: from colin2.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MHL9dD004043 for ; Fri, 22 Apr 2005 10:21:10 -0700 Received: (qmail 13776 invoked by uid 3709); 22 Apr 2005 17:21:08 -0000 Date: 22 Apr 2005 19:21:08 +0200 Date: Fri, 22 Apr 2005 19:21:08 +0200 From: Andi Kleen To: jamal Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050422172108.GA10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114173195.7679.30.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 290 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: 1844 Lines: 44 On Fri, Apr 22, 2005 at 08:33:15AM -0400, jamal wrote: > On Fri, 2005-22-04 at 13:36 +0200, Andi Kleen wrote: > > Greg Banks writes: > > > > > > An inordinate amount of CPU is being spent running around polling the > > > device instead of dealing with the packets in IP, TCP and NFS land. > > > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix > > > box with slower CPUs. > > > > We have seen similar behaviour. With NAPI some benchmarks run > > a lot slower than on a driver on the same hardware/NIC without NAPI. > > They should not run slower - but they may consume more CPU. They actually run slower. Now before David complains this was with old 2.6 kernels and I dont have time right now to rerun the benchmarks, but at least I dont think there was ever any patch addressing these issues. > > > This can be even observed with simple tests like netperf single stream > > between two boxes. > > > > Yes, slow traffic coming into the system would chew more CPU if you have > a fast CPU ;-> You should know this Andi, but let me explain the reason > for about the 100th time: No, the performance of the data transfer was actually slower. CPU time was not the problem, Opterons have enough of that ... > this is a design choice - a solution could be created to "fix" this but > hasnt happened because there has not been a good reason to complicate > things. The people who are bitching about this are benchmarkers who want > to win at both high and low rates and they are not happy because while > they can win at high rates, they cant at low rates. My impression is that NAPI seems to be more optimized for a rather obscure work load (routing), while it does not seem to be that great on the far more common server/client type workloads. If that was a design choice then it was a bad design. -Andi From ak@muc.de Fri Apr 22 10:22:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 10:22:23 -0700 (PDT) Received: from colin2.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MHMBdD004395 for ; Fri, 22 Apr 2005 10:22:12 -0700 Received: (qmail 14403 invoked by uid 3709); 22 Apr 2005 17:22:10 -0000 Date: 22 Apr 2005 19:22:10 +0200 Date: Fri, 22 Apr 2005 19:22:10 +0200 From: Andi Kleen To: jamal Cc: Robert Olsson , Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050422172210.GB10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <17001.4034.250460.397016@robur.slu.se> <1114184245.7978.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114184245.7978.5.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 291 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: 183 Lines: 7 > Note, this would entirely solve what Andi and the SGI people are talking > about. Perhaps, but Linux has to perform well on old hardware too. New silicon is not a solution. -Andi From rkmp@xs4all.nl Fri Apr 22 10:41:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 10:41:54 -0700 (PDT) Received: from wsprwl.xs4all.nl (wsp.xs4all.nl [80.126.33.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MHffdD006341 for ; Fri, 22 Apr 2005 10:41:42 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wsprwl.xs4all.nl (Postfix) with ESMTP id BA119879B1; Fri, 22 Apr 2005 19:41:39 +0200 (CEST) Message-ID: <42693753.7010907@xs4all.nl> Date: Fri, 22 Apr 2005 19:41:39 +0200 From: Ruud Linders User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: romieu@fr.zoreil.com Subject: Patch for USR r8169 clone X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------020303020800050604020703" X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rkmp@xs4all.nl Precedence: bulk X-list: netdev Content-Length: 956 Lines: 36 This is a multi-part message in MIME format. --------------020303020800050604020703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, This patch makes my U.S.Robotics USR997902 gigabit ethernet card work. Compiled and tested and working fine for me. Please consider including in next update to r8169.c. Thanks, Ruud Linders --------------020303020800050604020703 Content-Type: text/plain; name="PATCH.r8169.c_for_USR997902" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="PATCH.r8169.c_for_USR997902" --- r8169.c.ORIG 2004-12-25 11:36:12.000000000 +0100 +++ r8169.c 2005-04-22 19:18:12.000000000 +0200 @@ -151,6 +151,7 @@ static struct pci_device_id rtl8169_pci_tbl[] = { {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0x16EC, 0x0116, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0,}, }; --------------020303020800050604020703-- From hadi@cyberus.ca Fri Apr 22 11:18:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:18:39 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIIQdD009616 for ; Fri, 22 Apr 2005 11:18:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DP2jW-0002kf-VU for netdev@oss.sgi.com; Fri, 22 Apr 2005 14:18:30 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DP2jS-0006tq-93; Fri, 22 Apr 2005 14:18:26 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <20050422172108.GA10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 14:18:22 -0400 Message-Id: <1114193902.7978.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 293 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: 2567 Lines: 64 On Fri, 2005-22-04 at 19:21 +0200, Andi Kleen wrote: > On Fri, Apr 22, 2005 at 08:33:15AM -0400, jamal wrote: [..] > > They should not run slower - but they may consume more CPU. > > They actually run slower. > Why do they run slower? There could be 1000 other variables involved? What is it that makes you so sure it is NAPI? I know you are capable of proving it is NAPI - please do so. > Now before David complains this was with old 2.6 kernels and I dont have > time right now to rerun the benchmarks, but at least I dont think > there was ever any patch addressing these issues. > It would be helpful if you use new kernels of course - that reduces the number of variables to look at. > > this is a design choice - a solution could be created to "fix" this but > > hasnt happened because there has not been a good reason to complicate > > things. The people who are bitching about this are benchmarkers who want > > to win at both high and low rates and they are not happy because while > > they can win at high rates, they cant at low rates. > > My impression is that NAPI seems to be more optimized for a rather > obscure work load (routing), while it does not seem to be that > great on the far more common server/client type workloads. > If that was a design choice then it was a bad design. > There is only one complaint I have ever heard about NAPI and it is about low rates: It consumes more CPU at very low rates. Very low rates depends on how fast your CPU can process at any given time. Refer to my earlier email. Are you saying low rates are a common load? The choices are: a) at high rates you die or b) at _very low_ rates you consume more CPU (3-6% more depending on your system). Logic says lets choose a). You could overcome b) by turning on mitigation at the expense of latency. We could "fix" at a cost of making the whole state machine complex - which would be defeating the " optimize for the common". You are the first person i have heard that says NAPI would be slower in terms of throughput or latency at low rates. My experiences is there is no difference between the two at low input rate. It would be interesting to see the data. >> Note, this would entirely solve what Andi and the SGI people are >> talking about. > > Perhaps, but Linux has to perform well on old hardware too. > New silicon is not a solution. > I dont see any reason to "fix" anything (note my use of quotes) on old hardware. You have a workaround. OTOH, provide data to prove otherwise - we all want Linux to be the best. cheers, jamal From ak@muc.de Fri Apr 22 11:30:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:30:19 -0700 (PDT) Received: from colin2.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIU5dD010725 for ; Fri, 22 Apr 2005 11:30:06 -0700 Received: (qmail 58939 invoked by uid 3709); 22 Apr 2005 18:30:04 -0000 Date: 22 Apr 2005 20:30:04 +0200 Date: Fri, 22 Apr 2005 20:30:04 +0200 From: Andi Kleen To: jamal Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050422183004.GC10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114193902.7978.39.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 294 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: 1697 Lines: 45 On Fri, Apr 22, 2005 at 02:18:22PM -0400, jamal wrote: > On Fri, 2005-22-04 at 19:21 +0200, Andi Kleen wrote: > > On Fri, Apr 22, 2005 at 08:33:15AM -0400, jamal wrote: > [..] > > > They should not run slower - but they may consume more CPU. > > > > They actually run slower. > > > > Why do they run slower? There could be 1000 other variables involved? > What is it that makes you so sure it is NAPI? > I know you are capable of proving it is NAPI - please do so. We tested back then by downgrading to an older non NAPI tg3 driver and it made the problem go away :) The broadcom bcm57xx driver which did not support NAPI at this time was also much faster. > > Now before David complains this was with old 2.6 kernels and I dont have > > time right now to rerun the benchmarks, but at least I dont think > > there was ever any patch addressing these issues. > > > > It would be helpful if you use new kernels of course - that reduces the > number of variables to look at. It was customers who use certified SLES kernels. > There is only one complaint I have ever heard about NAPI and it is about > low rates: It consumes more CPU at very low rates. Very low rates It was not only more CPU usage, but actually slower network performance on systems with plenty of CPU power. Also I doubt the workload Jesse and Greg/Arthur/SGI saw also had issues with CPU power (can you guys confirm?) > You are the first person i have heard that says NAPI would be slower > in terms of throughput or latency at low rates. My experiences is there > is no difference between the two at low input rate. It would be > interesting to see the data. Well, did you ever test a non routing workload? -Andi From romieu@fr.zoreil.com Fri Apr 22 11:34:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:34:33 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIYJdD011666 for ; Fri, 22 Apr 2005 11:34:20 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j3MIVIH2012701; Fri, 22 Apr 2005 20:31:18 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j3MIVDX5012700; Fri, 22 Apr 2005 20:31:13 +0200 Date: Fri, 22 Apr 2005 20:31:13 +0200 From: Francois Romieu To: Ruud Linders Cc: netdev@oss.sgi.com Subject: Re: Patch for USR r8169 clone Message-ID: <20050422183113.GA12371@electric-eye.fr.zoreil.com> References: <42693753.7010907@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42693753.7010907@xs4all.nl> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 295 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: 674 Lines: 20 Ruud Linders : [pci id for the r8169 based network adapter made by USR] > Please consider including in next update to r8169.c. Thanks for your work but the same patch has been sent to Andrew Morton, Jeff Garzik and our favorite netdev@oss.sgi.com mailing list the 11 of april 2005. > --- r8169.c.ORIG 2004-12-25 11:36:12.000000000 +0100 > +++ r8169.c 2005-04-22 19:18:12.000000000 +0200 > @@ -151,6 +151,7 @@ > static struct pci_device_id rtl8169_pci_tbl[] = { > {0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, > {0x1186, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, > + {0x16EC, 0x0116, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, (nit: s/EC/ec/) -- Ueimor From akepner@sgi.com Fri Apr 22 11:39:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:39:29 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIcsdD012387 for ; Fri, 22 Apr 2005 11:38:54 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j3MKJMbm015708 for ; Fri, 22 Apr 2005 13:19:32 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-49.corp.sgi.com [134.15.0.49]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3MIcKlV17220678; Fri, 22 Apr 2005 11:38:21 -0700 (PDT) Date: Fri, 22 Apr 2005 11:37:17 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Andi Kleen cc: jamal , Greg Banks , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <20050422183004.GC10598@muc.de> Message-ID: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 415 Lines: 17 On Fri, 22 Apr 2005, Andi Kleen wrote: > .... > Also I doubt the workload Jesse and Greg/Arthur/SGI saw also had issues > with CPU power (can you guys confirm?) > The problem that we've had is that flushing PIOs can take a long time. So the CPU can spend more time spinning, waiting for the PIOs to flush, than doing useful work. I'm going to try to get some new (2.6.12-rc2) data this weekend. -- Arthur From davem@davemloft.net Fri Apr 22 11:57:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:57:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIvgdD013928 for ; Fri, 22 Apr 2005 11:57:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP3EV-0002cL-00; Fri, 22 Apr 2005 11:50:31 -0700 Date: Fri, 22 Apr 2005 11:50:30 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Cc: akepner@sgi.com, mchan@broadcom.com Subject: [TG3]: test minimal hw coalescing Message-Id: <20050422115030.544fddf7.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1911 Lines: 48 For the folks who want to play around with trying to eliminate some of the cruddy NAPI behavior with tg3, give the following patch a try. You can play with the LOW_{RX,TX}COL_TICKS, LOW_{RX,TX}MAX_FRAMES, et al. values to see if some settings work better than others. The current values are basically pulled out of a hat and should be verified with real performance testing. I'm more than happy to put something like this into the upstream driver, especially so if someone can get some real numbers to show both before and after (hint hint). :-) I also have to fix tg3.c to use the tagged irq status mode. Long ago when I wrote the NAPI support I couldn't figure out how to make that mode work with NAPI's IRQ disabling/enabling, but now I know that I have to keep track of the current semaphore count in the driver software state in order to do it correctly. This should help PIO overhead as well. drivers/net/tg3.c: f65ca3b2da6f3fcdb464cd8f9d0b53b5611103b1 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -5366,16 +5366,16 @@ static int tg3_reset_hw(struct tg3 *tp) udelay(10); } - tw32(HOSTCC_RXCOL_TICKS, 0); + tw32(HOSTCC_RXCOL_TICKS, LOW_RXCOL_TICKS); tw32(HOSTCC_TXCOL_TICKS, LOW_TXCOL_TICKS); - tw32(HOSTCC_RXMAX_FRAMES, 1); - tw32(HOSTCC_TXMAX_FRAMES, LOW_RXMAX_FRAMES); + tw32(HOSTCC_RXMAX_FRAMES, LOW_RXMAX_FRAMES); + tw32(HOSTCC_TXMAX_FRAMES, LOW_TXMAX_FRAMES); if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) { - tw32(HOSTCC_RXCOAL_TICK_INT, 0); - tw32(HOSTCC_TXCOAL_TICK_INT, 0); + tw32(HOSTCC_RXCOAL_TICK_INT, DEFAULT_RXCOAL_TICK_INT); + tw32(HOSTCC_TXCOAL_TICK_INT, DEFAULT_TXCOAL_TICK_INT); } - tw32(HOSTCC_RXCOAL_MAXF_INT, 1); - tw32(HOSTCC_TXCOAL_MAXF_INT, 0); + tw32(HOSTCC_RXCOAL_MAXF_INT, DEFAULT_RXCOAL_MAXF_INT); + tw32(HOSTCC_TXCOAL_MAXF_INT, DEFAULT_TXCOAL_MAXF_INT); /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, From davem@davemloft.net Fri Apr 22 11:59:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 11:59:57 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MIxsdD014392 for ; Fri, 22 Apr 2005 11:59:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP3GQ-0002ea-00; Fri, 22 Apr 2005 11:52:30 -0700 Date: Fri, 22 Apr 2005 11:52:30 -0700 From: "David S. Miller" To: Arthur Kepner Cc: ak@muc.de, hadi@cyberus.ca, gnb@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-Id: <20050422115230.6037a362.davem@davemloft.net> In-Reply-To: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 391 Lines: 11 On Fri, 22 Apr 2005 11:37:17 -0700 (PDT) Arthur Kepner wrote: > I'm going to try to get some new (2.6.12-rc2) data this weekend. That sounds great. See the other email I posted (you were CC:'d) where I show a patch to tg3 to minimally enable some hw interrupt coalescing which might help. It would be great to see what that kind of change does for your tests. Thanks. From hadi@cyberus.ca Fri Apr 22 12:01:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 12:01:43 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MJ1VdD014977 for ; Fri, 22 Apr 2005 12:01:31 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DP3PC-0004jz-Cu for netdev@oss.sgi.com; Fri, 22 Apr 2005 15:01:34 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DP3P9-0004yH-2h; Fri, 22 Apr 2005 15:01:31 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <20050422183004.GC10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 15:01:27 -0400 Message-Id: <1114196487.7978.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 299 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: 3790 Lines: 95 On Fri, 2005-22-04 at 20:30 +0200, Andi Kleen wrote: > On Fri, Apr 22, 2005 at 02:18:22PM -0400, jamal wrote: > > On Fri, 2005-22-04 at 19:21 +0200, Andi Kleen wrote: > > Why do they run slower? There could be 1000 other variables involved? > > What is it that makes you so sure it is NAPI? > > I know you are capable of proving it is NAPI - please do so. > > We tested back then by downgrading to an older non NAPI tg3 driver > and it made the problem go away :) The broadcom bcm57xx driver which > did not support NAPI at this time was also much faster. > Dont mean to make this into a meaningless debate - but have you thought of the fact maybe it could be a driver bug in case of NAPI? The e1000 NAPI had a serious bug since day one that was only recently fixed (I think Robert provided the fix - but the intel folks made the release). > > It would be helpful if you use new kernels of course - that reduces the > > number of variables to look at. > > It was customers who use certified SLES kernels. That makes it hard. You understand that there could be other issues - thats why its safer to just ask for latest kernel. > > There is only one complaint I have ever heard about NAPI and it is about > > low rates: It consumes more CPU at very low rates. Very low rates > > It was not only more CPU usage, but actually slower network performance > on systems with plenty of CPU power. > This is definetely a new thing nobody has mentioned before. Whatever difference there is would not be that much. > Also I doubt the workload Jesse and Greg/Arthur/SGI saw also had issues > with CPU power (can you guys confirm?) > The SGI folks seem to be on their way to collect some serious data. So that should help. > > You are the first person i have heard that says NAPI would be slower > > in terms of throughput or latency at low rates. My experiences is there > > is no difference between the two at low input rate. It would be > > interesting to see the data. > > Well, did you ever test a non routing workload? > I did extensive tests with UDP because it was easier to analyze as well as to pump data at. I did some TCP tests with many connections but the heursitics of retransmits, congestion control etc made it harder to analyze. If i had a bulk type of workload on a TCP server at gigabit rate it still isnt that interesting - they tend to go at MTU packet size which is typically less than 90Kpps worst case. With a simple UDP sink server that just swallowed packets it was easier. I could send it 1Mpps and exercise that path. So this is where i did most of the testing as far as non-routing paths - Robert is the other person you could ask this question. Very interesting observation to note in the case of UDP: at some point on my slow machine at 100Kpps that NAPI was able to keep up with, the socket queue got overloaded. And packets started dropping at the socket queue. I did provide patches to have feedback that goes all the way to the driver level; however intepreting these feedback codes is hard. Look at the comments in dev.c from Alexey to understand why this is hard;-> comments read as follows: ------ /* Jamal, now you will not able to escape explaining * me how you were going to use this. :-) */ ------- That comment serves as a reminder to revist this. About everytime i see i go back and look at my notes. So the challenge is still on the table. The old non-NAPI code was never able to stress the socket code the way NAPI does because the system simply died - so this was never seen. Things like the classical lazy receiver processing would have been useful to implement - but very hard to do in Linux. Back to my comments: We need to analyze why something is happening. Simply saying "its NAPI" is wrong. cheers, jamal From davem@davemloft.net Fri Apr 22 12:14:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 12:15:01 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MJEjdD016448 for ; Fri, 22 Apr 2005 12:14:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP3Ug-0002jB-00; Fri, 22 Apr 2005 12:07:14 -0700 Date: Fri, 22 Apr 2005 12:07:14 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: ak@muc.de, gnb@sgi.com, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-Id: <20050422120714.35f56e76.davem@davemloft.net> In-Reply-To: <1114196487.7978.65.camel@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <1114196487.7978.65.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 701 Lines: 16 On Fri, 22 Apr 2005 15:01:27 -0400 jamal wrote: > Dont mean to make this into a meaningless debate - but have you thought > of the fact maybe it could be a driver bug in case of NAPI? > The e1000 NAPI had a serious bug since day one that was only recently > fixed (I think Robert provided the fix - but the intel folks made the > release). True, but really Jamal I think a lot of this has to do with not doing a small amount of hw coalescing even when doing NAPI. Let's get people testing changes like that to see if it undoes the bad cases. I want to do something proactive with these reports instead of just asking for more performance data like a bunch of crazed lunatics :-) From hadi@cyberus.ca Fri Apr 22 12:21:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 12:21:45 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MJLWdD020749 for ; Fri, 22 Apr 2005 12:21:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DP3iZ-000232-W0 for netdev@oss.sgi.com; Fri, 22 Apr 2005 15:21:35 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DP3iX-0007go-6W; Fri, 22 Apr 2005 15:21:33 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: ak@muc.de, gnb@sgi.com, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <20050422120714.35f56e76.davem@davemloft.net> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <1114196487.7978.65.camel@localhost.localdomain> <20050422120714.35f56e76.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 15:21:29 -0400 Message-Id: <1114197689.7978.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 301 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: 439 Lines: 14 On Fri, 2005-22-04 at 12:07 -0700, David S. Miller wrote: > Let's get people testing changes like that to see if it undoes > the bad cases. I want to do something proactive with these > reports instead of just asking for more performance data like > a bunch of crazed lunatics :-) But we are crazed lunatics ;-> I have a feeling that the patch will solve the problem and we wont have the fun of seeing interesting data. cheers, jamal From sri@us.ibm.com Fri Apr 22 12:28:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 12:28:40 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MJSPdD022206 for ; Fri, 22 Apr 2005 12:28:26 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3MJSM4I681338 for ; Fri, 22 Apr 2005 15:28:22 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3MJSMVA327074 for ; Fri, 22 Apr 2005 13:28:22 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSLds028862 for ; Fri, 22 Apr 2005 13:28:22 -0600 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSL7h028810; Fri, 22 Apr 2005 13:28:21 -0600 Date: Fri, 22 Apr 2005 12:28:20 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [PATCH][SCTP] Fix SCTP_ASSOCINFO getsockopt for 1-1 style sockets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 828 Lines: 24 Hi Dave, Please apply to 2.6. Thanks Sridhar ======================================================================= [SCTP] Fix SCTP_ASSOCINFO getsockopt for 1-1 style sockets. Signed-off-by: Vladislav Yasevich Signed-off-by: Sridhar Samudrala ======================================================================== diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c 2005-04-21 16:20:07 -07:00 +++ b/net/sctp/socket.c 2005-04-21 16:20:07 -07:00 @@ -3473,7 +3473,7 @@ return -EINVAL; /* Values correspoinding to the specific association */ - if (assocparams.sasoc_assoc_id != 0) { + if (asoc) { assocparams.sasoc_asocmaxrxt = asoc->max_retrans; assocparams.sasoc_peer_rwnd = asoc->peer.rwnd; assocparams.sasoc_local_rwnd = asoc->a_rwnd; From greearb@candelatech.com Fri Apr 22 12:39:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 12:39:25 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MJdCdD023885 for ; Fri, 22 Apr 2005 12:39:12 -0700 Received: from [71.112.202.130] (pool-71-112-202-130.sttlwa.dsl-w.verizon.net [71.112.202.130]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j3MK7eGf002165; Fri, 22 Apr 2005 13:07:40 -0700 Message-ID: <426952DE.5090203@candelatech.com> Date: Fri, 22 Apr 2005 12:39:10 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> <42643BB9.6050705@candelatech.com> <20050418160147.6fd7ac9a.davem@davemloft.net> <42644FD4.3030200@candelatech.com> <20050419231442.7e37b087.davem@davemloft.net> In-Reply-To: <20050419231442.7e37b087.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------070602010208030404080903" X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 306 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: 2834 Lines: 85 This is a multi-part message in MIME format. --------------070602010208030404080903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Mon, 18 Apr 2005 17:24:52 -0700 > Ben Greear wrote: > > >>David S. Miller wrote: >> >> >>>So write the patch to add such comments. It would have taken the >>>same amount of typing as writing that paragraph saying how great an >>>addition this would be. :) >> >>Signed-off-by: Ben Greear > > > -EPATCH_MUNGED_BY_MAIL_CLIENT Sending as attachments this time...plz let me know if these work better. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com --------------070602010208030404080903 Content-Type: text/plain; name="dev.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dev.c.patch" --- linux-2.6.11/net/core/dev.c 2005-03-01 23:38:09.000000000 -0800 +++ linux-2.6.11.mostly-clean/net/core/dev.c 2005-04-18 17:23:21.000000000 -0700 @@ -1214,6 +1214,19 @@ * A negative errno code is returned on a failure. A success does not * guarantee the frame will be transmitted as it may be dropped due * to congestion or traffic shaping. + * + * ----------------------------------------------------------------------------------- + * I notice this method can also return errors from the queue disciplines, + * including NET_XMIT_DROP, which is a positive value. So, errors can also + * be positive. + * + * Regardless of the return value, the skb is consumed, so it is currently + * difficult to retry a send to this method. (You can bump the ref count + * before sending to hold a reference for retry if you are careful.) + * + * When calling this method, interrupts MUST be enabled. This is because + * the BH enable code must have IRQs enabled so that it will not deadlock. + * --BLG */ int dev_queue_xmit(struct sk_buff *skb) --------------070602010208030404080903 Content-Type: text/plain; name="netdevices.txt.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdevices.txt.patch" --- linux-2.6.11/Documentation/networking/netdevices.txt 2005-03-01 23:37:50.000000000 -0800 +++ linux-2.6.11.p4s/Documentation/networking/netdevices.txt 2005-04-18 16:59:43.000000000 -0700 @@ -51,6 +51,8 @@ set_multicast_list Context: BHs disabled Notes: netif_queue_stopped() is guaranteed false + Interrupts must be enabled when calling hard_start_xmit. + (Interrupts must also be enabled when enabling the BH handler.) Return codes: o NETDEV_TX_OK everything ok. o NETDEV_TX_BUSY Cannot transmit packet, try later --------------070602010208030404080903-- From mchan@broadcom.com Fri Apr 22 13:31:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 13:31:12 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MKUxdD027465 for ; Fri, 22 Apr 2005 13:31:00 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Fri, 22 Apr 2005 13:31:01 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 22 Apr 2005 13:30:43 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AUN94327; Fri, 22 Apr 2005 13:30:34 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA15514; Fri, 22 Apr 2005 13:30:34 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Apr 2005 20:30:33 +0000 Received: from rh4 by nt-irva-0741; 22 Apr 2005 12:32:34 -0700 Subject: Re: [TG3]: test minimal hw coalescing From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com, akepner@sgi.com In-Reply-To: <20050422115030.544fddf7.davem@davemloft.net> References: <20050422115030.544fddf7.davem@davemloft.net> Date: Fri, 22 Apr 2005 12:32:29 -0700 Message-ID: <1114198349.6158.20.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E77808F1OC1528160-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2961 Lines: 68 On Fri, 2005-04-22 at 11:50 -0700, David S. Miller wrote: > For the folks who want to play around with trying to eliminate > some of the cruddy NAPI behavior with tg3, give the following > patch a try. > > You can play with the LOW_{RX,TX}COL_TICKS, LOW_{RX,TX}MAX_FRAMES, > et al. values to see if some settings work better than others. > The current values are basically pulled out of a hat and should > be verified with real performance testing. > This patch to turn on "clear ticks" in coalescing mode on top of David's patch may also be beneficial. The "clear ticks" mode will reset the coalescing ticks counter when a new packet is received. Without "clear ticks", you normally have to set the ticks to be roughly equal to the time it takes to receive the number packets to be coalesced. For example, if your RXCOL_FRAMES is set to 5, your RXCOL_TICKS should be roughly 5 x 12 = 60 ticks. (It takes about 12 ticks (usec) to receive a 1.5K packet at Gigabit) The problem is that if only 1 packet is received, you still have to wait for 60 usec to get the rx interrupt and so latency will suffer. With "clear ticks" mode enabled, RXCOL_TICKS can be set a lot lower and independent of the RXCOL_FRAMES. You still get the benefit of coalescing all the packets up to RXCOL_FRAMES if they actually arrive. If fewer packets arrive, you get the interrupt sooner. A good starting value for RXCOL_TICKS is 15 - 20 ticks. diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c 2005-04-22 11:53:34.000000000 -0700 +++ b/drivers/net/tg3.c 2005-04-22 12:04:26.000000000 -0700 @@ -8494,6 +8494,11 @@ grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) tp->tg3_flags2 |= TG3_FLG2_IS_5788; + if ((GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700) && + !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) + tp->coalesce_mode |= HOSTCC_MODE_CLRTICK_TXBD | + HOSTCC_MODE_CLRTICK_RXBD; + /* these are limited to 10/100 only */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || diff -Nru a/drivers/net/tg3.h b/drivers/net/tg3.h --- a/drivers/net/tg3.h 2005-04-22 11:53:34.000000000 -0700 +++ b/drivers/net/tg3.h 2005-04-22 12:04:26.000000000 -0700 @@ -875,7 +875,7 @@ #define HOSTCC_STATUS 0x00003c04 #define HOSTCC_STATUS_ERROR_ATTN 0x00000004 #define HOSTCC_RXCOL_TICKS 0x00003c08 -#define LOW_RXCOL_TICKS 0x00000032 +#define LOW_RXCOL_TICKS 0x00000014 #define DEFAULT_RXCOL_TICKS 0x00000048 #define HIGH_RXCOL_TICKS 0x00000096 #define HOSTCC_TXCOL_TICKS 0x00003c0c @@ -891,7 +891,7 @@ #define DEFAULT_TXMAX_FRAMES 0x0000004b #define HIGH_TXMAX_FRAMES 0x00000052 #define HOSTCC_RXCOAL_TICK_INT 0x00003c18 -#define DEFAULT_RXCOAL_TICK_INT 0x00000019 +#define DEFAULT_RXCOAL_TICK_INT 0x00000014 #define HOSTCC_TXCOAL_TICK_INT 0x00003c1c #define DEFAULT_TXCOAL_TICK_INT 0x00000019 #define HOSTCC_RXCOAL_MAXF_INT 0x00003c20 From sri@us.ibm.com Fri Apr 22 13:50:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 13:50:21 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MKo8dD028921 for ; Fri, 22 Apr 2005 13:50:10 -0700 Received: from e6.ny.us.ibm.com ([192.168.1.106]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJTBqN024619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Apr 2005 15:29:11 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJTB1C013910 for ; Fri, 22 Apr 2005 15:29:11 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3MJTBf9074090 for ; Fri, 22 Apr 2005 15:29:11 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJTAXN027953 for ; Fri, 22 Apr 2005 14:29:11 -0500 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJT9eD027921; Fri, 22 Apr 2005 14:29:10 -0500 Date: Fri, 22 Apr 2005 12:29:09 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [PATCH][SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit(). Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 969 Lines: 33 Hi Dave, Please apply to 2.6. Thanks Sridhar =========================================================================== [SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit(). Signed-off-by: Sridhar Samudrala =========================================================================== diff -Nru a/net/sctp/output.c b/net/sctp/output.c --- a/net/sctp/output.c 2005-04-21 16:25:54 -07:00 +++ b/net/sctp/output.c 2005-04-21 16:25:54 -07:00 @@ -313,12 +313,12 @@ sk = chunk->skb->sk; /* Allocate the new skb. */ - nskb = dev_alloc_skb(packet->size); + nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC); if (!nskb) goto nomem; /* Make sure the outbound skb has enough header room reserved. */ - skb_reserve(nskb, packet->overhead); + skb_reserve(nskb, packet->overhead + LL_MAX_HEADER); /* Set the owning socket so that we know where to get the * destination IP address. -- From herbert@gondor.apana.org.au Fri Apr 22 14:45:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 14:45:38 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MLjUdD032618 for ; Fri, 22 Apr 2005 14:45:32 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DP5xd-0003Gi-00; Sat, 23 Apr 2005 07:45:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DP5xU-0000ZG-00; Sat, 23 Apr 2005 07:45:08 +1000 From: Herbert Xu To: cfriesen@nortel.com (Chris Friesen) Subject: Re: 2.6.9 BUG in tcp_transmit_skb at net/ipv4/tcp_output.c -- full output Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <42691EBC.9040106@nortel.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 23 Apr 2005 07:45:08 +1000 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 452 Lines: 14 Chris Friesen wrote: > Here's the full output of the bug > > kernel BUG in tcp_transmit_skb at net/ipv4/tcp_output.c:277! There's been lots of fixes to the TSO code since 2.6.9. Please test 2.6.11.7 instead. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From cfriesen@nortel.com Fri Apr 22 15:15:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 15:15:18 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MMF4dD002430 for ; Fri, 22 Apr 2005 15:15:06 -0700 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j3MMCtB14895; Fri, 22 Apr 2005 18:12:55 -0400 (EDT) Received: from nortel.com (acart285.ca.nortel.com [47.130.17.148]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLTSMK; Fri, 22 Apr 2005 18:13:09 -0400 Message-ID: <426976F2.3000604@nortel.com> Date: Fri, 22 Apr 2005 16:13:06 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: 2.6.9 BUG in tcp_transmit_skb at net/ipv4/tcp_output.c -- full output References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: netdev Content-Length: 648 Lines: 18 Herbert Xu wrote: > There's been lots of fixes to the TSO code since 2.6.9. Please test > 2.6.11.7 instead. Unfortunately I can't move to the latest. We have a bunch ofkernel modules from various vendors, board support packages that aren't in mainline, etc. We're in the process of moving to 2.6.10 and that requires support from six separate companies. It's a mess. If it matters, I'm on a G5 with the sungem driver (which I don't think supports TSO). I've already applied the last -ac patch for 2.6.9 which has a number of fixes for 2.6.9 TCP issues, but apparently not all of them were caught. Any pointers you can give me? Chris From jmoyer@redhat.com Fri Apr 22 15:26:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 15:26:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MMQ2dD003640 for ; Fri, 22 Apr 2005 15:26:03 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3MMQ1ng028062; Fri, 22 Apr 2005 18:26:01 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3MMQ1O16320; Fri, 22 Apr 2005 18:26:01 -0400 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j3MMQ12t008957; Fri, 22 Apr 2005 18:26:01 -0400 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j3MMOkEn013829; Fri, 22 Apr 2005 18:24:46 -0400 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j3MMOkkb013826; Fri, 22 Apr 2005 18:24:46 -0400 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.31150.194263.732284@segfault.boston.redhat.com> Date: Fri, 22 Apr 2005 18:24:46 -0400 To: Matt Mackall Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking In-Reply-To: <5.454130102@selenic.com> References: <4.454130102@selenic.com> <5.454130102@selenic.com> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 1223 Lines: 32 ==> Regarding [PATCH 4/7] netpoll: fix ->poll() locking; Matt Mackall adds: mpm> Introduce a per-client poll lock and flag. The lock assures we never mpm> have more than one caller in dev->poll(). The flag provides recursion mpm> avoidance on UP where the lock disappears. I don't think it makes sense to have the poll lock associated with a struct netpoll. We want to guard simultaneous access to the device's poll routine. With this implementation, if we have multiple netpoll clients running at the same time, we can have multiple callers of dev->poll at the same time. In other words, there is not a 1:1 relationship between struct netpoll's and struct net_device's. Please consider making this a per device lock. -Jeff @@ -74,13 +80,10 @@ static void poll_napi(struct netpoll *np) { int budget = 16; - unsigned long flags; - struct softnet_data *queue; - spin_lock_irqsave(&netpoll_poll_lock, flags); - queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && - !list_empty(&queue->poll_list)) { + np->poll_owner != __smp_processor_id() && + spin_trylock(&np->poll_lock)) { np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); From herbert@gondor.apana.org.au Fri Apr 22 15:32:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 15:33:07 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MMWpdD004653 for ; Fri, 22 Apr 2005 15:32:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DP6hX-0003ZL-00; Sat, 23 Apr 2005 08:32:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DP6hQ-0000dR-00; Sat, 23 Apr 2005 08:32:36 +1000 Date: Sat, 23 Apr 2005 08:32:36 +1000 To: Chris Friesen Cc: netdev@oss.sgi.com Subject: Re: 2.6.9 BUG in tcp_transmit_skb at net/ipv4/tcp_output.c -- full output Message-ID: <20050422223236.GA2425@gondor.apana.org.au> References: <426976F2.3000604@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426976F2.3000604@nortel.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 631 Lines: 14 On Fri, Apr 22, 2005 at 04:13:06PM -0600, Chris Friesen wrote: > > Unfortunately I can't move to the latest. We have a bunch ofkernel > modules from various vendors, board support packages that aren't in > mainline, etc. We're in the process of moving to 2.6.10 and that > requires support from six separate companies. It's a mess. You could also try going back to 2.6.8.1 since that predates the TSO restructure. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From sri@us.ibm.com Fri Apr 22 15:48:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 15:48:43 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MMmRdD005953 for ; Fri, 22 Apr 2005 15:48:30 -0700 Received: from e1.ny.us.ibm.com ([192.168.1.101]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSw03024608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Apr 2005 15:28:58 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSwab014509 for ; Fri, 22 Apr 2005 15:28:58 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3MJSwf9043878 for ; Fri, 22 Apr 2005 15:28:58 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSvdC027339 for ; Fri, 22 Apr 2005 14:28:57 -0500 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3MJSuXT027269; Fri, 22 Apr 2005 14:28:57 -0500 Date: Fri, 22 Apr 2005 12:28:56 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [PATCH][SCTP] Use ipv6_addr_any rather than ipv6_addr_type in sctp_v6_is_any(). Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 848 Lines: 27 Hi Dave, Please apply to 2.6. Thanks Sridhar ============================================================================= [SCTP] Use ipv6_addr_any() rather than ipv6_addr_type() in sctp_v6_is_any(). Signed-off-by: Brian Haley Signed-off-by: Sridhar Samudrala ============================================================================= diff -Nru a/net/sctp/ipv6.c b/net/sctp/ipv6.c --- a/net/sctp/ipv6.c 2005-04-21 16:21:58 -07:00 +++ b/net/sctp/ipv6.c 2005-04-21 16:21:58 -07:00 @@ -496,9 +496,7 @@ /* Is this a wildcard address? */ static int sctp_v6_is_any(const union sctp_addr *addr) { - int type; - type = ipv6_addr_type((struct in6_addr *)&addr->v6.sin6_addr); - return IPV6_ADDR_ANY == type; + return ipv6_addr_any(&addr->v6.sin6_addr); } /* Should this be available for binding? */ From davem@davemloft.net Fri Apr 22 15:59:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 15:59:49 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MMxadD006936 for ; Fri, 22 Apr 2005 15:59:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP70U-0004Ax-00; Fri, 22 Apr 2005 15:52:19 -0700 Date: Fri, 22 Apr 2005 15:52:18 -0700 From: "David S. Miller" To: jmoyer@redhat.com Cc: mpm@selenic.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking Message-Id: <20050422155218.223fa84d.davem@davemloft.net> In-Reply-To: <17001.31150.194263.732284@segfault.boston.redhat.com> References: <4.454130102@selenic.com> <5.454130102@selenic.com> <17001.31150.194263.732284@segfault.boston.redhat.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 871 Lines: 19 On Fri, 22 Apr 2005 18:24:46 -0400 Jeff Moyer wrote: > ==> Regarding [PATCH 4/7] netpoll: fix ->poll() locking; Matt Mackall adds: > > mpm> Introduce a per-client poll lock and flag. The lock assures we never > mpm> have more than one caller in dev->poll(). The flag provides recursion > mpm> avoidance on UP where the lock disappears. > > I don't think it makes sense to have the poll lock associated with a struct > netpoll. There should be a 1 to 1 relationship from netdev to netpoll, but I see no problems with a many to 1 relationship from netdev to netpoll, that is perfectly legal. It would give more stringent locking on dev->poll() invocations, not forget to lock when necessary. The only thing which is wrong is that netpoll_setup() should verify that netdev->np is NULL, and if it is not it should return an error. From jmoyer@redhat.com Fri Apr 22 16:04:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 16:04:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MN40dD007710 for ; Fri, 22 Apr 2005 16:04:01 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3MN3wKd001932; Fri, 22 Apr 2005 19:03:58 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3MN3wO22990; Fri, 22 Apr 2005 19:03:58 -0400 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.80.57]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j3MN3v2t011042; Fri, 22 Apr 2005 19:03:57 -0400 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.11/8.12.10) with ESMTP id j3MN2hMr014493; Fri, 22 Apr 2005 19:02:43 -0400 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.11/8.12.11/Submit) id j3MN2hsa014490; Fri, 22 Apr 2005 19:02:43 -0400 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.33427.462497.856777@segfault.boston.redhat.com> Date: Fri, 22 Apr 2005 19:02:43 -0400 To: "David S. Miller" Cc: mpm@selenic.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking In-Reply-To: <20050422155218.223fa84d.davem@davemloft.net> References: <4.454130102@selenic.com> <5.454130102@selenic.com> <17001.31150.194263.732284@segfault.boston.redhat.com> <20050422155218.223fa84d.davem@davemloft.net> X-Mailer: VM 7.19 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev Content-Length: 1387 Lines: 30 ==> Regarding Re: [PATCH 4/7] netpoll: fix ->poll() locking; "David S. Miller" adds: davem> On Fri, 22 Apr 2005 18:24:46 -0400 Jeff Moyer davem> wrote: >> ==> Regarding [PATCH 4/7] netpoll: fix ->poll() locking; Matt Mackall >> adds: >> mpm> Introduce a per-client poll lock and flag. The lock assures we never mpm> have more than one caller in dev->poll(). The flag provides recursion mpm> avoidance on UP where the lock disappears. >> I don't think it makes sense to have the poll lock associated with a >> struct netpoll. davem> There should be a 1 to 1 relationship from netdev to netpoll, but I davem> see no problems with a many to 1 relationship from netdev to davem> netpoll, that is perfectly legal. It would give more stringent davem> locking on dev->poll() invocations, not forget to lock when davem> necessary. davem> The only thing which is wrong is that netpoll_setup() should verify davem> that netdev-> np is NULL, and if it is not it should return an error. Oh yes, of course. Somehow I managed to forget that we now squirrel away the struct netpoll pointer in the net_device. Previously you could register multiple netpoll clients to one device, and this was useful for say doing netconsole and netdump over the same interface. If we've removed this ability, this is a bad thing. Oh dear... -Jeff From davem@davemloft.net Fri Apr 22 16:07:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 16:07:22 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MN7GdD008397 for ; Fri, 22 Apr 2005 16:07:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP77u-0004G2-00; Fri, 22 Apr 2005 15:59:58 -0700 Date: Fri, 22 Apr 2005 15:59:58 -0700 From: "David S. Miller" To: jmoyer@redhat.com Cc: mpm@selenic.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking Message-Id: <20050422155958.474a150c.davem@davemloft.net> In-Reply-To: <17001.33427.462497.856777@segfault.boston.redhat.com> References: <4.454130102@selenic.com> <5.454130102@selenic.com> <17001.31150.194263.732284@segfault.boston.redhat.com> <20050422155218.223fa84d.davem@davemloft.net> <17001.33427.462497.856777@segfault.boston.redhat.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 599 Lines: 14 On Fri, 22 Apr 2005 19:02:43 -0400 Jeff Moyer wrote: > Oh yes, of course. Somehow I managed to forget that we now squirrel away > the struct netpoll pointer in the net_device. Previously you could > register multiple netpoll clients to one device, and this was useful for > say doing netconsole and netdump over the same interface. If we've removed > this ability, this is a bad thing. Oh dear... In such a configuration, how did the netpoll code "tell" who the receive packets were for or did it send them to all registered netpoll clients for that device? Just curious. From gnb@melbourne.sgi.com Fri Apr 22 16:29:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 16:29:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3MNTFdD014040 for ; Fri, 22 Apr 2005 16:29:17 -0700 Received: from hole.melbourne.sgi.com (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24781; Sat, 23 Apr 2005 09:28:31 +1000 Received: by hole.melbourne.sgi.com (Postfix, from userid 16345) id DB7C11C082041; Sat, 23 Apr 2005 09:28:31 +1000 (EST) Date: Sat, 23 Apr 2005 09:28:31 +1000 From: Greg Banks To: jamal Cc: Andi Kleen , Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050422232831.GB6462@sgi.com> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114193902.7978.39.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@sgi.com Precedence: bulk X-list: netdev Content-Length: 3060 Lines: 74 On Fri, Apr 22, 2005 at 02:18:22PM -0400, jamal wrote: > On Fri, 2005-22-04 at 19:21 +0200, Andi Kleen wrote: > > On Fri, Apr 22, 2005 at 08:33:15AM -0400, jamal wrote: > [..] > > > They should not run slower - but they may consume more CPU. > > > > They actually run slower. > > IIRC I saw a similar but very small effect on Altix hardware about 18 months ago, but I'm unable to get at my old logbooks right now. I do remember the effect was very small compared to the CPU usage effect and I didn't bother investigating or mentioning it. > Why do they run slower? There could be 1000 other variables involved? > What is it that makes you so sure it is NAPI? At the time I was running 2 kernels identical except that one had NAPI disabled in tg3.c. > There is only one complaint I have ever heard about NAPI and it is about > low rates: It consumes more CPU at very low rates. Very low rates > depends on how fast your CPU can process at any given time. Refer to my > earlier email. Are you saying low rates are a common load? > > The choices are: a) at high rates you die or b) at _very low_ rates > you consume more CPU (3-6% more depending on your system). This is a false dichotomy. The mechanism could instead dynamically adjust to the actual network load. For example dev->weight could be dynamically adjusted according to a 1-second average packet arrival rate on that device. As a further example the driver could use that value as a guide to control interrupt coalescing parameters. In SGI's fileserving group we commonly see two very different traffic patterns, both of which must work efficiently without manual tuning. 1. high-bandwidth, CPU-sensitive: NFS and CIFS data and metadata traffic. 2. low bandwidth, latency-sensitive: metadata traffic on SGI's proprietary clustered filesystem. The solution on Irix was a dynamic feedback mechanism in the driver to control the interrupt coalescing parameters, so the driver adjusts to the predominant traffic. I think this is a generic problem that other people face too, possibly without being aware of it. Given that NAPI seeks to be a generic solution to device interrupt control, and given that it spreads responsibility between the driver and the device layer, I think there is room to improve NAPI to cater for various workloads without implementing enormously complicated control mechanisms in each driver. > Logic says lets choose a). You could overcome b) by turning on > mitigation at the expense of latency. We could "fix" at a cost of > making the whole state machine complex - which would be defeating > the " optimize for the common". Sure, NAPI is simple. Current experience on Altix is that NAPI is the solution that is clear, simple, and wrong. > >> Note, this would entirely solve what Andi and the SGI people are > >> talking about. > > > > Perhaps, but Linux has to perform well on old hardware too. > > New silicon is not a solution. Agreed. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From shemminger@osdl.org Fri Apr 22 16:41:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 16:42:10 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MNfudD015316 for ; Fri, 22 Apr 2005 16:41:56 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3MNfAs4017211 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Apr 2005 16:41:13 -0700 Date: Sat, 23 Apr 2005 09:40:38 +1000 From: Stephen Hemminger To: Greg Banks Cc: jamal , Andi Kleen , Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050423094038.72a8da73@localhost.localdomain> In-Reply-To: <20050422232831.GB6462@sgi.com> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 319 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: 3347 Lines: 78 On Sat, 23 Apr 2005 09:28:31 +1000 Greg Banks wrote: > On Fri, Apr 22, 2005 at 02:18:22PM -0400, jamal wrote: > > On Fri, 2005-22-04 at 19:21 +0200, Andi Kleen wrote: > > > On Fri, Apr 22, 2005 at 08:33:15AM -0400, jamal wrote: > > [..] > > > > They should not run slower - but they may consume more CPU. > > > > > > They actually run slower. > > > > > IIRC I saw a similar but very small effect on Altix hardware about 18 > months ago, but I'm unable to get at my old logbooks right now. I > do remember the effect was very small compared to the CPU usage effect > and I didn't bother investigating or mentioning it. > > > Why do they run slower? There could be 1000 other variables involved? > > What is it that makes you so sure it is NAPI? > > At the time I was running 2 kernels identical except that one had > NAPI disabled in tg3.c. > > > There is only one complaint I have ever heard about NAPI and it is about > > low rates: It consumes more CPU at very low rates. Very low rates > > depends on how fast your CPU can process at any given time. Refer to my > > earlier email. Are you saying low rates are a common load? > > > > The choices are: a) at high rates you die or b) at _very low_ rates > > you consume more CPU (3-6% more depending on your system). > > This is a false dichotomy. The mechanism could instead dynamically > adjust to the actual network load. For example dev->weight could > be dynamically adjusted according to a 1-second average packet > arrival rate on that device. As a further example the driver could > use that value as a guide to control interrupt coalescing parameters. > > In SGI's fileserving group we commonly see two very different traffic > patterns, both of which must work efficiently without manual tuning. > > 1. high-bandwidth, CPU-sensitive: NFS and CIFS data and metadata > traffic. > > 2. low bandwidth, latency-sensitive: metadata traffic on SGI's > proprietary clustered filesystem. > > The solution on Irix was a dynamic feedback mechanism in the driver > to control the interrupt coalescing parameters, so the driver > adjusts to the predominant traffic. > > I think this is a generic problem that other people face too, possibly > without being aware of it. Given that NAPI seeks to be a generic > solution to device interrupt control, and given that it spreads > responsibility between the driver and the device layer, I think > there is room to improve NAPI to cater for various workloads without > implementing enormously complicated control mechanisms in each driver. > > > Logic says lets choose a). You could overcome b) by turning on > > mitigation at the expense of latency. We could "fix" at a cost of > > making the whole state machine complex - which would be defeating > > the " optimize for the common". > > Sure, NAPI is simple. Current experience on Altix is that > NAPI is the solution that is clear, simple, and wrong. > > > >> Note, this would entirely solve what Andi and the SGI people are > > >> talking about. > > > > > > Perhaps, but Linux has to perform well on old hardware too. > > > New silicon is not a solution. > > Agreed. > > Greg. My experience is that NAPI adds latency and that can cause worse performance. I haven't seen a good analysis of the problem and/or simple tests to reproduce the problem From davem@davemloft.net Fri Apr 22 16:50:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 16:50:50 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3MNoldD016203 for ; Fri, 22 Apr 2005 16:50:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP7nZ-0004W1-00; Fri, 22 Apr 2005 16:43:01 -0700 Date: Fri, 22 Apr 2005 16:43:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: gnb@sgi.com, hadi@cyberus.ca, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-Id: <20050422164301.724343f6.davem@davemloft.net> In-Reply-To: <20050423094038.72a8da73@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1154 Lines: 27 On Sat, 23 Apr 2005 09:40:38 +1000 Stephen Hemminger wrote: > My experience is that NAPI adds latency and that can cause worse performance. > I haven't seen a good analysis of the problem and/or simple tests to reproduce > the problem Right, and it's cpu and bus speed dependant as to when you hit this bad case. If your packet rate is perfectly such that only 1 or 2 packets get processed per interrupt then NAPI loses badly due to the extra PIO overhead entailed from enabling and disabling interrupts. This is essential and well understood, and I personally don't need to see "numbers" to acknowledge this flaw. I hope that minimal mitigation settings alleviate this problem for the most part. When I moved tg3 over to NAPI, the happiest part of that was deleting the dynamic hw mitigation setting code the tg3 driver had. If ever that kind of thing goes back into the drivers, it should be based upon a common feedback variable (something based upon dev->weight perhaps), not reimplemented N times, once in every driver. With the dynamic schemes comes a new issue, how quickly to respond to changes in traffic patterns. From oxymoron@waste.org Fri Apr 22 19:14:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 19:14:45 -0700 (PDT) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3N2EgdD024879 for ; Fri, 22 Apr 2005 19:14:42 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.4/8.13.4/Debian-1) with ESMTP id j3N2EeK2024340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2005 21:14:41 -0500 Received: (from oxymoron@localhost) by waste.org (8.13.4/8.13.4/Submit) id j3N2EePG024337; Fri, 22 Apr 2005 21:14:40 -0500 Date: Fri, 22 Apr 2005 19:14:40 -0700 From: Matt Mackall To: "David S. Miller" Cc: jmoyer@redhat.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking Message-ID: <20050423021440.GZ21897@waste.org> References: <4.454130102@selenic.com> <5.454130102@selenic.com> <17001.31150.194263.732284@segfault.boston.redhat.com> <20050422155218.223fa84d.davem@davemloft.net> <17001.33427.462497.856777@segfault.boston.redhat.com> <20050422155958.474a150c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050422155958.474a150c.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 321 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: 830 Lines: 20 On Fri, Apr 22, 2005 at 03:59:58PM -0700, David S. Miller wrote: > On Fri, 22 Apr 2005 19:02:43 -0400 > Jeff Moyer wrote: > > > Oh yes, of course. Somehow I managed to forget that we now squirrel away > > the struct netpoll pointer in the net_device. Previously you could > > register multiple netpoll clients to one device, and this was useful for > > say doing netconsole and netdump over the same interface. If we've removed > > this ability, this is a bad thing. Oh dear... Hrm, it appears I forgot about that when I did the recent rework. > In such a configuration, how did the netpoll code "tell" who the > receive packets were for or did it send them to all registered > netpoll clients for that device? It walked a global list of clients. -- Mathematics is the supreme nostalgia of our time. From shemminger@osdl.org Fri Apr 22 19:53:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 19:53:19 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3N2rFdD028064 for ; Fri, 22 Apr 2005 19:53:16 -0700 Received: from localhost.localdomain ([150.203.247.9]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j3N2qPs4029510 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Apr 2005 19:52:28 -0700 Date: Sat, 23 Apr 2005 12:51:53 +1000 From: Stephen Hemminger To: "David S. Miller" Cc: gnb@sgi.com, hadi@cyberus.ca, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-ID: <20050423125153.65189ea0@localhost.localdomain> In-Reply-To: <20050422164301.724343f6.davem@davemloft.net> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> <20050422164301.724343f6.davem@davemloft.net> X-Mailer: Sylpheed-Claws 1.0.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-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 322 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: 1732 Lines: 39 On Fri, 22 Apr 2005 16:43:01 -0700 "David S. Miller" wrote: > On Sat, 23 Apr 2005 09:40:38 +1000 > Stephen Hemminger wrote: > > > My experience is that NAPI adds latency and that can cause worse performance. > > I haven't seen a good analysis of the problem and/or simple tests to reproduce > > the problem > > Right, and it's cpu and bus speed dependant as to when you hit > this bad case. If your packet rate is perfectly such that > only 1 or 2 packets get processed per interrupt then NAPI loses > badly due to the extra PIO overhead entailed from enabling and > disabling interrupts. > > This is essential and well understood, and I personally don't need > to see "numbers" to acknowledge this flaw. > > I hope that minimal mitigation settings alleviate this problem for > the most part. > > When I moved tg3 over to NAPI, the happiest part of that was deleting > the dynamic hw mitigation setting code the tg3 driver had. If ever > that kind of thing goes back into the drivers, it should be based > upon a common feedback variable (something based upon dev->weight > perhaps), not reimplemented N times, once in every driver. > > With the dynamic schemes comes a new issue, how quickly to respond > to changes in traffic patterns. One of the problem with the dynamic schemes, is there is no generic infrastructure to support it. There are some drivers that have tried dynamic schemes but each seems to reinvent some adhoc scheme. Seems like a good area for future research. Another related problem is some drivers use NAPI for both TX and RX and this can cause asymmetric behavior and scheduling issues. The whole dev->weight limit stuff assumes RX not TX usage of NAPI From hadi@cyberus.ca Fri Apr 22 20:04:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 20:04:34 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3N34VdD029260 for ; Fri, 22 Apr 2005 20:04:33 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DPAwW-000288-VV for netdev@oss.sgi.com; Fri, 22 Apr 2005 21:04:28 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DPAwa-0007xm-6X; Fri, 22 Apr 2005 23:04:32 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Stephen Hemminger , gnb@sgi.com, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <20050422164301.724343f6.davem@davemloft.net> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> <20050422164301.724343f6.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Fri, 22 Apr 2005 23:04:25 -0400 Message-Id: <1114225465.7669.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 323 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: 807 Lines: 21 On Fri, 2005-22-04 at 16:43 -0700, David S. Miller wrote: > With the dynamic schemes comes a new issue, how quickly to respond > to changes in traffic patterns. Unfortunately, dynamic adjustment of mitigation parameters - in my experiments at least (pre-NAPI) - show stability is hard to achieve. In fact the early tulip driver had about 8 levels of mitigation (that i put in and later taken out by Robert due to the instability). The one thing that has been tossed around is to modify the state machine such that the netdev is not taken out of the poll list for at least one more poll round or a timeout period. I did try this a while back and the extra poll did consume extra CPU - it probably isnt as bad as done by extra PIO(s); I still think static mitigation + NAPI should do it. cheers, jamal From linux_lover2004@yahoo.com Fri Apr 22 21:42:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 21:42:43 -0700 (PDT) Received: from web52208.mail.yahoo.com (web52208.mail.yahoo.com [206.190.39.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3N4gedD006757 for ; Fri, 22 Apr 2005 21:42:40 -0700 Received: (qmail 25349 invoked by uid 60001); 23 Apr 2005 04:42:39 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=yg53Ks+EPA9yTlTLkr+n7dzAW2uXVQaFRH6LszbUbpsLnDbCOoRCLwvUrgXKWWekyb8G1QE77fAirSlaNPqr8ZGkiL+lLjyAC21P+m8rPo6RVy4X0gbBAJ0Hi1NreyFyUdxatVLl2KbEpNU2++4rxRLDF3b/oRjzoBXV5WipzzI= ; Message-ID: <20050423044239.25347.qmail@web52208.mail.yahoo.com> Received: from [203.199.141.99] by web52208.mail.yahoo.com via HTTP; Fri, 22 Apr 2005 21:42:38 PDT Date: Fri, 22 Apr 2005 21:42:38 -0700 (PDT) From: linux lover Subject: understandable skbuff behavioural problem To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 720 Lines: 19 Hello, I am learning the skbuff workings in kenrel for that I added a fake header in TCP/IP with Fake header containing 2 fields of type int ipchksum and tcpchksum taken frpm upper layer and only copied to new header. I directly push it after IP header is added and thus sending packets to destination pc. At destination side i am able to receive application data(payload) indeed correctly in FTP transfer but how to display those 2 fields in kernel using printk? I am really stuck at this point please help me. Thanks in advance. regards, linux_lover __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From davem@davemloft.net Fri Apr 22 22:20:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Apr 2005 22:20:27 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3N5KOdD010141 for ; Fri, 22 Apr 2005 22:20:24 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPCwr-0006Tg-00; Fri, 22 Apr 2005 22:12:57 -0700 Date: Fri, 22 Apr 2005 22:12:57 -0700 From: "David S. Miller" To: Matt Mackall Cc: jmoyer@redhat.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 4/7] netpoll: fix ->poll() locking Message-Id: <20050422221257.5df9633a.davem@davemloft.net> In-Reply-To: <20050423021440.GZ21897@waste.org> References: <4.454130102@selenic.com> <5.454130102@selenic.com> <17001.31150.194263.732284@segfault.boston.redhat.com> <20050422155218.223fa84d.davem@davemloft.net> <17001.33427.462497.856777@segfault.boston.redhat.com> <20050422155958.474a150c.davem@davemloft.net> <20050423021440.GZ21897@waste.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 325 Lines: 10 On Fri, 22 Apr 2005 19:14:40 -0700 Matt Mackall wrote: > > In such a configuration, how did the netpoll code "tell" who the > > receive packets were for or did it send them to all registered > > netpoll clients for that device? > > It walked a global list of clients. Ok, we definitely need to fix this. From mallikarjuna.chilakala@intel.com Sat Apr 23 09:27:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 09:27:38 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NGRWdD003248 for ; Sat, 23 Apr 2005 09:27:32 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3KI6fdJ018242; Wed, 20 Apr 2005 18:06:41 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3KI65Wl020373; Wed, 20 Apr 2005 18:06:41 GMT Received: from [134.134.3.105] ([134.134.3.105]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042011064027775 ; Wed, 20 Apr 2005 11:06:40 -0700 Date: Tue, 19 Apr 2005 23:05:25 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 11/16] e1000:Removed redundant statement in e1000_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 733 Lines: 17 Removed redundant statement in e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -2436,7 +2436,6 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc->lower.data = 0; tx_desc->upper.data = 0; - cleaned = (i == eop); if(unlikely(++i == tx_ring->count)) i = 0; } From Robert.Olsson@data.slu.se Sat Apr 23 09:57:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 09:57:13 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NGv9dD005592 for ; Sat, 23 Apr 2005 09:57:10 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3NGunZ0003929; Sat, 23 Apr 2005 18:56:49 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 3CF60EE1E9; Sat, 23 Apr 2005 18:56:49 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17002.32337.149675.535048@robur.slu.se> Date: Sat, 23 Apr 2005 18:56:49 +0200 To: Andi Kleen Cc: jamal , Greg Banks , Arthur Kepner , "Brandeburg, Jesse" , netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <20050422183004.GC10598@muc.de> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 340 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: 1787 Lines: 47 Andi Kleen writes: > Well, did you ever test a non routing workload? Well Linux. 2.6.11.7 SMP kernel using one CPU driver e1000 NAPI - no-NAPI. Opteron 1.6 GHz e1000 w 82546GB. Driver sec NAPI no-NAPI ------------------------------------------------- 131072 131072 4 60.00 24.80 25.11 Mbits/sec 131072 131072 512 60.00 941.57 941.53 131072 131072 1024 60.00 941.60 941.61 131072 131072 2048 60.00 941.60 941.61 131072 131072 4096 60.00 941.60 941.57 131072 131072 8192 60.00 941.60 941.61 131072 131072 16384 60.00 941.28 941.60 131072 131072 32768 60.00 941.61 941.27 About the same TCP performance I would say. Now another TCP test... about to deliver TCP even under severe network conditions. Say a big TCP server with many NIC's and one NIC gets DOS'ed. In this case a DoS attack at 820 kpps at a different NIC not the one with the netperf test. (Actually it's doing forwarding at 330 kpps) and at the same time serving TCP, netserver in our case. Driver NAPI no-NAPI ------------------------------------------------- 131072 131072 4 60.00 25.59 N/A 131072 131072 512 60.00 836.79 N/A 131072 131072 1024 60.00 709.65 0.02 131072 131072 2048 60.00 734.34 N/A 131072 131072 4096 60.00 753.99 N/A 131072 131072 8192 60.00 695.57 N/A 131072 131072 16384 60.00 815.50 N/A 131072 131072 32768 60.00 690.33 N/A So even when we are under hard attack we can serve TCP at very decent rates with the NAPI driver. Without NAPI are not able to deliver any TCP service at all. Cheers. --ro From Robert.Olsson@data.slu.se Sat Apr 23 10:14:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 10:14:57 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NHErdD007347 for ; Sat, 23 Apr 2005 10:14:54 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3NHEc6e006367; Sat, 23 Apr 2005 19:14:38 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6F92DEE1E9; Sat, 23 Apr 2005 19:14:38 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17002.33406.419284.821059@robur.slu.se> Date: Sat, 23 Apr 2005 19:14:38 +0200 To: "David S. Miller" Cc: Stephen Hemminger , gnb@sgi.com, hadi@cyberus.ca, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <20050422164301.724343f6.davem@davemloft.net> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> <20050422164301.724343f6.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 341 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: 360 Lines: 15 David S. Miller writes: > With the dynamic schemes comes a new issue, how quickly to respond > to changes in traffic patterns. So true... spoiled months with this to trying to find acceptable mitigation settings for all rates and for all packet sizes. Yes minimal mitigation settings with NAPI is probably the best way to go. Cheers. --ro From hadi@cyberus.ca Sat Apr 23 10:49:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 10:49:13 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NHn9dD010219 for ; Sat, 23 Apr 2005 10:49:11 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DPOki-00035q-7n for netdev@oss.sgi.com; Sat, 23 Apr 2005 13:49:12 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DPOke-0004KN-U2; Sat, 23 Apr 2005 13:49:09 -0400 Subject: Re: Problem with IPSEC tunnel mode From: jamal Reply-To: hadi@cyberus.ca To: Wolfgang Walter Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> References: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> <1114172084.7679.15.camel@localhost.localdomain> <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> Content-Type: text/plain Organization: unknown Date: Sat, 23 Apr 2005 13:49:04 -0400 Message-Id: <1114278545.7669.75.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 342 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: 3886 Lines: 103 On Fri, 2005-22-04 at 15:22 +0200, Wolfgang Walter wrote: > Am Freitag, 22. April 2005 14:14 schrieb jamal: > I'm not sure how packets of tunnels ending at a host are treated exactly. > Probably the tunnel-packet itself is checked against XFRM_POLICY_IN because > its destination is the host itself. Then it gets decrypted if an entry > appropriate in the sad in (dst,spi) exists. The inner packet gets extracted > and decrypted and is then rerouted. > > I think it is like that because > > * you see those packets twice in PREROUTING (mangle) i.e. for an esp-tunnel: > first as esp-packet than the inner decrypted packet. If the inner packet is > to be routed, XFRM_POLICY_FWD is relevant, otherwise XFRM_POLICY_IN. > Indeed, you are correct. So to summarize, 1) for incoming packets: ->If encrypted: the SAD is consulted based on the header. Infact if you have an onion of encryptions, then they will all be peeled first if appropriate. ->If packet determined to be local, XFRM_POLICY_IN is used for checking. ->If packet determined to be forwarded, XFRM_POLICY_FWD is consulted; packet may be dropped if failure else forwarding XFRM_POLICY_OUT is used to determine the SA bundle to be used if action is to encrypt. [This is why i was asking whether FWD and OUT should look similar - why check FWD then use OUT? I didnt quiet understand Patricks answer]. 2) for localy generated packets -> XFRM_POLICY_OUT is both consulted for checking and used to determine SA bundle to use. > But maybe XFRM_POLICY_IN is bypassed for ipsec-packets. > ipsec packets essentially should never see XFRM_POLICY_IN from what i am gathering until after theyve been decrypted and are determined to be local. > I didn't try out transport-mode. > Should be no different. You should see (in tcpdump for example) first then encypted packet then the decrypted one. I havent tried it though. > Packets to be routed which are still encrypted here are ipsec-packets which > are not destinated or originating from this host. Of course they may came in > via a tunnel ending at this host: > > a<--->N1<--->b<----ipsec-tunnel--->c<--->N2<--->d > > If a communicates with d via esp (tunnel or transportmode) and b and c tunnel > all packets between network N1 and N2 via ipsec then, on c, a ipsec packet > from a to d would come in via the tunnel packed into another ipsec packet, is > extracted from the tunnel packet and is routed to d if XFRM_POLICY_FWD allows > esp packets from a to d and XFRM_POLICY_OUT allows unencrypted communication > between c and d for esp-packets from a to d. > So to allow pass-through of esp packets from a<->d at c, you will have to essentially create special policy rules (at FWD and OUT) to basically just allow if src/dst = a/d, correct? > spdadd 192.168.2.100 192.168.3.10 any -P in ipsec > esp/transport//require > ah/transport//require; > > installs both in and fwd rules (in RFC-mode). What is "RFC mode"? > Use option -k for only setting in rules (RFC only knows IN and OUT rules). > This behaviour was added to > ipsec-tools. As far as I know earlier kernels had a bug and didn't check fwd > ruleset so that setkey and racoon worked by accident under linux. > > > racoon now behaves like pluto: it inserts always in and fwd rules. Its easier > than to check if a in or fwd rule or both is needed. > I think i am still lost on the desire to have the FWD database. Unless we are trying to use SPD for firewalling? > And no, we do not use setkey any more but ip xfrm (though setkey displays more > information, i.e. it tells you if a policy is socket-specific). Should be fixable in ip xfrm .. > Reason is > that neither setkey nor racoon can handle large rule sets. And for most fwd > rules we also set an in rule (as pluto does). > Do you know why pfkey doesnt scale? Herbert? cheers, jamal From Robert.Olsson@data.slu.se Sat Apr 23 10:54:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 10:54:36 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NHsVdD010972 for ; Sat, 23 Apr 2005 10:54:32 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3NHsDr0011526; Sat, 23 Apr 2005 19:54:14 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id CE739EE1E9; Sat, 23 Apr 2005 19:54:13 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17002.35781.813292.517029@robur.slu.se> Date: Sat, 23 Apr 2005 19:54:13 +0200 To: Stephen Hemminger Cc: "David S. Miller" , gnb@sgi.com, hadi@cyberus.ca, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <20050423125153.65189ea0@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> <20050422164301.724343f6.davem@davemloft.net> <20050423125153.65189ea0@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 343 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: 1073 Lines: 26 Stephen Hemminger writes: > One of the problem with the dynamic schemes, is there is no generic infrastructure > to support it. There are some drivers that have tried dynamic schemes > but each seems to reinvent some adhoc scheme. Seems like a good area > for future research. Well how do decorrelate bursty network and more interesing at what time level? I said this before... the only useful measure for mitigation setting was packets on RX ring. > Another related problem is some drivers use NAPI for both TX and RX and > this can cause asymmetric behavior and scheduling issues. The whole > dev->weight limit stuff assumes RX not TX usage of NAPI Well in the very beginning it was thought only RX yes, But it is possible also to have TX buffer cleared etc in the ->poll routine to simplify intr. acking. As implemented only RX packets updates the budget. From what I see in real life use this works well. Guess you noticed the tests with e1000 and TCP just posted. Anyway MSI will give us some new options in this area.. Cheers. --ro From davem@davemloft.net Sat Apr 23 11:03:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 11:03:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NI3PdD012120 for ; Sat, 23 Apr 2005 11:03:26 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPOnv-0002eM-00; Sat, 23 Apr 2005 10:52:31 -0700 Date: Sat, 23 Apr 2005 10:52:31 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: wolfgang.walter@studentenwerk.mhn.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: Problem with IPSEC tunnel mode Message-Id: <20050423105231.082041f3.davem@davemloft.net> In-Reply-To: <1114278545.7669.75.camel@localhost.localdomain> References: <200504221342.10675.wolfgang.walter@studentenwerk.mhn.de> <1114172084.7679.15.camel@localhost.localdomain> <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <1114278545.7669.75.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 283 Lines: 9 On Sat, 23 Apr 2005 13:49:04 -0400 jamal wrote: > Do you know why pfkey doesnt scale? Herbert? It does no queueing, pfkey responses are generated in one huge atomic send back to the application's socket. It's just like BSD routing sockets, very poorly designed. From Robert.Olsson@data.slu.se Sat Apr 23 13:50:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 13:50:30 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NKoOdD027351 for ; Sat, 23 Apr 2005 13:50:25 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3NKo82V001333; Sat, 23 Apr 2005 22:50:08 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 3AB80EE1E9; Sat, 23 Apr 2005 22:50:08 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="xrptmDWBB9" Content-Transfer-Encoding: 7bit Message-ID: <17002.46336.122897.957854@robur.slu.se> Date: Sat, 23 Apr 2005 22:50:08 +0200 To: "David S. Miller" Cc: hadi@cyberus.ca, ak@muc.de, gnb@sgi.com, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com, Robert.Olsson@data.slu.se Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <1114197689.7978.68.camel@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <1114196487.7978.65.camel@localhost.localdomain> <20050422120714.35f56e76.davem@davemloft.net> <1114197689.7978.68.camel@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 346 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: 244056 Lines: 3197 --xrptmDWBB9 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Well remember I did some CPU-measurements with different variants of the tulip driver long time ago while discussing this with Manfred. Yellow: NAPI no intr. mitigation Red: old HW-Flow w. intr. mitigation Blue: NAPI w. intr. mitigation Purple: A tulip variant doing all work in ->poll w. intr. mitigation Your coalicing patch for tg3 should roughly be like moving from the yellow to the purple line. I'll guess we soon got the answer... Maybe I have to upgrade the lab with some recent broadcom cards too. --xrptmDWBB9 Content-Type: image/gif Content-Disposition: inline; filename="NAPI-overhead.gif" Content-Transfer-Encoding: base64 R0lGODlhgALgAfIFAAAAAACqqqoAAKoAqqqqAP///wAAAAAAACH5BAAAAAAALAAAAACAAuABAAP+ CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIBQAFAIUFWFAFBVWAAAgAAAUFhVAIAFAAUIAACAAAAACAAAgAAAAAgAAIAABQAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFBYAACAAAAACFAAgABQAAgA AIAAAAAIAACAAAAAWFUAgFVVAAgFAIUAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAAWAUAAFCAUAhQAA AAgABYBQAAUIUACAAAAACAAAgAAAAAgAAIAAAFAIBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAX+AAAIAACAAAAACAAAgAAAAAgABYBQAAUIUACFAFAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAAAAAIAACAAAAACAAFgFAAUAhQAIUAUAAIAACAUABQCAAFhQAAAAgAUIBVAABYVQCA BVUACAAFgABQVQgABYUFAFUIBQCAVQUAWFAFgABVBQgAVYUAAAAIAFCAVQAAWFUAgAAFAAhQVYAA VVVYAFCFAAAFCFAAgFUFAAgAAIBQAAAIUACABVAACAUAgAAAUAgABYBQVQUIUFWAAFAFWABQhQUA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAUAgA BYAFUFVYAACAAABQWFUAgAAFAAgAAIAAVQBYAAWAUABVCFAAgFUFAFgAUIBQBVAIUFCABQAACAVQ hQAFUAgABYAFAAUIAACAAFUAWAAFgFAAAFgAAIAAUAAIUACAAFAACFAAgAVQAAgFAID+AABQCAAA gFVVAAgFAIUAAAAIAAWAUAAFCAAAgABQAFgAVYBQAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAFAIAAWAUAAFCAUAgAAAAAgABYUAAFAIBQCAAAAA WABQgFBVVQhQAIAAAFAIAFCAAAVQCAAAgAUFBQhQVYUABQBYAAWAAABVWFUAgAAAAFgAAIBQVVUI AFCAAABVWAUAgAUAAAgFAIAFAAUIVVWFAAAACAAFgAAABQgAAIUAUAAIAACAUABQCABVhQAAVVgF UIAABVBYVQWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAWAUABQCFAAhQAAAAgAAIBQAAUIUACABQAACABQhQAFUAgAAIAFAAAIAAWAAAUAWAAFgAAA BVhQAIUAUABYAFCAUABQCFAAgAAAAAgAUIAAAFAIAACAAAUACAUAhQAABVgAAIUAAFAIBQCFAAAA CAAAgFAAUAhQAIAAUAAIBQD+gAAAUAhQBYAAAAUIBQCFAAVQWAAFgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAFUFCFBVhQD+UAAIAACAAABQCAAF gAUABQgAAIAABVUIAFCFBQAFCAAAgFAAAAhVBYBQAAAIUFCABQBVWAVQgAAFAFhVAIBQVQAIAACA AAUACABQhQUAUFgFAIBVVQAIAAWAAFUFCABQgAAAVVgAAIAAAABYVQCABQAACFBVgAAAAAgAUIVQ AFVYBQCAVVUACFVQgABVBQgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+UIAABQAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAID+AAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAUFUIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUFgFAIAAAAAI AAWAAAAACABVhQAAVVgAAIAAAAAIAACAAAAACFBVgAAAAAgAUIUFAAUIUACFVQUACAAAgFBVBQgA VYUAAFVYAACAAAAAWFUAgAAAAAhQVYAAVVVYAFCFBQAACAAAhQBQAFgAUIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAhQAIAFAAAIAACAVQAACAAAgAUABQgFAIUAAAAIAACAAAAA CAD+AIUAUAAIAACAUABQCFAFhQVQAAgFAIAAAFAIAAWAAAUACAAFgAAAAAgABYBQAAAIAACFAFAA WAAAgFAAUAgAAIAAUAVYBVCAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAFCAAAgABQUAgAAIAAAAAIUACFAFUAWFAFgFBQBQgAVYUAAAAIBQCAAABQCAAAgAUFBQgFAIUA AAAIAAWAUAAAWAAAgFAAAAgAAIAAAFAIUACABQAACAVQhVUAUAhQBYAAAAAIBQWFAAUAWABVhVUA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQWAUAgAAAAFgABYAAAAAIAFWFAFBQCAVQ hQAFUFgABYAFAAUIUFWAAAAACABQhQUABVj+UACFVQUACAAAgFBVBQgAUIAAAFAIAACAAAAAWFUA gFBQAAgAVYAAAABYAAWFUAAACAAAhVBQAFhVVYAAAAUIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAhQAIAAAAAIAFCFVQUACAAAgAUAAAhVAIUABQBYAAWAAABVWFUAhQAAAAgAAIAAAFAI UACABVAACAAAgAAAUAgAAIAABQAIAAWAAAAACAAFgAAAAFgAAIAAUAAIAFCAUAVQCAAAgABQAAgF UIAABQAIBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAAAIUAWAAABQCABQhQAA BQgAAIUAUABYBVCAUAAACFAAgABQAAgAAIAAAFAIAAWABQAFCAUAgAAAAAgABYAAAAD+WAAAgFAA AAgAAIBQAAAIAAWFAFAACAVQgAAFUAgABYAAAAAIBQCFAAUAWABQgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAABVWFUAgFUAAAgABYAAVQAIUFWFBQBVWABQgFUAUAgAAIBQVQAIVVWF AAAACABQhQUABQhQAIUAAAAIAACAUAAACABVhQAAVVgAAIAAAFBYVQWABQAFCFBVgABQVQgAUIUF AAAIAACFAFAAWABQgFBVVQgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACFAAAACAAAgFUAAAhQAIAAAAAIAACAAAAACAUAgAAAAAgF AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIVVAABYVQCAUFUACAAA gAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgABQ AAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIUAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAUAWAAAhQAABQhQAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUFhVBYAFAAUIAAWAAFAFCAAFhQUAAAgAAIBV UABYUAWAAFUACFAAgAUAVVgAUIBVAABYVQWAAAAACAUAhQBQVVgAUIUFAFBYVQCAAAAAWABQgABQ AAhQAIAFAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAD+AAAIAACFAAAFCFAAgFAAAAhQAIBQBVAIAACAAFAAWAVQhQAFAAgFAIAFAAUIBQCFAFUAWAAF gAAAAAgAAIUAUABYAACAUABQCFAAgAAAAAgAUIVVAAAIBQCABQAFCAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAFAACFAAgAUAUAgAAIAFAFAI AAWAAAAACAUAhQAFAAgAAIUAAAUIUACFVVUAWAAAgABVBQgAAIAAUAAIBQCFVQBQWFUFgFBVAAgA AIAABQAIAACFAAAFCFAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+ AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAUFgAVQBQgABYD+AAAFCABVgFAAAAgAAIUAVQBYAACAAFAACAAFhQBQ AAgAUIAAAAAIAAWAAAAACAVQhQAAAFgABYAAAAAIUACAAAAAWAAAgABQAAhQAIAFAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAFBYUACA VQUACFUFgFBQBQgAAIAAAFUIBVCAAAAAWFUAgAAFAAhQVYAABQAIAFWFBQAACAAAgFVQAFhVBYAA VQUIUFWFAAAACABQgAAAAFhVAIBQVQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAAD+gAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAUFUACFBVgABQVQgA UIUFAFBYBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAFCFAAhQBQAFgAUIBQAFAIUACABQAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFD+AIAF UABYBVCAUAVQCFAFgAVQBQgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQVQUIBQWFAAUFWAAFhVAABVhQAIAAAFBYVVWF VVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVV VVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVX+VVhVVYVV VVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVV VVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVV WFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVY VVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVQUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIUACFBVAAWAVQgFAFUAj+UAWABQAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIUAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAUIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAA AAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhQBQAAgFUIAABVAIAAWABQAF CAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAD+AAAIAACAAFAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACFAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgFAFAAhQVYAAUFUIAFCFBQBQWAUAgAAAUAgAAIAAAAD+CAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAUAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAUAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAD+AIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhQAAAAgAAID+AAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAUIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgA AIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAUAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAKAAAAACAAgggAAACgAAIAAAAAI AACAIAAgCCAAgAIAAAgAIIIiAiAIAACAICIACAIAggAAAAgAAoAgACAoAgCCIiIACCICgAAAAAgA AIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgCAAAAgAAIAAIAAIAACAAAAACAAAgAAAIAgAAoACAAIIAACAAAIACAACgAAA AgggAIIAIAAIAACAIAIiCAAggAAAIAgAAIACAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgIigCIIAAAgAIAgCA IAIACAIigAAAAAgAAoAgAAIIIACAAAAAKAAAgCAAAAggAIACIAAIAgCAAAAgCAICgAACAAgAAoAA AAIIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+ AACAAAAACAAAgAAAAAgAAIAAAAAIAAKAAAIAKAAAggAAACgAAIICIAAIAACAICIiCCAAgAIAAAgA IIICACAIAACAAgACCAIAggAAAAgAAoIgAAAoAACAIAAACCAAgAAAAAgiIoIiIiIoIiKCIiIiKCIi giIiAggAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAIAAA KAAggAAgAAgAIIAAIAAIAgCAAAAgCAACgAICAggAAIAAAgAIAAKAAAACCCAAgiAgAAgAAIAgACAI ACCAAAAgCAAAgAIAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAD+AAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAIAgCIIAgAgAIAgCAAAIACCIAggAAAAgAAoAg ACIIIgCAAAAAKAAAgCAAAAggAIACIAIoAgCAAAAgCAACgAACAAgAAoAAAAIIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAIIAAIAIoACCCAgAgKAIAgiACAAgAAIAgACAIIACAAgAACAAggAAAICgiAoAgIgAIAgCC AAAACAACgCAAICgCAIAgAAAIIgKAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAA AAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAIAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAgCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAI AACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAD+AIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAABAAgAAIAAEAEIAACBAAAACAAAgAAAABgAEID+ABAACBARgQAAERgAAIAAABAI AAGAEBEACBERgQAQEQgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAYAACAAAAACBAAgAAA AAgAAIAAAAAIABCBAAEAGBAAgAEAAQgAAYAAAAAIABGAEQAAGAAAgBAAAAgQAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIEBGBARAACAEAgAEAABgBAIABEQAIAACAAAEBGAABgBAAAQgQAIAQ AAAIAAD+gBAQEAgAEIAAABAIAACAAQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA UAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAABAAgB AIEAAAEIAACBAAARCBAAgRERABgAEYAQABAIEBGBAAAQCAAAgAAAEAgBAYAAAQAIAAGAAAABCAAA gAAQERgREYEREREYERGBERERGBERgQEAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAABgAAIEAEAAIEACAABAACBAAgAEAAAgAEIAAARAY EQGAAQAACAABgAAAAAgAAYAQAAAYAACAEAAACBD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+ AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIABCAARAAGAEAgAEAAAgBAIARAAEIAACAAAEAGAABgBAAAQgAAIAQAAAIAACAEAAQCAAQgAAA EAgAAIABAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAABAACBABgQAQEQgAEIEBAAEYAQCA AAAAGAAQgBAAEAgQAIAAABEYAACAAAAQCAABgBARAAgAAYAAEBEIAACAAAAACAAAgAAAAAj+AACA AAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACBAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAEAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAD+CABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAF AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAwAI AACAADADCAAAgwAAAAj+AACAAAAAOAAwgAAwAAgwM4MAADM4AACAAAAACAAAgDADAAgwA4AAAAAI AACAAAAwOAAAgDMAAAgAAIAwADAIADODADAzOAMAgzMAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAOAAAgAAAAAgwAIAAAAAIAACAAAAACAAwgwAD ADgwAIADAAMIAAOAAAAACAAAgAAAADgAAIAwAAAIAACAAAAACAAwgAAAMAgAAIAAADA4MAOAAAMA CAADgAAAAwgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACDAzgwMwAAgDAIADAAA4AwCAAzMACAAAgAADAzgAA4AwAAP+CDAAgDAAAAgAAIAAMwMIADCA AAAwCAAwgDMAADgzAIAAAwAIAAOAAAAACAADgzAAADgAAIAwAAAIMACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAwAIAwCDAAADCAAAgwAAMwgw AIMzMwA4ADOAMAAwCDAzgwAAMAgAAIAAAAAIAAOAAAMACAADgAAzADgAA4AwAAA4AACAMAAACAAA gDAwMAgAMIAAADAIAACAAwAACAAAgzMzMzgzM4MzMzM4MzODMzMzODMAgAAAAAgAUIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAFAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAA4AACDADAACDAAgAAwAAgwAIADAAAIADCAAAMwODMDgAMAAAgAA4AAAAAI ADCDMwD+ADgAAIAwAAA4ADCAMAAwCAAwgAAAMAgAAIAAADAIAAOAAAMACAADgAAAAwgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAwgAMwADgDAIAD AAAIAwCAMwADCAAAgAADADgAA4AwAAMIAACAMAAACAAAgDAAMAgAMIAAADAIADCDAAMwCAADgAAD AAgAA4AAAAAIAAOAMAAAOAAAgDAAAAgwAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA WAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAD+gFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAwAAgwA4MAMDMIADCDAwADOAMAgAAAADgAMIAwADAIMACA AAAzOAAAgAAAADgzA4AwMwAIMDOAAAMzCAAwgwP+ADA4AwCAMwMACAAAgDAAMAgAM4MAADAIAACD MwAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+ CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgwAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAADgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgABYAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIADAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAMIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAQAgAAIAAAABIBACAAAQACAAAgAAAAAgABIBAAABIAACERAQACEQEgAAAAAgA AIAAAAAIAACAAAAECAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAVYUAAFVYAACFVQAAWFUAgFBVAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABIAAAAAIAACEAAAA KCIiggIAAAgAAIBABEAIAASEAEAACBQBgAQAAAgAAIAAAAAIAACAAAAACAT+AIAAAAAIAACAAAAA CABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACABQAFCAUAhQAFAFgABYBQAAUI UACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACEREQASABAgABAAAgARIAAQEBIAACAAABACAQEgAQABAgEEYQB AAQIAACAADMzCAAAgAAAAAgAQIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAFCFAAhQBVAFgAVYBQAFUIUACFBQAACAAFgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACABA gAAEAAgEAIAABCAoRACEAERESAAEgEQABAhAAIREBAAIQACAAAAAOEREhEREREhERIRERERIRESE REQECAAAgAAAAFj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAVYUAUFAIBVCA BQVQCAUFgAUFBQgAAIBQVVVYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABIAABABIAACEAAAASCAAhABAAAgAAIBAAEAI QESEFEERCAAAgAQAAAgAA4AAAAAIAACAAAAECAAAgAAAAAgAAIAAAFBYVVWAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAAUIVQCFAFUAWABVgFAAVQhQAIAAAFAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIBAQABIAESAAEAACABAggBABAgEAIAAAEAIAASABBAUCAQAgAAABAgAAIMDAAAIAACAAAAA CAQAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAF CFAAhQBQAFgAUIBQAFAIUACABQAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAASAAAhAQEAEhEAIBARAAIBESA AAAACAAEgEAAFBhBEIQAAAAIRASAAAMACAAAgAAAAAgAQIAAAAAIAACAAAAACAAAgAAAAFgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABVhQAAVVgAAIVVAABYVQCAUFUACAAAgFAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACIIAACEAAAACAAAgAAAAAgQAYARAAAIAACAAAAwCAAA gAAAAAgAAIBAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAIAgABAAAgAAIAAAAAIAACAABAACAAAgAAAAAgzAIAAAAAIAACAAAAECAAAgAAAAAgAAIAAAAAI AACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAggAAAAAgAAIAAAAAIAACAAAAQGAAAgAAA AAgAMIAAAAAIAACAAAAACEAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAgAAAIAACAAAAACAAAgAAAAAgQAIAAAAAIAACAMwAACAAAgAAAAAgAAIQAAAAIAACA AAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAIAIIAACAAAAACAAAgAAAAAgA AIEAAAAIAACAADAACAAAgAAAAAgAAIAABAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYD+AAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAoAACAAAD+AAgAAIAAAAAIAACAEAEACAAAgAAAMDgAAIAAAAAIAACAAABA CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAACgAAAAAgAAIAA AAAIAACAAAABCAAAgAAAAAgwAIAAAAAIAACAAAAACEAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQ CAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAggIAAAgAAIAAAAAIAACAAAAACAEAgAD+AAAIAACDAAAACAAA gAAAAAgAAIQAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAI AACAAAAACAAAgAAAAAgAEIAAAAAIAACAMAMACAAAgAAAAAgAAIAABAAIAACAAAAACAAAgAAAAAgA AIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAACAAAgAAAAAgAAIARAAAIAACAAAAD CAAAgAAAAAgAAID+AABACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACCAAgAAAAAgAAIAAAAAIAACAABAACAAAgAAAADgDAIAAAAAIAACAAAAACEAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAgggAAAAgAAIAAAAAIAACAAAAAGAAA gAAAAAgAA4AAAAAIAACAAAAACAAAhAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAABYAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAgAAAIAACAAAAACAAAgAAAAAgAAYAAAAAIAACDAwAACAAAgAAAAAgAAIAABAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAIIAACAAAAACAAAgAAA AAgAAIEBAAAIAACAAAMACAAAgAAAAAgAAIAAAEAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUA CAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAIAgAAAAAgAAIAAAAAIAACAAAEACAAAgAAAMwgAAIAAAAAIAACA AAAACEAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAigAAAAAgA AIAAAAAIAACAAAAQCAAAgAAAAAgDAIAAAAAIAACAAAAACAAAhAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIACAAAIAACAAAAACAAAgAAAAAgQAIAAAAAIADCAAAAA CAAAgAAAAAgAAIAAQAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA IAAIAACAAAAACAAAgAAAAAgAEIEAAAAIAACAMwAACAAAgAAAAAgAAIAAAABIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAAKAAAgAAAAAgAAIAAAAAIAACAEAAACAAA gAAwAAgAAIAAAAAIAACAAAAACAAEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACCACgAAAAAgAAIAAAAAIAACAAAABCAAAgAAAMDgAAIAAAAAIAACAAAAACAAAgAQAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAggAAAAj+AACAAAAACAAAgAAA AAgBAIAAAAAIMACAAAAACAAAgAAAAAgAAIAAQAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA WAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAAAgAEIAAAAAIADCDAAAACAAAgAAAAAgAAIAA AABIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAD+AAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAACAAA gAAAAAgAAIARAAD+CAAAgDAAAAgAAIAAAAAIAACAAAAACAAEgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACCIAgAAAAAgAAIAAAAAIAACAABAACAAAgAAAAwgAAIAAAAAI AACAAAAACAAAgAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAA gAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAggAAA AAgAAIAAAAAIAACAAAAAGAAAgAAAADgDAIAAAAAIAACAAAD+AAgAAIAAQAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAgAAAIAACAAAAACAAAgAAAAAgAAYAAAAAIAAOA AAAACAAAgAAAAAgAAIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAIIAACAAAAACAAAgAAAAAgAAIEBAAAIAACDAwAACAAAgAAAAAgAAIAAAAAIAECAAAAACAAA gAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAKAIAgAAAAAgAAIAAAAAIAACAAAEA CAAAgAADAAgAAIAAAAAIAACAAAAACAAAgEAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+ AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAACgAAAAAgAAIAAAAAIAACAAAAQCAAAgAAAMwgAAIAAAAAIAACAAAAACAAAgAAA BAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIACAAAIAACAAAAACAAA gAAAAAgQAIAAAAAIAwCAAAAACAAAgAAAAAgAAIAAAAAIQACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAIgAIAACAAAAACAAAgAAAAAgAEIEAAAAIADOAAAAACAAAgAAAAAgA AIAAAAAIAACEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAAD+gAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAgCAAAgAAA AAgAAIAAAAAIAACAEAAACAAAgAMAAAgAAIAAAAAIAACAAAAACAAAgAAEAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAAAABCAAAgAAwAAgAAIAA AAAIAACAAAAACAAAgAAAQAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAA AAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgA AIIAAAAIAACAAAAACAAAgAAAAAgBAIAAADA4AACAAAAACAAAgAAAAAgAAIAAAAAIAASAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAgAgAIAACAAAAACAAAgAAAAAgAEYAAAAAI MACAAAAACAAAgAAAAAgAAIAAAAAIAACABAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgA AIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAIIAAD+gAAAAAgAAIAAAAAIAACAAQAACAAwgwAAAAgAAIAAAAAIAACAAAAACAAAgABA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAIAgAAAAAgAAIAAAAAIAACA ABAACAAAgDAAAAgAAIAAAAAIAACAAAAACAAAgAAAAEgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAVVUFCFBVgABQ VQgAUIUFAFD+WAUAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAggAAAAAgAAIAAAAAIAACAAAAAGAD+AIAAMAMIAACAAAAACAAAgAAAAAgA AIAAAAAIAECAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhQAIUAUABYAFCAUABQCFAAgAUAAAgABYAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAiAAAIAACAAAAA CAAAgAAAAAgQAYAAAAA4AACAAAAACAAAgAAAAAgAAIAAAAAIAACAQAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIUAUABYBVCAUAVQCFAFgAVQBQgAAIBQAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAIAAIAACAAAAACAAAgAAAAAgAAIEAAAAIMAOAAAAACAAAgAAA AAj+AACAAAAACAAAgAAABAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAUFhQAFBVgABYVQAAVYUACAAABQ WFVVgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAKAAA gAAAAAgAAIAAAAAIAACAAAEACAAAgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgEAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABVhVUFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAABQCAAAhQVQAFgFUIBQBVAIUAWABQAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAACgAAAAAgAAIAAAAAIAACAAAAQCAAAgAADAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIQAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhQAIAAUAAIBVCAAAVQCAAF gAUABQgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIICAAAIAACAAAAACAAAgAAAAAgRAIAAADMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAQA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAFAAAIUFWAAFBVCABQhQUAUFgFAIAAAFAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAAAgAEIAA AAAIAwCAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAA AAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAgCAAAgAAAAAgAAIAAAAAIAACAEAAACAAzgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgABIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAI AACAAAABCAAAgAMAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAEAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAD+AAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAIIIAAAAIAACAAAAACAAAgAAAABgBAIAAMwAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAEAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAgAAAIAACA AAAACAAAgAAAAAgAAYAAADAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAASAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAACCAAAgAAAAAgAAIAAAAAIAACAAQAACDAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAQIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAIAgAAAAAgAAIAAAAAIAACAABAACAAwgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAigAD+AAAIAACAAAAACAAAgAAAEBgAAIAw AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAECAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIACAAAIAACAAAAACAAAgAAAAAgQAIAAMAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAQAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAUAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAIAAIAACAAAAACAAAgAAAAAgA AIH+AAAAOAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIQAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAAKAAAgAAAAAgAAIAAAAAIAACAAAEACDADgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAABAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABY AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+ AACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCACgAAAAAgAAIAA AAAIAACAAAAQCAAAgwAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAABACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIIAAAAIAACAAAAACAAAgAAAAAgRAIAwAwAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACEAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAFgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAI AACAAAAACAAAgAAAAAgAEIAAAAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAEAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAiCAAAgAAAAAgAAIAAAAAIAACAEAAACAMAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAQAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAIAgAAAAAgAAIAAAAAIAACAAAABCAAzgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AABIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIIAAAAAIAACAAAAACAAAgAAAABgB AIADAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAEgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAgAAAIAACAAAAACAAAgAAAAAgAAYAAMwAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgEAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAI AFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAACACCAAAgAAAAAgAAIAA AAAIAACAAQAwCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAQIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAAKAAAgAAAAAgAAIAAAAAIAACAABAACDMAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAD+AFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAoAAAAAI AACAAAAACAAAgAAAEBgAMIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIACAAAIAACAAAAACAAAgAAAAAgQAIAwAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAEAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA IgD+CAAAgAAAAAgAAIAAAAAIAACBADADCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AEAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAgCAAAgAAAAAgAAIAAAAAIAACAAAEAOAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIQACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+ AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACCAAgAAAAAgAAIAAAAAIAACAAAD+EQgwA4AAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIAAAAIAACAAAAACAAAgAAA AAgBAIMAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgABAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAAAgAEIAwAwAIAACAAAAACAAAgAD+AAAIAACA AAAACAAAgAAAAAgAAIAAAABIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAgCAAAgAAAAAgA AIAAAAAIAACAEAADCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAASAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+BYAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAABABOAMAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAID+AAAACAAAgEAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIA AAAIAACAAAAACAAAgAAAABgAA4AAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA BAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAI AACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAAAgAAYADAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgEAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAgCAAAgAAAAAgAAIAAAAAIAACAATMACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAECAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAABEw CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAQACAAAgAAAAAgAAIAAAAAI AACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIIAAAAIAACAAAAACAAAgAAAEAgzAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAQAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAA gAAAAAgQMIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAFgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAD+gAAAAAgAAIAAAAAIAACAAAAgCAAAgAAAAAgAAIAAAAAIAACBMwAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAA AAgAAIAAAAAIAACAEDEACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAEAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQD+ CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIIAAAAIAACAAAAACAAAgAAAATgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAEgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAFCFAABVWAAAhVUAAFhVAIBQVQAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAgAIAACAAAAACAAAgAAAAAgxA4AAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgABIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACABQgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgFAAAAgFAIUABQBYAAWA UAAFCFAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAACAAAgAAAAAj+ABCDAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAQAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAABQgAAIUAVQBYAFWAUABVCFAAhQUAAAgABYAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAMAMACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAECAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIUFWFAFBQ CAVQgAUFUAgFBYAFBQUIAACAUFVVWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAggAAAAgAAIAAAAAIAACA ABADCAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgEAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQWFVVgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACABQAFCFUAhQBVAFgAVYBQAFUIUACAAABQCAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAABgDAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAQIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAFCFAAhQBQAFgAUID+UABQCFAAgAUAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAA CAAAgAAAAAgAM4AAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAQA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABY AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAVYUAAFVYAACFVQAAWFUAgFBVAAgA AIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAAwAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAAD+gAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA ggAAAAgAAIAAAAAIAACAADEACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACEAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAACAAAgAAAMDgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIQAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACA AAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAACAIAACAAAAACAAAgAAAAAgwAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAQAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACD AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAASAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAggAAAAgAAIAAAAAIAACAEAMACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAA CAAAgAAAMwgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAEAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA UIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAACAAAgAAAAAgDAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAQIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACCAA gAAAAAgAAIAAAAAIADCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAQAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAggAAAAgAAIAAAAAIAACAMQAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAj+AACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAACAAgAAIAAAAAIAAD+gAAwAwgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIBAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAACAAAgAAAEDgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAEAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAA CAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIICCCAAAACAAAgAAAAAgwA4AAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACEBEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgiIgAAgAAIAAAAAI AACDAwAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAQAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAA gAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAggAIAAAAAIAACAADMACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAARAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AgAACAAAgAAAMDgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AEAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAD+AAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAgCAAAgAAAAAgAMIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CEAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAoAAAAAIAACAMAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAhAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAxCAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAEAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAAKAAAgAAAAAgxAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAEAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAggAAAAgA EIADAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIRACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAIAAIAACAEDAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACABAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAVQgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIIACAAAAQOAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgEAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAA AAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIBQWFAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAIAAAgQMIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAQIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAA AAAIAACFUFAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAIAgAAIEwAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAD+gAAAAAgAUIAAAAAIAACAAAAACAAAgABQUAgFAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIACCAAAEwCAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAI AACAAAAACAAAgAAAAAhQVYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA BYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAACAQCDAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgEAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACBAA gAMAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAQAQIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAhMwAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAABIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAVQ gAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAEDMoAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAEgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIUAUAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAgGDMDggAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAA AAgAAIBQVVVYAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACDIzgwAiAggAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+ AIAARAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAUAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAggMoMAEAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAEQIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgA AIAAAAAIAACAAAAACAAAhQAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgA AIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAIIIAAwAIAQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAABIBACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACCIgAAOAAA gQAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACEAEgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAWAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAIAIACAAwgAAQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACABAhAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAA gFVVAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAg AggAAIAAAwAYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBEAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgABQUAgFAIAAAAAIAACAAAAACAAAgFVVBQhQ VYAAUFUIAFCFBQBQWAUAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAIigAAIAAAAAIAxCAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAARAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAA AAgAAIAAAAAIBQWFAAAACAAAgAAAAAgAAIAAAAUIAACFAFAAWABQgFAAUAhQAIAFAAAIAAWAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgA AIAAAAAoAgCAAAAACAAAgwABAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACFUFAACAAAgAAAAAgAAIAA AAAIUFWFAFAAWAVQgFAFUAhQBYAFUAUIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIIgKAAAAACAAAgAAwABgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACEQAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgA UIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAABQgFBYUABQVYAAWFUAAFWFAA gAAAUFhVVYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAD+CAAigAAAAAgAAIAAAAAIAxCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgARIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAVYVVBQAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAhQAIUFUABYBVCAUAVQCFAFgAUAAAgABYAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAgggIAAAgAAIAAAAAIAACD EAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIQEAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAID+AAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUACABVAACAVQgAAF UAgABYAFAAUIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgCIAAAgAAIAAAAAIAACAADD+EAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAQACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACA AFUACAUAgAAAAAgAAIAAAAAIAACAUFUACFBVgABQVQgAUIUFAFBYBQCAAABQCAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAgIgAIAACAAAAA CAAAgAAAAAgDAYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABECAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAAD+gAAAUAhQUIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAIAIIAACAAAAACAAAgAAAAAgAAIMQAAAIAACAAAAACAAAgAD+ AAAIAACAAAAACAAAgAAAAEgEAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAA CAAAgAAAAAgABYBVAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAiKAAA gAAAAAgAAIAAAAAIAACAADAQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhABIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIBQAAUIAACAAAAACAD+AIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAKAIAgAAAAAgAAIAAAAAIAACAAAAACDAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIT+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAFAAgAAIAAAAAIAACAAABQWFVVhQAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAggAoAAAAAIAACAAAAACAAAgAAAAAgAAIADAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAQAQA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIoIAAAAIAACAAAAACAAAgAAAAAgAAIAA AAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAEAECAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACCAgAACAAAgAAAAAgAAIAAAAAIAACAAAAACDAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAQEgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAFgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAIgIACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAMAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhEAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAiAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAEAMIAACAAAAACAAAgAAA AAgAAIAAAAAIAECAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgA AIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgIggAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIMQCAAAAACAAAgAAAAAgAAIAAAAAIAACARAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAFgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAD+gAAAAAgAAIAAACAoAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgQMAAAgA AIAAAAAIAACAAAAACAAAgABEAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAUFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAoIgCAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAQAwgAAIAAAAAIAACAAAAACAAAgAAARAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgA AIAABQVYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIIAKAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAQOAAAAACAAAgAAAAAgAAIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAABYUFCAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAg ggAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIABCAMAAACAAAgAAAAAgAAIAAAAAIAESA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAA AAAIAFWFVVUACAAAhQAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgiIAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+ AACAAAAACAAAgAABMAgAAIAAAAAIAACAAAAACAAAhAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAFWAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAgAgAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAABgAA4AAAAAIAACAAAAA CAAAgEAEAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+BQAI AACAAAAACAAAgAAAAAgFAIUAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA BYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAIgIIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAEIAwAAD+CAAAgAAAAAgAAIAAAAQIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIUAUAAIAACFVQAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAiCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAEwCAAA gAAAAAgAAIAAAABIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAFCAAAAACAAAgAAAAAgAAID+AABVWAAAgAAFAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAKAIAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAQCDAAgAAAAAgAAIAAAAAIQASAAAD+AAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAA gAAAAFgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAACgiAoAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA ABgBAYADAAAIAACAAAAACABEhAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIVQAAAIAAD+gAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgQAYARMQAIAACAAAAACAAAgEAEAAgAAIAA AAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAA AAgAAIAAAFUIAACAAFVVWFUAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAACAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACBAAAAOBABgAAAAAgAAIAAAABIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIBQWFAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAIAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAEACAADgAAAAAgAAIAAAAAI AACEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgA AIAAAAAIAACAAAAACAAAhVBQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAEQgAAIADAAAIAACAAAAACAAAgABAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgABQUAgFAIAAUFUI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAj+AACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAIAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgBAIAAMwAIAACA AAAACAAAgAAAAAgEAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAUACAAAgAAAAAgAAIAAAAAIUFWAAAAAWABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAIAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIABCAAAAwCAAAgAAAAAgAAIAAAAAIAACEAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACA AAAACABQgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAA AAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAggAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAEAAA CDAAgAAAAAgAAIAAAAAIAACAAEAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAUFAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgAAgAAID+ AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAQgAAIMAAAAIAACAAAAACAAAgAAAAAhAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAA CAAAgAAAAAhVBYAAAABYVVWFBQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAgCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAABgBAIAAAwAIAACAAAAACAAAgAAAAAgAAIAEAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACCAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAAGAAAAwCAAAgAAAAAgAAIAAAAAI AACAAAAECAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQ gAAAAAgAAIAAAAAIAACAAAAACAUAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAQAACDAAgAAAAAgAAIAAAAAIAACAAAAACEAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAUIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgCAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAABAACAD+AIMAAAAIAACA AAAACAAAgAAAAAgAAIBAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIVVAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACCAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAABgAAIAAAwAIAACAAAAACAAAgAAAAAgAAIAAAEAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAD+AAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAACAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAYAAADAI AACAAAAACAAAgAAAAAj+AACAAAAACAAEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgCAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAQAACDAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAE AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAI AACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA ABAACAAwgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAEgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIBQCAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAACAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAABgAAIAwAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAUACAAAgAAAAAgAAIAAAFAIVVWFAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgQAYAAAAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAEAACAAAgAAAAAgAAIAAAAAI AACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAhQBQAAgA AIAAAAAIAACAAAAACAAAhQAAVVgAAIVVAABYVQCAUFUACAAAgFAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIACAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACBAAAACAMAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAhAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgABVAAgFAIUABQBY AAX+gFAABQhQAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAIIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAEACAAwgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAFAIBQCFAFUAWABVgFAAVQhQAIUFAAAIAAWAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+ CAAAgAAAAAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAEAgAAIAwAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUACF AFBQCAVQgAUFUAgFBYAFBQUIAACAUFVVWAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAIA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgQAIAAAAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CABAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUFhVVYAAAAAI AACAAAAACAAAgAAABVgAAIAAAAAIAACAAAAACAAAgFVVBQhVAIUAVQBYAFWAUABVCFAAgAAAUAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAIIAACAAAAACAAAgAAAAAgAAIAAAAAIAACB AAAACAMAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgFAIUAAAAIAACAAAAA CAAAgAAAAAgFAIUAUABYAFCAUABQCFAAgAUAAAgABYAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIIACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAEACAAwgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAAWAAAgAAAAAgAAIAAAAAIAACFAFAACAAAgAAAAAgAAIAAAAAIAACFAABVWAAAhVUAAFhVAIBQ VQAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAgAACAAAgAD+AAAIAACAAAAA CAAAgAAAEAgAAIAwAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAFAACAUA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAggAAIAAAAAIAACAAAAACAAAgAAAAAgRAIAAMAMIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAABAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAA CAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAhQVYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAggAIAAAAAIAACA AAAACAAAgAAAAAgAEID+AAAAOAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAASA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAgAACAAAgAAAAAgAAIAAAAAIAACAEAAACAADgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAQAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAj+AACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAC CAAAgAAAAAgAAIAAAAAIAACAAAABCAAAgAMAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAEgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgA AIAAAAAIAACAAAAACFAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAF gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAggAIAAAAAIAACAAAAACAAAgAAAAAgBAIAA MAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAQIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAD+CAAAgAAAAAgAAIVQUAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIACAAAIAACAAAAACAAAgAAAAAgAEIAAAAA4AACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAD+AIAAAAAIAACAAEAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAFCAAAAACAAAgAAAAAgAAIAAUFAIBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAACCAAAgAAAAAgAAIAAAAAI AACAEAAACAADgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACEAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIBQWF AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACCAAgAAAAAgAAIAAAAAIAACAAAABCAAAgAMAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAQAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgFUFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIACAAAIAACA AAAACAAAgAAAABgBAIAAMAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AEAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAIIAACAAAAACAAAgAAAAAgAAYAAAAA4AACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAASAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CCAAgAAAAAgAAIAAAAAIAACAAQAACAADgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAEAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAA gAAAAAgAAIAAAAAIAFCFAFAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAA gFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAIAAAgAAIAAAAAIAACAABAACAAAgwMA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgEAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgFAABVgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAA gAAAAAgAAIAAAAIIAACAAAAACAAAgAAAABgAAIAAAwAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAABQAIAACAAAAACAAAgAAAUAhQBYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgABYAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAgCAAAAACAAAgAAAAAgA AYAAADAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAECAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAAWA BQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAD+CAAAggAAAAgAAIAAAAAIAACAAQAACDAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAUFVVWAUAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgAAgAAIAA AAAIAACAABAACAAAgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIBAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgCAIAAAAAIAACAAAD+ABgAAIAAAwAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACCAAAACAAAgAAAAAgQAYAAADAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACABAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACABQ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAACAACAAAgAAAAAgAAIEAAAAIMACAAAAA CAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAQAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAACgAAIAAAAAIAACAAAEACAAAgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAD+AIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIIAAAAAIAACAAAAQCAAA gAAwAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACCAgIACAAAgAAAAAgQEYEAAwA4AACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAABAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAIgKAAAgAAA AAgAAIAQADAIAwOAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAA AAgAAIAAAAAIAESAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAACgAAIAAAAAIAACAAAABCDAAgAMAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACEBAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AoAAAAAIAACAAAAAGAEAgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACARAQACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAIAAACAAAgAAAAAgAAYAAAwAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgABEAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAACCAAAgAAAAAgAAIABADMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgABARAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAggAIAAAAAIAACAABAACAMA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAERIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAAWAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIACAAAIAACAAAAAGAAwgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABIBACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAACAACAAAgAAA AAgQAYAwAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CEQEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAA gAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAIAgAAAAAgAAIEAAAMIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA ggAAAAj+AACAAAEACAMAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAQIQEAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAAAAQCAAwgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBEAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAoAACAAAAACBAAgDAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAQEQACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+ AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAACgAAAAAgAEIEAAAMIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAEAECAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgCAAAAgAAIAQAAAIAwCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgA AIAAAAAIAACAAAAACAAAgAAAREgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQ VQAIUFWAAFBVCABQhQUAUFgFAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAIAACAAAAB CAAzgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAEgEAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAFAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAFCFAAhQBQAFgAUIBQAFAIUACABQAACAAF gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIIACAAAAACAEAgAMAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAD+AAAIQASAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAVQAFgFUIBQBVAIUAWABVAFCAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAIAAAgAEIAAMAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAESE AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAUIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAVQAIBQWFAAUFWAAFhVAA BVhQAIAAAFBYVVWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgAAgAAIARAAA4AACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACEBAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFWFVQUACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIUACFBVAAWAVQgFAFUAhQBYAFAAAIAAWAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAgCAABAACAADgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgEQEAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACFAAgAVQAAgF UIAABVAIAAWABQAFCAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACCAAAAGAAAgAMAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgABEAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFBVAAhQVYAAUFUIAFCFBQBQWAUAgAAAUAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAACAAgAAYAAMAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAQEQIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAACgAAIABAAA4 AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAEBIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA UAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAAKAABEACAADgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACEQAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+UAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA IAAQCAAAgAMAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACEBEgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAIAgQAIAAMwAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAQIQAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAD+ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAggAIEAADAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIREAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIACAQAIMACAAAAACAD+AIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAQAQACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAARCAAAgwAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AEQECAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAEAgAADAAgA AIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAARAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAEIIAADAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAEgEAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAQ AgAIMACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhEBIAAAAD+CAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAABKAAAgwAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAESAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUID+AAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAAGAECgAADAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAECEBAAACAAAgAAAAAgA AIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAYAgADAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgEQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgA AIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIABAAIIMwCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgABEAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAABAACCAwgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAQEQIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA BQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAAGAAAgjAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAEBI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgQAYAA IAMIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAASEQAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+ AACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIEAAAAoAwCAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACEAEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAI AACAAAEACAAwgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgARIQAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIBQAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAQCAAAgDAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIQEAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACBAAgAAwIwgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAQAQACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAEIEAAAA4IACAAAAACAAA gAAAAAgAAIAAAAAIAACAAEQECAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAQAAAIAAOAAgAACAAAgAAAAAgAAIAAAAAIAAD+gAAARAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAARGBERgTMg IggAAIAAAAAIAACAAAAACAAAgAAAQEgEAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAwAAgiAIAAAAAIAACAAAAACAAAgAAAAAhEAIAA AAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAA4ACKAAAAACAAAgAAAAAgAAIAAAAAIAESAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAD+AAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAOAAgAACAAAgAAAAAgAAIAAAAAI AACEBAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAMiAAgAAIAAAAAIAACAAAAACAAAgEAEAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAwIAgAAIAAAAAIAACA AAAACAAAgABABAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAA4IgCAAAAACAAAgAAAAAgAAIAAAEBIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAID+ AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIACOAAAAA CAAAgAAAAAgAAIAAAAAIRACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAMAAAgAAIAAAAAIAACAAAAACABEgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAyAQgAAIAAAAAIAACAAAAACAAAhAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAACIIAwCAAAAACAAAgAAAAAgAAIBABAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACA UAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAjCAAAAACAAAgAAAAAgAAIAAQAQIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIACKAMAD+AAgAAIAAAAAIAACA AABASAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAFgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAIAAwgAAIAAAAAIAACAAAAACEQAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAVYUAAFVYAACFVQAAWFUAgFBVAAgAAIBQAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAiAAgDAIAAAAAI AACAAAAACABEgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAAUIBQCF AAUAWAAFgFAABQhQAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAACIIADCAAAAACAAAgAAAAAgAAIQEAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFAAhQBVAFgAVYBQAFUIUACFBQAACAAFgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAgCA MAEACAAAgAAAAAgAAIBABAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CABVhQBQUAgFUIAFBVAIBQWABQUFCAAAgFBVVVgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAigAAAEwgAAIAAAAAIAACAAEAECAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAFBYVVWA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAAAIVQCFAFUAWABVgFAAVQhQAIAA AFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAIAAAgTAIAAAAAIAACAAABASAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAUIAACFAFAAWABQgFAAUAhQAIAFAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAIgAIADCBAAAACAAAgAAAAAhEAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+ CAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFBVhQUAVVgAAIVVAABY VQCAUFUACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAACIIAACAMAEACAAAgAAAAAgARIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAIAgAAAEwgAAIAAAAAI AACEBAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAABQAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAigAAAAAgTAIAAAAAIAACAQAQACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIICAAAIADCA AQAACAAAgABABAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAgAIAACAMBAACAAAgAAAQEgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA BQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAi CAAAgAAAAxgAAIAAAAAIRACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAIAgAAAAAgDAYAAAAAIAESAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAigAAAAAj+ADCAAQAACAAAhAQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgABYAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIICAAAIAACAABMACAAAgEAEAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAgAIAACAAAAwGAAAgABABAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACA AAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAiCAAAgAAAAAgwEIAA AEBIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAIAgAAAAAgAAIMQAAAIRACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIoAAAAAI AACAAAMBCABEgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIICAAAIAACAAAAwCAEAhAQAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAIACAAAgAAAAAgwEIBABAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAiCAAAgAAAAAgAAIMQQAQIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgCAIAAAAAIAACAAANBSAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAUACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIoAAAAAIAACAAAAwCEQAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACCAgAACAAAgAAAAAgARIEAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CABQgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAIACAAAgAAAAAgA AIQEAQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAID+AAAACAAAgAAAIggAAIAAAAAIAACAAEQTCAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAACgiAIAA AAAIAACAAEBEGAMAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgiAoAAAAAIAAD+gAAAREgBAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAD+AAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI ACKAAAAACAAAgAAAQEgUAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIACCCAgAACAAAgAAAADhEAYAAAAAIAACAAAAA CAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgCIAAAgAAIAAAAAIQ0SAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgCAiAAgAAIAAAAAIAESEAQAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAAD+gAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAIAIIAACAAAAACABAhBQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACIoAACAAAAACAAAhEQB AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAAKAIAgAAAAAgAAIBEFAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCICgAAAAAgA AIBARAEIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA UAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIoAAAAAIAACAAEQUCAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIIC AAAIAACAAEBEGAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAIgIACAAAgAAAREgBAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+UIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAACIACAAAgAAAQEgUAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAACD+IggAAIAAAABIRBGAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAA gAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAICgAAIAAAAAIRBSBAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAUACFBVgABQVQgAUIUFAFBYBQCAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAACgiAIAAAAAIQESBAQAACAAA gAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAF AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAUFgAAIUAUABYAFCAUABQCFAAgAUA AAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIIAKAAAAACABDhBEAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+ AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAUIAAUABYBVCAUAVQCFAFgAVQBQgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIACKCAAAACAAAhEQB AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIBQWFAAX+BVgA BYVQAAVYUACAAABQWFVVgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAggIAAAgAAIBEFAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABVhVUFAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAhQVQAFgFUIBQBVAIUAWABQAACAAFgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgCICAAgA AIBARAEIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgABQ AAgFUIAABVAIAAWABQAFCAAAgFD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAgIgAIAACAAEQUCAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQVQAIUFWAAFBVCABQhQUAUFgFAIAAAFAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA IAIIAACAAEBEGAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAiKAAAgAAAREgRAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAgKAIAgAAAQEgUAYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgiAIAAAABIRBGAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAggIoAAAAAIRBSBAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIACKCAAAACABEgwEAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAID+AAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACCAgAACABAhBQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAIgIACAAAhEQB AAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAiAAgAAIBDFAEIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAgIggA AIAwRBQIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAD+AIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAACAoAACAAENEGAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAoIgCAADBESAEAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACCICgAAAQ0gUAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAigAAAAEhEAYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIBQ AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAIIICAAAIRBSAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAiAAAIQESBAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAWAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAICIACABDhBEAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAACACCAAwhEQBAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAIigAAINE FAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAACgCAIBDRAEIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgi AoD+MEQUCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA UAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIACKAAEBEGAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+ AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIACCCAgBESAEAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAI AACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgCIAQUgEAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgCAiEDhEAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAFAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAIgIIQ0SAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACA AAAACAAAgAAAAAgAAIAAACIIMESEAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAgKAJDhAQAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAF AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAFgAAAAAgAAIAAAAAIAACAAAAACCJAhEQAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAggIoRE AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAFCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAIoJEFAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAFgAAAAAgAAIAAAAAI AACCAkQBCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAFgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAARCAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAA AAD+CAAAgAAAABgBAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+ AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA WAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAUAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI BQCAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAUAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACA AAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhQAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAABQgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgABYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAI AACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQVQAIAACAUAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgABQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIUACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAUIUACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACABQgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIBQCAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACABQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAABQCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAABQAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFAAhQUAAAgABYAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAABQAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACFAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAFCAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgABYAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIBQAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAABYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAUFBQgAAIBQVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWF VVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVX+hVVVVVhVVYVVVVVYVVWF VVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVV VVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVV VVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVV WFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVYVVWFVVVVWFVVhVVVVVhVVYVVVVVY VVWAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFUI UACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUACABQAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgFBVAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+ CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACFVQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUACFBV gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABQWAUAgFUFAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAUIUFAFBYBQCAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAFAIAFCFBQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIVVWFAFBVCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAUAUACFUFgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAABVWFUAgFUFAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAUAWAAAgAAAAAj+AACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUFgAAIUAUAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAhQAIAFUAAIBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIBQAFAIUACABQAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUAWAUABQCAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACFAAAAWABQgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAAD+gAAABQgAUIAABQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAFUAAIBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAFgAVYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAUIAAUABYBQCAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAUIBVCFAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAWABVAFCAAAgAD+AAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhVAAUAhQBYAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgABQVVgAUIBQBQAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgF AIAABVBYAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAUAAIBVCFAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAUIAFBQAIAACA AAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAUACAUFhQAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAABQWAUAhVBQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAhQUABVhQAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAF UAgABYVQAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIUABQVYAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIVVBQBYUFCAAAAACAD+AIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAAWAAAhVBQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAFUAWAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAAWAAAhQVQAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFAA gABQBQgFAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAUAhQBYAFAAAIAACA AAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAABYVVWAUAVQCAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAFAAWAVQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAFAACAVQhQAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAFgABQ BQgFAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA WABQgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAUIAAUAAIBQCAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAFAAAIBQCFAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAFAIAAWABQAFCAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAUABQCAAFgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAFAACAVQ gAAFAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAUAhQAFAFgAAIAAAAAIAACA AAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAFAAAIBQCFAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIVVAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIBQVQAIUFWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAFVYVQCAVQUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAFCFBQBQ WAUAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAUAgAUIUFAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAhQVYAAUFUIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIBVBQAIVQWAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAUIAACAVQUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+ gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAID+AAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAD+AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACFBVgABVVQgABYBQAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgFAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAD+AAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAhQBQAFgAUIBQAFD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAFAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAD+AIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAUAAIAFCAAAVQCAAFgAAAAAgFAIUA UFVYAFCFBQBQWFAAgFUFAAgAAIBQUAUIAFWFAFBQWAAAhVUAAFhVAIAFVQAIVVWFAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIBQCAAFVVCAAFgFAAAAgAAIUAUABYAACAAAD+UAhQAIUFUAAIBQCAAABQWAAF gAUABQhVAIUABQBYAAWAUABVCFAAgFAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAhQAAAFgAAIBQAFAI AACAAFAACAUAhVUAAFhVBYAFAAUIVVWFAAAACAAFgFAAVVhVAIUAAABYAACAUFVVCFAAgAUAUAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAAD+gAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgABQAAgFUIAAAFAIAAWAAAAACAVQhQAAAFgABYBQAAUIVQCFAAAA CAAAgFD+BVAIUACAAFAACABQgAAFUAgAAIAFAAUIAAWFAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAD+CAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIUFWA AAUACABQhQUAAAgAAIBVUABYVQWAAFVVCABVgAUAVVgAAIAAAFAIVQCAUFUACAUAgABQVQgAUIUF AAUIUACAAAUACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAD+AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAUABQgAAIAAAAAIAAWAAAAACAAAgAAAAAgAAID+AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAD+ AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAFBYBQCAAAAACAAAgFAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgA AIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAj+AACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAA gAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACA AAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAA AAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACDgAAA AAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAA CAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAIAACAAAAACAAAgAAAAAgAAIAAAAAI AACAAAAACAAAgAAAAAkAOw== --xrptmDWBB9 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Cheers. --ro --xrptmDWBB9-- From wolfgang.walter@studentenwerk.mhn.de Sat Apr 23 14:03:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 14:03:42 -0700 (PDT) Received: from email.studentenwerk.mhn.de (mailin.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NL3ddD028651 for ; Sat, 23 Apr 2005 14:03:40 -0700 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id BFEFF58002; Sat, 23 Apr 2005 23:03:36 +0200 (CEST) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id B2B8A54002; Sat, 23 Apr 2005 23:03:36 +0200 (CEST) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: hadi@cyberus.ca Subject: Re: Problem with IPSEC tunnel mode Date: Sat, 23 Apr 2005 23:03:35 +0200 User-Agent: KMail/1.7.2 Cc: Herbert Xu , netdev@oss.sgi.com References: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <1114278545.7669.75.camel@localhost.localdomain> In-Reply-To: <1114278545.7669.75.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200504232303.35549.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3NL3ddD028651 X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 3407 Lines: 86 Am Samstag, 23. April 2005 19:49 schrieb jamal: > On Fri, 2005-22-04 at 15:22 +0200, Wolfgang Walter wrote: > So to allow pass-through of esp packets from a<->d at c, you will have > to essentially create special policy rules (at FWD and OUT) to basically > just allow if src/dst = a/d, correct? Yes. > > > spdadd 192.168.2.100 192.168.3.10 any -P in ipsec > > esp/transport//require > > ah/transport//require; > > > > installs both in and fwd rules (in RFC-mode). > > What is "RFC mode"? The RFCs for ipsec talk about the SPD. This database must be consulted for every packet entering or leaving. Its defined as an ordered database. A rules has direction, selectors (i.e. src, dst, next layer protocoll, src-port, dst-port, icmp-type) and processing info (BYPASS = not handled by ipsec, DISCARD = drop the packet, PROTECT = handled by ipsec). So setkey in RFC mode sets in anf fwd rules as RFC-in = linux-in + linux-fwd. > > > Use option -k for only setting in rules (RFC only knows IN and OUT > > rules). This behaviour was added to > > ipsec-tools. As far as I know earlier kernels had a bug and didn't check > > fwd ruleset so that setkey and racoon worked by accident under linux. > > > > > > racoon now behaves like pluto: it inserts always in and fwd rules. Its > > easier than to check if a in or fwd rule or both is needed. > > I think i am still lost on the desire to have the FWD database. Unless > we are trying to use SPD for firewalling? SPD is indeed also a sort of firewall. You can use it to construct i.e. a vpn-gateway and forbid any non-vpn-traffic entering or leaving. How the SPD is implemented is of course not specified. I think KLIPS use a mixing of routing and netfilter and "ipsec-netdevices" to realise the SPD. My personal view is that 2.6 native SPD is better. Its easier to understand and protect i.e. vpn-gateways. Using selectors other than src, dst in the SPD is tricky, by the way, because of fragments. Say a rule selects packets from a to b with protocol tcp and dst-port 80 to be sent through a tunnel you must have an extra rule (and tunnel) for the fragments (and all fragments are tunneled then). Maybe more complex selectors should be realised by netfilter, a module which can mark packets. And SPD uses that mark. Then statefull policies are possible, i.e. I don't know if linux handles ICMP traffic well, often one must check the payload against the SPD. I had no time yet to do some tests. > > > And no, we do not use setkey any more but ip xfrm (though setkey displays > > more information, i.e. it tells you if a policy is socket-specific). > > Should be fixable in ip xfrm .. > > > Reason is > > that neither setkey nor racoon can handle large rule sets. And for most > > fwd rules we also set an in rule (as pluto does). > > Do you know why pfkey doesnt scale? Herbert? It seems to deliver the whole message at once. If one increase the socket-buffer (must change racoon and setkey source, at least with version 0.3.3) enough one gets complete dumps, ie. But sometimes there seems to be still problems - i.e. if you send a lot of messages. Maybe the kernel can not create these large messages because it cannot allocate enough memory in that moment or racoon cannot read fast enough. Greetings, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leopoldstraße 15 80802 München From reuben-lkml@reub.net Sat Apr 23 18:21:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 18:21:35 -0700 (PDT) Received: from tornado.reub.net (tornado.reub.net [60.234.136.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3O1LTdD017308 for ; Sat, 23 Apr 2005 18:21:31 -0700 Received: from typhoon.reub.net (typhoon.reub.net [192.168.0.6]) by tornado.reub.net (Postfix) with ESMTP id 4F6CE325D; Sun, 24 Apr 2005 12:54:21 +1200 (NZST) Message-Id: <6.2.3.0.2.20050424125154.04124008@tornado.reub.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.0 Date: Sun, 24 Apr 2005 12:54:21 +1200 To: Andrew Morton , netdev@oss.sgi.com From: Reuben Farrelly Subject: Re: Fw: 2x crash in 2.6.12-rc2-mm3 Cc: "David S. Miller" In-Reply-To: <20050423175021.1272a974.akpm@osdl.org> References: <20050423175021.1272a974.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: reuben-lkml@reub.net Precedence: bulk X-list: netdev Content-Length: 1952 Lines: 65 I also had this one last night (still with rc2-mm3) but hadn't yet gotten around to sending it on... BUG: soft lockup detected on CPU#1! Pid: 0, comm: swapper EIP: 0060:[] CPU: 1 EIP is at _spin_lock+0x52/0x63 EFLAGS: 00000202 Not tainted (2.6.12-rc2-mm3) EAX: 00000001 EBX: d3454e24 ECX: d34550e8 EDX: 00000000 ESI: dff92000 EDI: d3454e24 EBP: c030a9bd DS: 007b ES: 007b CR0: 8005003b CR2: b78ba004 CR3: 0c6b1000 CR4: 000006d0 [] tcp_delack_timer+0x12/0x1e3 [] run_timer_softirq+0xd6/0x1a6 [] rebalance_tick+0xfb/0x11a [] __do_softirq+0x72/0xdc [] do_softirq+0x33/0x36 [] irq_exit+0x40/0x42 [] apic_timer_interrupt+0x1c/0x24 [] mwait_idle+0x25/0x43 [] acpi_processor_idle+0xf0/0x250 [processor] [] cpu_idle+0x4e/0x63 I imagine this may be related, if it's not the same problem? The traces look similar but not identical. reuben At 12:50 p.m. 24/04/2005, Andrew Morton wrote: >Looks like a deadlock in neigh_timer_handler(). > >Straightforward, I think - foo_lock_bh() is not sufficient to prevent timer >handlers from executing. > >Whcih probably means someone has already fixed it? > > > >Begin forwarded message: > >Date: Sun, 17 Apr 2005 01:59:01 +1200 >From: Reuben Farrelly >To: Andrew Morton >Subject: 2x crash in 2.6.12-rc2-mm3 > > >Hi Andrew, > >Had 2x crashes over about 3 hours with rc2-mm3 tonight (just flown >back from Sydney, so when I got home rebooted from rc2-mm1 which was >good, to rc2-mm3 which so far is more unstable). > >Photo at http://www.reub.net/kernel/P4160257.JPG Serial console >output probably not too hard if required. > >Box is a single CPU/HT, P4 with Intel Gigabit Lan and compiled with >FC4 gcc4 (latest) > >I didn't see this one show up on lkml, but my guess is that this is >something network related? > >reuben From dtor_core@ameritech.net Sat Apr 23 21:01:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 21:01:20 -0700 (PDT) Received: from smtp818.mail.sc5.yahoo.com (smtp818.mail.sc5.yahoo.com [66.163.170.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3O41FdD030735 for ; Sat, 23 Apr 2005 21:01:16 -0700 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.253.36.236 with plain) by smtp818.mail.sc5.yahoo.com with SMTP; 24 Apr 2005 04:01:14 -0000 From: Dmitry Torokhov To: netdev@oss.sgi.com Subject: Race between suspend and open in network drivers? Date: Sat, 23 Apr 2005 23:01:12 -0500 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504232301.12990.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 862 Lines: 26 Hi, I have a question regarding possible race between suspend and open methods in most network drivers. Consider b44 for example: static int b44_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct b44 *bp = netdev_priv(dev); if (!netif_running(dev)) return 0; Why can we just check netif_running and bail out? What stops 2nd CPU from getting into b44_open right then and set up the device and we'll get into suspend with device fully set up and DMAing... Come to think of it it's not even a race since b44_open does not even check if device is suspended. I must be missing something... Do we rely on userland being completely stopped while suspending? But what about suspend to ram (IIRC we don't stop userlan there) or selective suspend? Thanks! -- Dmitry From herbert@gondor.apana.org.au Sun Apr 24 01:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 01:14:42 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3O8EZdD018993 for ; Sun, 24 Apr 2005 01:14:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DPcFt-0003sQ-00; Sun, 24 Apr 2005 18:14:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DPcFm-0002KW-00; Sun, 24 Apr 2005 18:14:10 +1000 From: Herbert Xu To: reuben-lkml@reub.net (Reuben Farrelly) Subject: Re: Fw: 2x crash in 2.6.12-rc2-mm3 Cc: akpm@osdl.org, netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <6.2.3.0.2.20050424125154.04124008@tornado.reub.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 24 Apr 2005 18:14:10 +1000 X-Virus-Scanned: ClamAV 0.83/850/Sat Apr 23 21:08:28 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 983 Lines: 26 Reuben Farrelly wrote: > I also had this one last night (still with rc2-mm3) but hadn't yet > gotten around to sending it on... > > BUG: soft lockup detected on CPU#1! > > Pid: 0, comm: swapper > EIP: 0060:[] CPU: 1 > EIP is at _spin_lock+0x52/0x63 > EFLAGS: 00000202 Not tainted (2.6.12-rc2-mm3) > EAX: 00000001 EBX: d3454e24 ECX: d34550e8 EDX: 00000000 > ESI: dff92000 EDI: d3454e24 EBP: c030a9bd DS: 007b ES: 007b > CR0: 8005003b CR2: b78ba004 CR3: 0c6b1000 CR4: 000006d0 > [] tcp_delack_timer+0x12/0x1e3 > [] run_timer_softirq+0xd6/0x1a6 The only thing these two traces tell us is that there is probably something seriously screwed up in mm with regards to timers and/or spin locks. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Apr 24 15:08:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 15:08:57 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3OM8qdD022299 for ; Sun, 24 Apr 2005 15:08:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DPpHW-00033F-5k for netdev@oss.sgi.com; Sun, 24 Apr 2005 16:08:50 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DPpHY-0002Bw-Uj; Sun, 24 Apr 2005 18:08:53 -0400 Subject: Re: Problem with IPSEC tunnel mode From: jamal Reply-To: hadi@cyberus.ca To: Wolfgang Walter Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <200504232303.35549.wolfgang.walter@studentenwerk.mhn.de> References: <200504221522.49403.wolfgang.walter@studentenwerk.mhn.de> <1114278545.7669.75.camel@localhost.localdomain> <200504232303.35549.wolfgang.walter@studentenwerk.mhn.de> Content-Type: text/plain Organization: unknown Date: Sun, 24 Apr 2005 18:08:47 -0400 Message-Id: <1114380527.7669.142.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/850/Sat Apr 23 21:08:28 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 356 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: 1692 Lines: 47 On Sat, 2005-23-04 at 23:03 +0200, Wolfgang Walter wrote: > > SPD is indeed also a sort of firewall. You can use it to construct i.e. a > vpn-gateway and forbid any non-vpn-traffic entering or leaving. > So i think design intent must have been to map these to the netfilter/iptables hooks - fwd/in/out hooks. > How the SPD is implemented is of course not specified. I think KLIPS use a > mixing of routing and netfilter and "ipsec-netdevices" to realise the SPD. > It could certainly be any applicable classifier that can map at least the 6 tuples {src/dst IP, src/dst port, proto, netdevice}. > My personal view is that 2.6 native SPD is better. Its easier to understand > and protect i.e. vpn-gateways. Except it introduces yet another firewall scheme. We should look at unifying these schemes. Both the input/fwding can be derived at the ingress. > Using selectors other than src, dst in the SPD is tricky, by the way, because > of fragments. Say a rule selects packets from a to b with protocol tcp and > dst-port 80 to be sent through a tunnel you must have an extra rule (and > tunnel) for the fragments (and all fragments are tunneled then). > > > Maybe more complex selectors should be realised by netfilter, a module which > can mark packets. And SPD uses that mark. Then statefull policies are > possible, i.e. > I think that it is probably the best path forward - i suppose this being the first incarnation of native ipsec this could be seen as a lesson. > I don't know if linux handles ICMP traffic well, often one must check the > payload against the SPD. I had no time yet to do some tests. > from the code it should work just fine. cheers, jamal From davem@davemloft.net Sun Apr 24 19:45:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 19:45:27 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P2jNdD016492 for ; Sun, 24 Apr 2005 19:45:23 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPtTN-0008No-00; Sun, 24 Apr 2005 19:37:21 -0700 Date: Sun, 24 Apr 2005 19:37:21 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [RFC] neighbour tables configuration via rtnetlink Message-Id: <20050424193721.01ecb0b2.davem@davemloft.net> In-Reply-To: <20050305172257.GN31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/850/Sat Apr 23 21:08:28 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1700 Lines: 33 On Sat, 5 Mar 2005 18:22:57 +0100 Thomas Graf wrote: > Before I go ahead, putting more effort into it, what is our preferred > interface for network configuration? My personal preference is to make > everything available via netlink with the long term plan to extend it > with distributive remote configuration protocol in userspace. If so, > shall we continue to push everything into rtnetlink regardless of the > association to routing? The only drawback of the currently "overloaded" > rtnetlink is the rtnl semaphore which has grown into something like > the BKL for networking. I'm not aware of any performance problems or > other issues because of this except for the module loading over nfs. > Does anyone? > > Thoughts? Perhaps we shouldn't try to assosciate the rtnl semaphore with lock_kernel(). It really is more of a write lock than a lock which protects both reads and writes. (yes, I realize the rtnl packet processing code holds this thing for all messages, not just ones which modify config state) It is always going to be tempting to finer-grain the rtnl semaphore, but just about every single RTNL state change has some trickle down effect on some generic network device setting. So at that moment any attempt to fine-grain the locking for an RTNL operation fails. It is tempting to consider a hierarchy of locks, with a locking order such that generic netdev stuff sits at the bottom. But welcome to an AB<-->BA deadlock city as we hit generic device state changes which cause modification of protocol specific addressing and routing state. Back to the main topic, Thomas do you plan to complete this rtnetlink'ification of neigh for the 2.6.13 timeframe? From davem@davemloft.net Sun Apr 24 19:51:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 19:51:15 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P2pBdD017365 for ; Sun, 24 Apr 2005 19:51:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPtZ4-0008SY-00; Sun, 24 Apr 2005 19:43:14 -0700 Date: Sun, 24 Apr 2005 19:43:13 -0700 From: "David S. Miller" To: Matt Domsch Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4.30-pre3] net/{icmp,ipv6}.h: include net/snmp.h Message-Id: <20050424194313.2c466b8a.davem@davemloft.net> In-Reply-To: <20050318212256.GB26112@lists.us.dell.com> References: <20050318212256.GB26112@lists.us.dell.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/850/Sat Apr 23 21:08:28 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 623 Lines: 13 On Fri, 18 Mar 2005 15:22:56 -0600 Matt Domsch wrote: > Compiling linux-2.4.30-pre3 with FC4-test1 compiler gcc-4.0.0-0.32 on > x86_64 fails because icmp_statistics[NR_CPUS*2] is declared as a sized > array without struct icmp_mib having been defined, likewise > ipv6_statistics[NR_CPUS*2] without struct ipv6_mib first defined. > > Solution is to include before declaring either array. I don't think we're going to take gcc-4.0 build fixes for the 2.4.x tree. I think deep maintainence mode should really mean deep maintainence mode, and that's what the 2.4.x tree is in right now. From davem@davemloft.net Sun Apr 24 20:18:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 20:18:52 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P3IldD019487 for ; Sun, 24 Apr 2005 20:18:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPtzh-0000BC-00; Sun, 24 Apr 2005 20:10:45 -0700 Date: Sun, 24 Apr 2005 20:10:45 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: kaber@trash.net, netdev@oss.sgi.com, tgraf@suug.ch Subject: Re: PATCH: Allow Simple actions WAS(Re: patch: introduce simple actions Message-Id: <20050424201045.781707b4.davem@davemloft.net> In-Reply-To: <1112794142.1098.56.camel@jzny.localdomain> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> <20050322195827.5ecd0c33.davem@davemloft.net> <1111550799.1116.28.camel@jzny.localdomain> <1112794142.1098.56.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 438 Lines: 15 On 06 Apr 2005 09:29:02 -0400 jamal wrote: > Anyways, here it is with suggestions incorporated. > I could probably split it into two patches one for > the base and the other for the simple action. Let me > know if you want me to do this. > > description: > -Allow simple actions > -introduce a simple action example to demonstrate usage > > signed off by: Jamal Hadi Salim Applied, thanks Jamal. From davem@davemloft.net Sun Apr 24 20:21:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 20:21:54 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P3LodD023589 for ; Sun, 24 Apr 2005 20:21:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPu2j-0000E9-00; Sun, 24 Apr 2005 20:13:53 -0700 Date: Sun, 24 Apr 2005 20:13:53 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: local_bh_enable & hard_start_xmit Message-Id: <20050424201353.7df5e470.davem@davemloft.net> In-Reply-To: <426952DE.5090203@candelatech.com> References: <42642892.2040300@candelatech.com> <20050418151421.41a8f64a.davem@davemloft.net> <42643BB9.6050705@candelatech.com> <20050418160147.6fd7ac9a.davem@davemloft.net> <42644FD4.3030200@candelatech.com> <20050419231442.7e37b087.davem@davemloft.net> <426952DE.5090203@candelatech.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 200 Lines: 9 On Fri, 22 Apr 2005 12:39:10 -0700 Ben Greear wrote: > Sending as attachments this time...plz let me know if these work > better. Looks good, patches applied. Thanks Ben. From davem@davemloft.net Sun Apr 24 20:31:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 20:31:34 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P3VVdD025306 for ; Sun, 24 Apr 2005 20:31:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPuC2-0000HW-00; Sun, 24 Apr 2005 20:23:30 -0700 Date: Sun, 24 Apr 2005 20:23:29 -0700 From: "David S. Miller" To: acme@ghostprotocols.net (Arnaldo Carvalho de Melo) Cc: netdev@oss.sgi.com Subject: Re: [PATCH][IPV6] export inet6_sock_nr Message-Id: <20050424202329.5d03e045.davem@davemloft.net> In-Reply-To: <20050417225433.GC10626@conectiva.com.br> References: <20050417225433.GC10626@conectiva.com.br> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 378 Lines: 15 On Sun, 17 Apr 2005 19:54:33 -0300 acme@ghostprotocols.net (Arnaldo Carvalho de Melo) wrote: > Please apply, SCTP/DCCP needs this. ... when INET_REFCNT_DEBUG is defined :-) > Signed-off-by: Arnaldo Carvalho de Melo Applied, but... > --- net/ipv6/af_inet6.c (revision 57) > +++ net/ipv6/af_inet6.c (working copy) please -p1 root your patches :-) From davem@davemloft.net Sun Apr 24 20:37:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Apr 2005 20:37:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3P3bRdD026259 for ; Sun, 24 Apr 2005 20:37:27 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DPuHn-0000N6-00; Sun, 24 Apr 2005 20:29:27 -0700 Date: Sun, 24 Apr 2005 20:29:26 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [PATCH][SCTP] Fix bug in sctp_init() error handling code. Message-Id: <20050424202926.2d04e546.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 586 Lines: 21 On Fri, 22 Apr 2005 12:28:39 -0700 (PDT) Sridhar Samudrala wrote: > Please apply to 2.6. I can't, something is mangled in your patches. It too me a while to figure out what was wrong but it's in the context lines not modified by your patch. > @@ -1159,8 +1159,6 @@ > status = 0; > out: > return status; > -err_add_protocol: > - proto_unregister(&sctp_prot); Two leading spaces, then a tab, thus the patch doesn't apply. That's a signature of a "*.rej" file btw. Please resubmit the whole batch of SCTP patches you have once you've corrected this problem. From hadi@znyx.com Mon Apr 25 05:16:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 05:16:38 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PCGQdD010509 for ; Mon, 25 Apr 2005 05:16:26 -0700 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042505170505:28460 ; Mon, 25 Apr 2005 05:17:05 -0700 Subject: Re: NAPI, e100, and system performance problem From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Arthur Kepner Cc: "David S. Miller" , ak@muc.de, gnb@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com In-Reply-To: <1114429267.7669.160.camel@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <20050422115230.6037a362.davem@davemloft.net> <1114429267.7669.160.camel@localhost.localdomain> Organization: ZNYX Networks Date: Mon, 25 Apr 2005 08:16:19 -0400 Message-Id: <1114431379.7669.164.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/25/2005 05:17:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/25/2005 05:17:09 AM, Serialize complete at 04/25/2005 05:17:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 387 Lines: 18 After looking closely at the data: To reduce the work, 20 and 40% should be enough. But lets rule out the tg3 and also test with e1000 and UDP. cheers, jamal On Mon, 2005-25-04 at 07:41 -0400, jamal wrote: > Actually, it may be sufficient to collect data for 20, 40, and 80% link > utilization for napi, napi+dmiller_mchan and nonapi > > Same for the e1000. > > cheers, > jamal > From herbert@gondor.apana.org.au Mon Apr 25 05:41:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 05:42:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PCfsdD012978 for ; Mon, 25 Apr 2005 05:41:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQ2uG-0003SY-00; Mon, 25 Apr 2005 22:41:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQ2u8-0005Fm-00; Mon, 25 Apr 2005 22:41:36 +1000 Date: Mon, 25 Apr 2005 22:41:36 +1000 To: "David S. Miller" Cc: fubar@us.ibm.com, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050425124136.GA20159@gondor.apana.org.au> References: <20050408221629.GA21125@gondor.apana.org.au> <200504082356.j38Ntr7k010144@death.nxdomain.ibm.com> <20050409002137.GA21726@gondor.apana.org.au> <20050409003108.GA21962@gondor.apana.org.au> <20050424185149.278ffb93.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20050424185149.278ffb93.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2141 Lines: 63 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Apr 24, 2005 at 06:51:49PM -0700, David S. Miller wrote: > > > So if you want a quick and dirty fix, why not make bonding call > > dev_set_mac_address from a work queue? > > I'd say we still have at least two weeks until 2.6.12 final goes out. > So if you want to work on the proper long-term fix now, by all means > please do so. Well I had a go at it but I realised that this isn't something that can be fixed properly in two weeks. The work queue hack can probably be done in that time frame but it'll be darn ugly. I found another reason why we need to defer the dev_set_mac_address to process context: We need to hold the RTNL while it's taking place. Otherwise someone else could come along and change the slave's MAC address at the same time. Because device drivers tend to rely on the RTNL to guarantee non-reentrancy, this is likely to break. I also managed to find a little bug along the way though so let's quash it :) bond_alb_set_mac_address did not acquire bond->lock before operating on the slaves. As it can be done at any time by the user, this could interfere with the timers. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p drivers/net/bonding/bond_alb.c: 5ce606d9dc03f9b145c3024abecfca20ec65fd9d --- a/drivers/net/bonding/bond_alb.c +++ b/drivers/net/bonding/bond_alb.c @@ -1666,6 +1666,7 @@ int bond_alb_set_mac_address(struct net_ } } + write_lock_bh(&bond->lock); if (swap_slave) { alb_swap_mac_addr(bond, swap_slave, bond->curr_active_slave); } else { @@ -1678,6 +1679,7 @@ int bond_alb_set_mac_address(struct net_ rlb_req_update_slave_clients(bond, bond->curr_active_slave); } } + write_unlock_bh(&bond->lock); return 0; } --4Ckj6UjgE2iN1+kY-- From hadi@cyberus.ca Mon Apr 25 08:10:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 08:10:27 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PFAEdE026157 for ; Mon, 25 Apr 2005 08:10:23 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DQ1xh-0008N5-0V for netdev@oss.sgi.com; Mon, 25 Apr 2005 07:41:13 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQ1xe-0000l5-HP; Mon, 25 Apr 2005 07:41:10 -0400 Subject: Re: NAPI, e100, and system performance problem From: jamal Reply-To: hadi@cyberus.ca To: Arthur Kepner Cc: "David S. Miller" , ak@muc.de, gnb@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com In-Reply-To: References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <20050422115230.6037a362.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Mon, 25 Apr 2005 07:41:07 -0400 Message-Id: <1114429267.7669.160.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 403 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: 163 Lines: 10 Actually, it may be sufficient to collect data for 20, 40, and 80% link utilization for napi, napi+dmiller_mchan and nonapi Same for the e1000. cheers, jamal From davej@redhat.com Mon Apr 25 09:01:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 09:01:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PG1EdD002185 for ; Mon, 25 Apr 2005 09:01:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3PG1DNx022603 for ; Mon, 25 Apr 2005 12:01:13 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3PG1DO08182 for ; Mon, 25 Apr 2005 12:01:13 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j3PG1DVX007168 for ; Mon, 25 Apr 2005 12:01:13 -0400 Received: (from davej@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id j3PG1D57007163 for netdev@oss.sgi.com; Mon, 25 Apr 2005 12:01:13 -0400 X-Authentication-Warning: devserv.devel.redhat.com: davej set sender to davej@redhat.com using -f Date: Mon, 25 Apr 2005 12:01:13 -0400 From: Dave Jones To: netdev@oss.sgi.com Subject: Incorrect permissions on route flush sysctl Message-ID: <20050425160113.GA22919@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Content-Length: 634 Lines: 17 This has been brought up before.. http://lkml.org/lkml/2000/1/21/116 but didnt seem to get resolved. This morning I got someone file a bugzilla about it breaking sysctl(8). Signed-off-by: Dave Jones --- linux-2.6.11/net/ipv4/route.c~ 2005-04-25 11:57:45.000000000 -0400 +++ linux-2.6.11/net/ipv4/route.c 2005-04-25 11:58:09.000000000 -0400 @@ -2843,7 +2843,7 @@ ctl_table ipv4_route_table[] = { .procname = "flush", .data = &flush_delay, .maxlen = sizeof(int), - .mode = 0644, + .mode = 0200, .proc_handler = &ipv4_sysctl_rtcache_flush, .strategy = &ipv4_sysctl_rtcache_flush_strategy, }, From davej@redhat.com Mon Apr 25 09:16:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 09:17:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PGGmdD004516 for ; Mon, 25 Apr 2005 09:16:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3PGGlvQ027498 for ; Mon, 25 Apr 2005 12:16:47 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3PGGlO14052 for ; Mon, 25 Apr 2005 12:16:47 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j3PGGl40017228 for ; Mon, 25 Apr 2005 12:16:47 -0400 Received: (from davej@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id j3PGGlHH017226 for netdev@oss.sgi.com; Mon, 25 Apr 2005 12:16:47 -0400 X-Authentication-Warning: devserv.devel.redhat.com: davej set sender to davej@redhat.com using -f Date: Mon, 25 Apr 2005 12:16:46 -0400 From: Dave Jones To: netdev@oss.sgi.com Subject: Re: Incorrect permissions on route flush sysctl Message-ID: <20050425161646.GA13778@redhat.com> References: <20050425160113.GA22919@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425160113.GA22919@redhat.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/851/Sun Apr 24 18:19:30 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Content-Length: 704 Lines: 20 On Mon, Apr 25, 2005 at 12:01:13PM -0400, Dave Jones wrote: > This has been brought up before.. http://lkml.org/lkml/2000/1/21/116 > but didnt seem to get resolved. This morning I got someone > file a bugzilla about it breaking sysctl(8). And here's its ipv6 counterpart. Signed-off-by: Dave Jones --- linux-2.6.11/net/ipv6/route.c~ 2005-04-25 12:16:02.000000000 -0400 +++ linux-2.6.11/net/ipv6/route.c 2005-04-25 12:16:08.000000000 -0400 @@ -2005,7 +2005,7 @@ ctl_table ipv6_route_table[] = { .procname = "flush", .data = &flush_delay, .maxlen = sizeof(int), - .mode = 0644, + .mode = 0200, .proc_handler = &ipv6_sysctl_rtcache_flush }, { From razzor@kopf-tisch.de Mon Apr 25 10:00:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 10:00:13 -0700 (PDT) Received: from mail.innovalan.de (urtyp.innovalan.de [81.2.162.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PGxwdD008618 for ; Mon, 25 Apr 2005 10:00:00 -0700 Received: by mail.innovalan.de (Postfix, from userid 1004) id CA27319ADCC; Mon, 25 Apr 2005 18:59:57 +0200 (CEST) Received: from coruscant.lan (pD958B640.dip.t-dialin.net [217.88.182.64]) by mail.innovalan.de (Postfix) with ESMTP id B329319ADCA; Mon, 25 Apr 2005 18:59:56 +0200 (CEST) Date: Mon, 25 Apr 2005 19:00:48 +0200 From: Olaf Rempel To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [2.6.11 PATCH] /proc/net/stat/* cleanup Message-ID: <20050425190048.370dfd15@coruscant.lan> In-Reply-To: <20050424193007.0a687ef4.davem@davemloft.net> References: <20050304203751.379dc6a6@coruscant> <20050424193007.0a687ef4.davem@davemloft.net> X-Mailer: Sylpheed-Claws 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__25_Apr_2005_19_00_48_+0200_=OKRuDBXVXRIBrjH" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=0.92.8 X-Virus-Status: Clean X-Virus-Checker-Version: clamassassin 1.2.0 with ClamAV 0.83/851/Mon Apr 25 03:19:30 2005 signatures 31.851 X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-archive-position: 408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razzor@kopf-tisch.de Precedence: bulk X-list: netdev Content-Length: 2146 Lines: 52 --Multipart_Mon__25_Apr_2005_19_00_48_+0200_=OKRuDBXVXRIBrjH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, 24 Apr 2005 19:30:07 -0700 "David S. Miller" wrote: > Your patch is mangled by your email client, the tabs have been turned > into spaces, so the patch will not apply. > > Also, please supply a proper "Signed-off-by:" line with your changes. Whoops. OK Patch against 2.6.11 vanilla /proc/net/stat/* header cleanup Signed-off-by: Olaf Rempel --Multipart_Mon__25_Apr_2005_19_00_48_+0200_=OKRuDBXVXRIBrjH Content-Type: text/x-patch; name=linux-2.6.11-net-stats.patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=linux-2.6.11-net-stats.patch --- linux-2.6.11/net/core/neighbour.c.org 2005-03-02 08:37:47.000000000 +0100 +++ linux-2.6.11/net/core/neighbour.c 2005-04-25 17:52:35.000000000 +0200 @@ -1948,7 +1948,7 @@ struct neigh_statistics *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs forced_gc_goal_miss\n"); + seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs\n"); return 0; } --- linux-2.6.11/net/ipv4/route.c.org 2005-03-02 08:38:38.000000000 +0100 +++ linux-2.6.11/net/ipv4/route.c 2005-04-25 17:55:20.000000000 +0200 @@ -393,7 +393,7 @@ struct rt_cache_stat *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); + seq_printf(seq, "entries in_hit in_slow_tot in_slow_mc in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); return 0; } --Multipart_Mon__25_Apr_2005_19_00_48_+0200_=OKRuDBXVXRIBrjH-- From mallikarjuna.chilakala@intel.com Mon Apr 25 10:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 10:42:49 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PHgZdD012224 for ; Mon, 25 Apr 2005 10:42:36 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3PHgZrD021142; Mon, 25 Apr 2005 17:42:35 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3PHgRDN009635; Mon, 25 Apr 2005 17:42:35 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042510423412941 ; Mon, 25 Apr 2005 10:42:34 -0700 Received: from fmsmsx403.amr.corp.intel.com ([132.233.42.207]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 10:42:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [PATCH net-drivers-2.6 5/11] ixgb: Reset status in the Rx descriptor prior to handing it to the controller Date: Mon, 25 Apr 2005 10:42:33 -0700 Message-ID: <331AD7BED1579543AD146F5A1A44D52506DF2852@fmsmsx403.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH net-drivers-2.6 5/11] ixgb: Reset status in the Rx descriptor prior to handing it to the controller thread-index: AcVF13HgtzEthMGbTdWsv95LR9Y5eg== From: "Chilakala, Mallikarjuna" To: Cc: X-OriginalArrivalTime: 25 Apr 2005 17:42:34.0914 (UTC) FILETIME=[2A1DD820:01C549BE] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3PHgZdD012224 X-archive-position: 410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1536 Lines: 41 Reset status in the Rx descriptor prior to handing it to the controller. Leave three Rx descriptors unused Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1977,8 +1977,8 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte num_group_tail_writes = IXGB_RX_BUFFER_WRITE; - /* leave one descriptor unused */ - while(--cleancount > 0) { + /* leave three descriptors unused */ + while(--cleancount > 2) { rx_desc = IXGB_RX_DESC(*rx_ring, i); skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); @@ -2005,6 +1933,10 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte PCI_DMA_FROMDEVICE); rx_desc->buff_addr = cpu_to_le64(buffer_info->dma); + /* guarantee DD bit not set now before h/w gets descriptor + * this is the rest of the workaround for h/w double + * writeback. */ + rx_desc->status = 0; if((i & ~(num_group_tail_writes- 1)) == i) { /* Force memory writes to complete before letting h/w From mallikarjuna.chilakala@intel.com Mon Apr 25 10:41:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 10:41:40 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PHfadD012097 for ; Mon, 25 Apr 2005 10:41:37 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3PHfarD020647; Mon, 25 Apr 2005 17:41:36 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3PHfMDR008475; Mon, 25 Apr 2005 17:41:36 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042510413612773 ; Mon, 25 Apr 2005 10:41:36 -0700 Received: from fmsmsx403.amr.corp.intel.com ([132.233.42.207]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 10:41:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [PATCH net-drivers-2.6 0/11] ixgb: driver update Date: Mon, 25 Apr 2005 10:41:35 -0700 Message-ID: <331AD7BED1579543AD146F5A1A44D52506DF284C@fmsmsx403.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH net-drivers-2.6 0/11] ixgb: driver update thread-index: AcVF11vpKEaGXFgDQl+V+uZgqz0A8g== From: "Chilakala, Mallikarjuna" To: Cc: X-OriginalArrivalTime: 25 Apr 2005 17:41:36.0279 (UTC) FILETIME=[072ADA70:01C549BE] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3PHfadD012097 X-archive-position: 409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 696 Lines: 18 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Fix multi-cast packet count in statistics 2. Do not set the RS bit on context descriptors 3. Change RDT write bump size back to 4 4. Mask RXO interrupt 5. Reset status in the Rx descriptor prior to handing it to the controller 6. Fix EEPROM functions to be endian-aware 7. Support for ethtool -d 8. Remove hook for suspend. No power management in 10GbE Controllers 9. Code optimization 10. Fixed msec_delay in osdep to use msleep 11. Driver version, white space, comments, device id & other From davem@davemloft.net Mon Apr 25 11:59:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 11:59:53 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PIxedD019497 for ; Mon, 25 Apr 2005 11:59:40 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DQ8fl-0006vQ-00; Mon, 25 Apr 2005 11:51:09 -0700 Date: Mon, 25 Apr 2005 11:51:08 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: akepner@sgi.com, Robert.Olsson@data.slu.se, ak@muc.de, gnb@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem Message-Id: <20050425115108.5fbb8b07.davem@davemloft.net> In-Reply-To: <1114428355.7669.157.camel@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422183004.GC10598@muc.de> <20050422115230.6037a362.davem@davemloft.net> <1114428355.7669.157.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 764 Lines: 20 On Mon, 25 Apr 2005 07:25:55 -0400 jamal wrote: > Dang, I just noticed you used TCP. Could you use UDP please? > > While the suspect may be PIO/s - lets be scientific and prove it. Jamal, enough already... stop being such a control freak. You're exceeding me as a control freak, and that's saying something. The guy got the numbers for us, in response to their claim that on their systems cpu utilization is poor due to NAPI. Are you not convinced of this yet? Will a hundred new sets of numbers using the precise driver and protocol of your choosing convince you more of this? I think you're making unreasonable reqeusts of the problem submitter at this point, and we should be sending them patches to test not a new set of tests to run. From mallikarjuna.chilakala@intel.com Mon Apr 25 12:49:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 12:49:57 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PJnhdD029327 for ; Mon, 25 Apr 2005 12:49:44 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3PJnhOT032036; Mon, 25 Apr 2005 19:49:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3PJnh9n024592; Mon, 25 Apr 2005 19:49:43 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042512494310074 ; Mon, 25 Apr 2005 12:49:43 -0700 Date: Mon, 25 Apr 2005 12:49:43 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3PJnhdD029327 X-archive-position: 430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3052 Lines: 70 Performance optimizations to e100 Tx Path Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -777,7 +777,7 @@ static int e100_eeprom_save(struct nic *         return 0;  }   -#define E100_WAIT_SCB_TIMEOUT 40 +#define E100_WAIT_SCB_TIMEOUT 20000 /* we might have to wait 100ms!!! */  static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr)  {         unsigned long flags; @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni                          * because the controller is too busy, so                          * let's just queue the command and try again                          * when another command is scheduled. */ +                       if(err == -ENOSPC) { +                               //request a reset +                               schedule_work(&nic->tx_timeout_task); +                       }                         break;                 } else {                         nic->cuc_cmd = cuc_resume; @@ -891,7 +895,7 @@ static void mdio_write(struct net_device    static void e100_get_defaults(struct nic *nic)  { -       struct param_range rfds = { .min = 64, .max = 256, .count = 64 }; +       struct param_range rfds = { .min = 16, .max = 256, .count = 64 };         struct param_range cbs  = { .min = 64, .max = 256, .count = 64 };           pci_read_config_byte(nic->pdev, PCI_REVISION_ID, &nic->rev_id); @@ -906,8 +910,9 @@ static void e100_get_defaults(struct nic         /* Quadwords to DMA into FIFO before starting frame transmit */         nic->tx_threshold = 0xE0;   -       nic->tx_command = cpu_to_le16(cb_tx | cb_i | cb_tx_sf | -               ((nic->mac >= mac_82558_D101_A4) ? cb_cid : 0)); +       /* no interrupt for every tx completion, delay = 256us if not 557*/ +       nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf | +               ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));           /* Template for a freshly allocated RFD */         nic->blank_rfd.command = cpu_to_le16(cb_el); @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str         struct sk_buff *skb)  {         cb->command = nic->tx_command; +       /* interrupt every 16 packets regardless of delay */ +       if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i;         cb->u.tcb.tbd_array = cb->dma_addr + offsetof(struct cb, u.tcb.tbd);         cb->u.tcb.tcb_byte_count = 0;         cb->u.tcb.threshold = nic->tx_threshold;         cb->u.tcb.tbd_count = 1;         cb->u.tcb.tbd.buf_addr = cpu_to_le32(pci_map_single(nic->pdev,                 skb->data, skb->len, PCI_DMA_TODEVICE)); +       // check for mapping failure?         cb->u.tcb.tbd.size = cpu_to_le16(skb->len);  }   From felix-linuxkernel@fefe.de Mon Apr 25 13:04:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 13:04:34 -0700 (PDT) Received: from codeblau.de (ipx10069.ipxserver.de [80.190.240.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PK4KdD031332 for ; Mon, 25 Apr 2005 13:04:22 -0700 Received: (qmail 3186 invoked by uid 1000); 25 Apr 2005 19:57:36 -0000 Date: Mon, 25 Apr 2005 21:57:36 +0200 From: Felix von Leitner To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: IPv6 has trouble assigning an interface Message-ID: <20050425195736.GB3123@codeblau.de> References: <20050311202122.GA13205@fefe.de> <20050311173308.7a076e8f.akpm@osdl.org> <20050324.205902.119922975.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050324.205902.119922975.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix-linuxkernel@fefe.de Precedence: bulk X-list: netdev Content-Length: 786 Lines: 16 I'm using stock 2.6.11.7 now. Here is an strace of some piece of code of mine: socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [12884901889], 4) = 0 bind(3, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 setsockopt(3, SOL_IPV6, IPV6_MULTICAST_LOOP, "\1", 1) = 0 [...] sendto(3, "ncp-lowfat-1.2.2", 16, 0, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "ff02::6e63:7030", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) ff02 is a link-local multicast address. I've bound to ::. How can this fail? link-local should always work, even if no routes are set and no router has been found. Felix From asimshankar@gmail.com Mon Apr 25 13:16:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 13:16:48 -0700 (PDT) Received: from expredir6.cites.uiuc.edu (expredir6.cites.uiuc.edu [128.174.5.97]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PKGgdD000643 for ; Mon, 25 Apr 2005 13:16:43 -0700 Received: from limnos.csrd.uiuc.edu (limnos.csrd.uiuc.edu [130.126.138.58]) by expredir6.cites.uiuc.edu (8.12.11/8.12.11) with ESMTP id j3PKGYFN013068; Mon, 25 Apr 2005 15:16:34 -0500 (CDT) Date: Mon, 25 Apr 2005 14:15:05 -0500 (CDT) From: Asim Shankar X-X-Sender: shankar@limnos.csrd.uiuc.edu To: netdev@oss.sgi.com cc: davem@davemloft.net Subject: [PATCH 2.6.11.7] sch_htb: Drop packet when direct queue is full Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/852/Mon Apr 25 08:12:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 753 Lines: 19 htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is destined for the direct_queue but the direct_queue is full. (Before patch: Erroneously returned NET_XMIT_SUCCESS even though packet was not enqueued) Signed-off-by: Asim Shankar --- linux-2.6.11.7/net/sched/sch_htb.c.orig 2005-04-21 17:40:05.305709014 -0500 +++ linux-2.6.11.7/net/sched/sch_htb.c 2005-04-21 17:35:27.872624173 -0500 @@ -717,6 +717,10 @@ static int htb_enqueue(struct sk_buff *s if (q->direct_queue.qlen < q->direct_qlen) { __skb_queue_tail(&q->direct_queue, skb); q->direct_pkts++; + } else { + kfree_skb(skb); + sch->qstats.drops++; + return NET_XMIT_DROP; } #ifdef CONFIG_NET_CLS_ACT } else if (!cl) { From mchan@broadcom.com Mon Apr 25 15:07:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 15:07:54 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PM7ndD016026 for ; Mon, 25 Apr 2005 15:07:50 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 25 Apr 2005 15:07:29 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 25 Apr 2005 15:07:14 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AUW34853; Mon, 25 Apr 2005 15:07:10 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA22844; Mon, 25 Apr 2005 15:07:09 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Apr 2005 22:07:09 +0000 Received: from rh4 by nt-irva-0741; 25 Apr 2005 14:09:11 -0700 Subject: [PATCH 2.6.12-rc2 2/3] tg3: Refresh hw index in tg3_rx() From: "Michael Chan" To: "David S. Miller" cc: "Arthur Kepner" , netdev@oss.sgi.com In-Reply-To: <1114463061.4917.34.camel@rh4> References: <1114463061.4917.34.camel@rh4> Date: Mon, 25 Apr 2005 14:09:11 -0700 Message-ID: <1114463351.4917.39.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E73B5AA29G2437618-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/853/Mon Apr 25 12:22:22 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 613 Lines: 23 This patch refreshes the hw rx producer in tg3_rx() so that additional work posted by the hardware can be processed. Signed-off-by: Michael Chan diff -Nru c/drivers/net/tg3.c d/drivers/net/tg3.c --- c/drivers/net/tg3.c 2005-04-25 12:32:44.000000000 -0700 +++ d/drivers/net/tg3.c 2005-04-25 12:39:46.000000000 -0700 @@ -2802,6 +2802,12 @@ next_pkt_nopost: sw_idx++; sw_idx %= TG3_RX_RCB_RING_SIZE(tp); + + /* Refresh hw_idx to see if there is new work */ + if (sw_idx == hw_idx) { + hw_idx = tp->hw_status->idx[0].rx_producer; + rmb(); + } } /* ACK the status ring. */ From dlstevens@us.ibm.com Mon Apr 25 15:38:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 15:38:24 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PMcJdD019289; Mon, 25 Apr 2005 15:38:20 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3PMcIAa518016; Mon, 25 Apr 2005 18:38:18 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3PMcIO1266362; Mon, 25 Apr 2005 16:38:18 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3PMcHlc009617; Mon, 25 Apr 2005 16:38:18 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3PMcH6H009612; Mon, 25 Apr 2005 16:38:17 -0600 In-Reply-To: <20050425195736.GB3123@codeblau.de> To: Felix von Leitner Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, "YOSHIFUJI Hideaki / ?$B5HF#1QL@" MIME-Version: 1.0 Subject: Re: IPv6 has trouble assigning an interface X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Mon, 25 Apr 2005 15:38:15 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/25/2005 16:38:17, Serialize complete at 04/25/2005 16:38:17 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/853/Mon Apr 25 12:22:22 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1275 Lines: 34 It's failing because it doesn't know what interface you want to send on, and link-local addresses don't narrow that down any. If you bind to a specific IPv6 address, it'll use that interface (as a work-around). Adding a route for the multicast address may also work (haven't tried). I'd expect using IPV6_MULTICAST_IF would work, but a quick test appears that it doesn't. Specifying a sin6_scope_id as the interface index on the sendto() is another way of specifying the device that doesn't appear to work. So, there may be a bug. Note that if you bind to "::" without doing anything else and send to a link-local address, it can't know what interface you want to send on by the destination, so your program won't control which interface it'll send on. Doing that by binding to a specific interface's IPv6 address works for me (the failure is in assigning the source address when it isn't known). Specifying the device in other ways ought to work, too, so I'll look into this a bit more (as will others, no doubt). +-DLS > ff02 is a link-local multicast address. I've bound to ::. How can this > fail? link-local should always work, even if no routes are set and no > router has been found. > Felix From mchan@broadcom.com Mon Apr 25 15:55:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 15:55:04 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3PMssdD021262 for ; Mon, 25 Apr 2005 15:55:00 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 25 Apr 2005 15:53:41 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 25 Apr 2005 15:54:40 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AUX01489; Mon, 25 Apr 2005 15:54:24 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA06370; Mon, 25 Apr 2005 15:54:24 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Apr 2005 22:54:29 +0000 Received: from rh4 by nt-irva-0741; 25 Apr 2005 14:56:25 -0700 Subject: Re: [PATCH 2.6.12-rc2 3/3] tg3: Fix tg3_restart_ints() From: "Michael Chan" To: "David S. Miller" cc: akepner@sgi.com, netdev@oss.sgi.com In-Reply-To: <20050425151816.1910b2ba.davem@davemloft.net> References: <1114463061.4917.34.camel@rh4> <1114463351.4917.39.camel@rh4> <1114464194.4917.52.camel@rh4> <20050425151816.1910b2ba.davem@davemloft.net> Date: Mon, 25 Apr 2005 14:56:25 -0700 Message-ID: <1114466185.4917.61.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E73AB7F1OC2316774-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/853/Mon Apr 25 12:22:22 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 480 Lines: 14 On Mon, 2005-04-25 at 15:18 -0700, David S. Miller wrote: > All 3 patches applied, looks great. > > The only thing I see is that we might want to put a > rmb() at the beginning of tg3_has_work() since we are > clearing the status block bit right before we call it. > It might not be necessary though. > I think memory barriers are not needed since tg3_has_work() does not depend on what's been written or read before it, other than sblk->status which is a direct dependency. From mallikarjuna.chilakala@intel.com Mon Apr 25 20:18:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Apr 2005 20:18:33 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3Q3ITdD015913 for ; Mon, 25 Apr 2005 20:18:30 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3PJgF0D007324; Mon, 25 Apr 2005 19:42:15 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3PJgBDT010412; Mon, 25 Apr 2005 19:42:15 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042512421405517 ; Mon, 25 Apr 2005 12:42:14 -0700 Date: Mon, 25 Apr 2005 12:42:15 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 11/11] ixgb: Driver version, white space, comments, device id (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/853/Mon Apr 25 12:22:22 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3Q3ITdD015913 X-archive-position: 461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2018 Lines: 54 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -47,7 +47,7 @@ char ixgb_driver_string[] = "Intel(R) PR  #else  #define DRIVERNAPI "-NAPI"  #endif -char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_driver_version[] = "1.0.95-k2"DRIVERNAPI;  char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";    /* ixgb_pci_tbl - PCI Device ID Table @@ -103,6 +103,7 @@ static int ixgb_change_mtu(struct net_de  static int ixgb_set_mac(struct net_device *netdev, void *p);  static irqreturn_t ixgb_intr(int irq, void *data, struct pt_regs *regs);  static boolean_t ixgb_clean_tx_irq(struct ixgb_adapter *adapter); +  #ifdef CONFIG_IXGB_NAPI  static int ixgb_clean(struct net_device *netdev, int *budget);  static boolean_t ixgb_clean_rx_irq(struct ixgb_adapter *adapter, @@ -1253,6 +1254,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter           unsigned int nr_frags = skb_shinfo(skb)->nr_frags;         unsigned int f; +         len -= skb->data_len;           i = tx_ring->next_to_use; @@ -1857,7 +1833,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a                 next_skb = next_buffer->skb;                 prefetch(next_skb);   -                 cleaned = TRUE;                   pci_unmap_single(pdev, @@ -2108,6 +2095,7 @@ ixgb_restore_vlan(struct ixgb_adapter *a  static void ixgb_netpoll(struct net_device *dev)  {         struct ixgb_adapter *adapter = dev->priv; +         disable_irq(adapter->pdev->irq);         ixgb_intr(adapter->pdev->irq, dev, NULL);         enable_irq(adapter->pdev->irq); From herbert@gondor.apana.org.au Tue Apr 26 04:19:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 04:19:20 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QBJ79L011253 for ; Tue, 26 Apr 2005 04:19:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQO5f-0004H8-00; Tue, 26 Apr 2005 21:18:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQO5V-0005Ww-00; Tue, 26 Apr 2005 21:18:45 +1000 Date: Tue, 26 Apr 2005 21:18:45 +1000 To: Jay Vosburgh Cc: "David S. Miller" , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050426111845.GA8968@gondor.apana.org.au> References: <20050426011907.GA13846@gondor.apana.org.au> <200504260411.j3Q4BYke004030@death.nxdomain.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504260411.j3Q4BYke004030@death.nxdomain.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/853/Mon Apr 25 12:22:22 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2211 Lines: 48 On Mon, Apr 25, 2005 at 09:11:33PM -0700, Jay Vosburgh wrote: > > There's a path in the "old" link monitor that does an > SIOCGMIIREG ioctl to read the PHY registers directly; the handler > functions typically do a copy_from_user sort of thing, and there's some > segment switching magic done in bonding because it's calling from the > timer. It will give warnings if DEBUG_SPINLOCK_SLEEP is on and the > bonding "use_carrier=0" is supplied (to turn off netif_carrier detection > and use the MII inspection). There's an IOCTL macro in bonding.h that > does the nasty parts. Indeed. But how can this stuff work at all? Surely if use_carrier is disabled while miimon is enabled we should get a dead-lock as soon as this call chain is run: dev_ioctl => bond_enslave => bond_check_dev_link => slave_dev->ioctl So either nobody ever uses this setup or I'm missing something :) > >The timers would be converted to delayed work. > > It is better, performance-wise, to run the "main" part of the > link monitoring in a timer, and then call out to a work queue only for > those operations that need a context? I.e., how expensive are work > queues compared to timers? For the amount of work that these timers are doing, the overhead is pretty small. It is also gentler on the system when the CPU load goes up. > I've been thinking in terms of rearranging the monitor system to > have, essentially, one or more "inspectors" that check link state, and a > single "executor" that makes link up/down decisions based on input from > the "inspectors." The "executor" (or perhaps one of its minions, if the > executor itself is a timer for performance reasons) would be the work > queue piece, as it would be doing the actual swapping around. This sounds good. One thing to watch out for though is that you need to drop the bond lock between the inspector and the executor. This is so that the executor can acquire the rtnl. The only other alternative would be to always hold the rtnl. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Tue Apr 26 05:59:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 05:59:45 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QCxfU3016361 for ; Tue, 26 Apr 2005 05:59:42 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id A62921C0EB; Tue, 26 Apr 2005 14:59:55 +0200 (CEST) Date: Tue, 26 Apr 2005 14:59:55 +0200 From: Thomas Graf To: Nicolas DICHTEL Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS Message-ID: <20050426125955.GT577@postel.suug.ch> References: <426E06F1.9000105@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426E06F1.9000105@6wind.com> X-Virus-Scanned: ClamAV 0.83/854/Tue Apr 26 05:28:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 769 Lines: 15 * Nicolas DICHTEL <426E06F1.9000105@6wind.com> 2005-04-26 11:16 > I set CONFIG_NET_SCH_CLK_GETTIMEOFDAY in my kernel. The macro > PSCHED_TDIFF_SAFE calculates > the difference between two timestamps and uses the function > psched_tod_diff() to do this. > If the clock is readjusted (due to ntp for example), this function can > return a negative number > (if bound > 1000000) and then the flow is blocked by the kernel. Am I > right ? do_gettimeofday takes care of ntp adjustments so we _should_ be safe, however, it might be wise to enforce a range of 0..bound instead of INT_MIN..bound because qdiscs like red are relying on this. Assuming we have a delta of -4 seconds and return -4e6 red will horribly crash when acccessing the array with idle_time>>cell_log. From kaber@trash.net Tue Apr 26 06:18:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 06:18:11 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QDHwVU018530 for ; Tue, 26 Apr 2005 06:17:59 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DQPwN-0001p5-4l; Tue, 26 Apr 2005 15:17:27 +0200 Message-ID: <426E3F67.8090006@trash.net> Date: Tue, 26 Apr 2005 15:17:27 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Yair@arx.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: Re-routing packets via netfilter (ip_rt_bug) References: <426D0CB9.4060500@trash.net> <20050425213400.GB29288@gondor.apana.org.au> <426D8672.1030001@trash.net> <20050426003925.GA13650@gondor.apana.org.au> In-Reply-To: <20050426003925.GA13650@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/854/Tue Apr 26 05:28:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 224 Lines: 9 Herbert Xu wrote: > Makes sense. But what about the case where saddr is foreign but > daddr is broadcast/multicast? Looks like we have no choice but to also use saddr=0 and ip_route_output() in this case. Regards Patrick From ak@muc.de Tue Apr 26 06:40:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 06:40:43 -0700 (PDT) Received: from one.firstfloor.org ([213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QDeaZf020964 for ; Tue, 26 Apr 2005 06:40:36 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 08704D033E; Tue, 26 Apr 2005 15:40:23 +0200 (CEST) To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: is UDP_CORK "real" References: <426833F0.9010803@hp.com> From: Andi Kleen Date: Tue, 26 Apr 2005 15:40:22 +0200 In-Reply-To: <426833F0.9010803@hp.com> (Rick Jones's message of "Thu, 21 Apr 2005 16:14:56 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/854/Tue Apr 26 05:28:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 926 Lines: 20 Rick Jones writes: > today? While man tcp described TCP_CORK, on the two places I've > checked thusfar, man udp does not describe UDP_CORK. I'm not sure if > that means UDP_CORK is "unreal" or just that the udp manpage needs > repair (or was out of date on my systems). AFAIK nobody has been updating the protocol manpages since I stopped doing so several years ago when they were included into the standard manpages. There are lots of missing features etc. that could be documented, the BUGS sections are usually out of date etc. It is roughly at the state of early 2.3. There is also unfortunately no policy to require a manpage update when a new feature is added to the kernel. Some manpages have been even never fully written like the ipv6 manpage. Perhaps someone is interested in updating all these? It unfortunately needs quite a lot of RTFS to figure out what the code actually does. -Andi From ak@muc.de Tue Apr 26 06:47:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 06:47:12 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QDl8Zf021764 for ; Tue, 26 Apr 2005 06:47:08 -0700 Received: by one.firstfloor.org (Postfix, from userid 502) id 6BF98D033E; Tue, 26 Apr 2005 15:47:07 +0200 (CEST) To: Matt Mackall Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH] Fix deadlock in netconsole with no carrier References: <20050419135350.GH7715@wotan.suse.de> <20050419170650.GW21897@waste.org> From: Andi Kleen Date: Tue, 26 Apr 2005 15:47:07 +0200 In-Reply-To: <20050419170650.GW21897@waste.org> (Matt Mackall's message of "Tue, 19 Apr 2005 10:06:50 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/854/Tue Apr 26 05:28:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1609 Lines: 45 Matt Mackall writes: [sorry for the late answer, but you dont seem to have cced the answer to me so I lost it until now] > On Tue, Apr 19, 2005 at 03:53:50PM +0200, Andi Kleen wrote: >> >> I got a deadlock at boot with netconsole when the netword card >> did not have a cable connected. This patch fixes this by limiting >> the number of retries. > > It should be waiting for carrier detect before proceeding. What NIC is that? e1000 > I'm sure five retries is not enough. Well, infinite is definitely too many. And the early netconsole code already waits for carrier up, so waiting even longer in the actual write does not make much sense to me. The problem with spinning longer here is that when you boot on a system with no carrier but netconsole configured it will waste a lot of time uselessly spinning/polling here all the time. It is better to end this early. In theory you could do a more clever backoff scheme and note when a device is always down, but I think the short retry combined with the long wait at early netconsole init is nearly equivalent. Without this patch my setup doesnt even boot so I would appreciate if the patch could be applied. > >> Also when we run into the device spinlock dont poll all the time, >> just spin. > > Two patches? Again, I don't think we should give up so easily. For the device spinlock polling is useless because the NIC is not actually out of resources, all you need to do is to spin. Polling too is a waste of CPU time. In case polling is really needed (in case of a race) it will be retried once the spinlock is free. -Andi From Yair@arx.com Tue Apr 26 07:37:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 07:37:21 -0700 (PDT) Received: from post.arx.com (post.arx.com [212.25.66.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QEauZf025410 for ; Tue, 26 Apr 2005 07:36:58 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Re-routing packets via netfilter (ip_rt_bug) X-Mimeole: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 26 Apr 2005 17:39:31 +0200 Message-ID: <4151C0F9B9C25C47B3328922A6297A3286CFA9@post.arx.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-routing packets via netfilter (ip_rt_bug) Thread-Index: AcVKATCdrAz8cyfbSYS32kx8Bpg6oQAdLglg From: "Yair Itzhaki" To: "Herbert Xu" , "Patrick McHardy" Cc: , , X-Virus-Scanned: ClamAV 0.83/854/Tue Apr 26 05:28:25 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3QEauZf025410 X-archive-position: 476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Yair@arx.com Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 36 I'm afraid I'm not following you. Where did you want to set saddr=0 ? Yair > -----Original Message----- > From: Herbert Xu [mailto:herbert@gondor.apana.org.au] > Sent: Tuesday, April 26, 2005 02:39 > To: Patrick McHardy > Cc: Yair Itzhaki; linux-kernel@vger.kernel.org; > netfilter-devel@lists.netfilter.org; netdev@oss.sgi.com > Subject: Re: Re-routing packets via netfilter (ip_rt_bug) > > > On Tue, Apr 26, 2005 at 02:08:18AM +0200, Patrick McHardy wrote: > > Herbert Xu wrote: > > >You're right. But then we can't call ip_route_output in the case > > >where saddr is foreign but daddr is local. Nor can we call > > >ip_route_input since the output will be ip_rt_bug. > > > > In that case we need to use saddr=0, which shouldn't make > any difference > > with sane routing. > > Makes sense. But what about the case where saddr is foreign but > daddr is broadcast/multicast? > > Cheers, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > From nicolas.dichtel@6wind.com Tue Apr 26 07:57:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 07:58:02 -0700 (PDT) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QEvtZf027258 for ; Tue, 26 Apr 2005 07:57:56 -0700 Received: from [10.16.0.135] (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 265F624F; Tue, 26 Apr 2005 16:57:54 +0200 (CEST) Message-ID: <426E56DC.7000108@6wind.com> Date: Tue, 26 Apr 2005 16:57:32 +0200 From: Nicolas DICHTEL Reply-To: nicolas.dichtel@6wind.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> In-Reply-To: <20050426125955.GT577@postel.suug.ch> Content-Type: multipart/mixed; boundary="------------040304080005040803070804" X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nicolas.dichtel@6wind.com Precedence: bulk X-list: netdev Content-Length: 1890 Lines: 58 This is a multi-part message in MIME format. --------------040304080005040803070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas Graf wrote: >* Nicolas DICHTEL <426E06F1.9000105@6wind.com> 2005-04-26 11:16 > > >>I set CONFIG_NET_SCH_CLK_GETTIMEOFDAY in my kernel. The macro >>PSCHED_TDIFF_SAFE calculates >>the difference between two timestamps and uses the function >>psched_tod_diff() to do this. >>If the clock is readjusted (due to ntp for example), this function can >>return a negative number >>(if bound > 1000000) and then the flow is blocked by the kernel. Am I >>right ? >> >> > >do_gettimeofday takes care of ntp adjustments so we _should_ be safe, >however, it might be wise to enforce a range of 0..bound instead of >INT_MIN..bound because qdiscs like red are relying on this. Assuming >we have a delta of -4 seconds and return -4e6 red will horribly >crash when acccessing the array with idle_time>>cell_log. > > > You can have the same kind of problem with a ingress filter. I propose the following patch to fix the range to 0..bound [SCHED] Fix range in psched_tod_diff() to 0..bound Signed-off-by: Nicolas Dichtel --------------040304080005040803070804 Content-Type: text/plain; name="x.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x.diff" diff -Nru linux-2.6-a/include/net/pkt_sched.h linux-2.6-b/include/net/pkt_sched.h --- linux-2.6-a/include/net/pkt_sched.h 2005-04-26 15:45:07.074124664 +0200 +++ linux-2.6-b/include/net/pkt_sched.h 2005-04-26 15:47:26.215971888 +0200 @@ -140,7 +140,7 @@ if (bound <= 1000000 || delta_sec > (0x7FFFFFFF/1000000)-1) return bound; delta = delta_sec * 1000000; - if (delta > bound) + if (delta > bound || delta < 0) delta = bound; return delta; } --------------040304080005040803070804-- From dmitry.torokhov@gmail.com Tue Apr 26 08:57:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 08:58:06 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QFvwZf004834 for ; Tue, 26 Apr 2005 08:57:58 -0700 Received: by rproxy.gmail.com with SMTP id r35so1274762rna for ; Tue, 26 Apr 2005 08:57:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QDNsHCR4eiINgf8YjK1JLC11Vv8zqTzLm6OvcAv8sHrwGOTpKUMP0EtkFpZiHsMD+V83EyMLdlcpidalNUuVUGccazsjuMpf28JTn0S66iQxb+9Qk0uVLqmSIdGFxQYMfdvaJGvwfm0Sa2MY+yCHPTaZL4z+tYP0btAzzqr7C1w= Received: by 10.38.67.48 with SMTP id p48mr7792364rna; Tue, 26 Apr 2005 08:57:56 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 26 Apr 2005 08:57:55 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 10:57:55 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: Evgeniy Polyakov Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050411125932.GA19538@uganda.factory.vocord.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3QFvwZf004834 X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 1285 Lines: 35 Hi Evgeniy, On 4/11/05, Evgeniy Polyakov wrote: > /*****************************************/ > Kernel Connector. > /*****************************************/ ... > +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) > +{ > + struct cn_callback_entry *__cbq; > + struct cn_dev *dev = &cdev; > + int found = 0; > + > + spin_lock_bh(&dev->cbdev->queue_lock); > + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > + __cbq->cb->priv = msg; > + > + __cbq->ddata = data; > + __cbq->destruct_data = destruct_data; > + > + queue_work(dev->cbdev->cn_queue, &__cbq->work); It looks like there is a problem with the code. As far as I can see there is only one cn_callback_entry associated with each callback. So, if someone sends netlink messages with the same id at a high enough rate (so cbdev's work queue does not get a chance to get scheduled and process pending requests) ddata and the destructor will be overwritten which can lead to memory leaks and non-delivery of some messages. Am I missing something? -- Dmitry From johnpol@2ka.mipt.ru Tue Apr 26 09:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 09:25:42 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QGPTZf007476 for ; Tue, 26 Apr 2005 09:25:30 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3QGOo7N015784; Tue, 26 Apr 2005 20:24:50 +0400 Date: Tue, 26 Apr 2005 20:24:37 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 20:24:51 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1675 Lines: 47 On Tue, 26 Apr 2005 10:57:55 -0500 Dmitry Torokhov wrote: > Hi Evgeniy, > > On 4/11/05, Evgeniy Polyakov wrote: > > /*****************************************/ > > Kernel Connector. > > /*****************************************/ > ... > > +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) > > +{ > > + struct cn_callback_entry *__cbq; > > + struct cn_dev *dev = &cdev; > > + int found = 0; > > + > > + spin_lock_bh(&dev->cbdev->queue_lock); > > + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > > + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > > + __cbq->cb->priv = msg; > > + > > + __cbq->ddata = data; > > + __cbq->destruct_data = destruct_data; > > + > > + queue_work(dev->cbdev->cn_queue, &__cbq->work); > > It looks like there is a problem with the code. As far as I can see > there is only one cn_callback_entry associated with each callback. So, > if someone sends netlink messages with the same id at a high enough > rate (so cbdev's work queue does not get a chance to get scheduled and > process pending requests) ddata and the destructor will be overwritten > which can lead to memory leaks and non-delivery of some messages. > > Am I missing something? Connector needs to check return value here - zero means that work was already queued and we must free shared skb. There may not be the same work with different data. > -- > Dmitry Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From johnpol@2ka.mipt.ru Tue Apr 26 09:31:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 09:31:13 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QGV6Zf008930 for ; Tue, 26 Apr 2005 09:31:07 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3QGUZ4p019410; Tue, 26 Apr 2005 20:30:35 +0400 Date: Tue, 26 Apr 2005 20:30:23 +0400 From: Evgeniy Polyakov To: johnpol@2ka.mipt.ru Cc: dtor_core@ameritech.net, dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426203023.378e4831@zanzibar.2ka.mipt.ru> In-Reply-To: <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 20:30:36 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2355 Lines: 72 On Tue, 26 Apr 2005 20:24:37 +0400 Evgeniy Polyakov wrote: > On Tue, 26 Apr 2005 10:57:55 -0500 > Dmitry Torokhov wrote: > > > Hi Evgeniy, > > > > On 4/11/05, Evgeniy Polyakov wrote: > > > /*****************************************/ > > > Kernel Connector. > > > /*****************************************/ > > ... > > > +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) > > > +{ > > > + struct cn_callback_entry *__cbq; > > > + struct cn_dev *dev = &cdev; > > > + int found = 0; > > > + > > > + spin_lock_bh(&dev->cbdev->queue_lock); > > > + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > > > + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > > > + __cbq->cb->priv = msg; > > > + > > > + __cbq->ddata = data; > > > + __cbq->destruct_data = destruct_data; > > > + > > > + queue_work(dev->cbdev->cn_queue, &__cbq->work); > > > > It looks like there is a problem with the code. As far as I can see > > there is only one cn_callback_entry associated with each callback. So, > > if someone sends netlink messages with the same id at a high enough > > rate (so cbdev's work queue does not get a chance to get scheduled and > > process pending requests) ddata and the destructor will be overwritten > > which can lead to memory leaks and non-delivery of some messages. > > > > Am I missing something? > > Connector needs to check return value here - zero means > that work was already queued and we must free shared skb. > > There may not be the same work with different data. Here is the patch: * looking for johnpol@2ka.mipt.ru-2004/connector--main--0--patch-52 to compare with * comparing to johnpol@2ka.mipt.ru-2004/connector--main--0--patch-52 M connector.c * modified files --- orig/drivers/connector/connector.c +++ mod/drivers/connector/connector.c @@ -151,8 +151,8 @@ __cbq->ddata = data; __cbq->destruct_data = destruct_data; - queue_work(dev->cbdev->cn_queue, &__cbq->work); - found = 1; + if (queue_work(dev->cbdev->cn_queue, &__cbq->work)) + found = 1; break; } } Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From dmitry.torokhov@gmail.com Tue Apr 26 10:31:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 10:32:13 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QHVwZf014903 for ; Tue, 26 Apr 2005 10:31:58 -0700 Received: by rproxy.gmail.com with SMTP id r35so7234rna for ; Tue, 26 Apr 2005 10:31:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PopERRu9ENjqO8CO2cxcoiiNtGqFPPxEqF0MNowRejHijuTffUb9ce6y0SWwRHDhFD406EwpTVxKeOJAPElHPl7LwkeXqTMu9Mdb3nb0u19FS9aRbM58AU2tQqOeJKZDcjYEqNbgbEiOwBWWBkIwbq0CucIoV24lw261fAp1LJ0= Received: by 10.38.72.63 with SMTP id u63mr30794rna; Tue, 26 Apr 2005 10:31:58 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 26 Apr 2005 10:31:58 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 12:31:58 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3QHVwZf014903 X-archive-position: 483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 2095 Lines: 53 On 4/26/05, Evgeniy Polyakov wrote: > On Tue, 26 Apr 2005 10:57:55 -0500 > Dmitry Torokhov wrote: > > > Hi Evgeniy, > > > > On 4/11/05, Evgeniy Polyakov wrote: > > > /*****************************************/ > > > Kernel Connector. > > > /*****************************************/ > > ... > > > +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) > > > +{ > > > + struct cn_callback_entry *__cbq; > > > + struct cn_dev *dev = &cdev; > > > + int found = 0; > > > + > > > + spin_lock_bh(&dev->cbdev->queue_lock); > > > + list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > > > + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > > > + __cbq->cb->priv = msg; > > > + > > > + __cbq->ddata = data; > > > + __cbq->destruct_data = destruct_data; > > > + > > > + queue_work(dev->cbdev->cn_queue, &__cbq->work); > > > > It looks like there is a problem with the code. As far as I can see > > there is only one cn_callback_entry associated with each callback. So, > > if someone sends netlink messages with the same id at a high enough > > rate (so cbdev's work queue does not get a chance to get scheduled and > > process pending requests) ddata and the destructor will be overwritten > > which can lead to memory leaks and non-delivery of some messages. > > > > Am I missing something? > > Connector needs to check return value here - zero means > that work was already queued and we must free shared skb. > > There may not be the same work with different data. > Ugh, that really blows. Now every user of a particular message type has to coordinate efforts with other users of the same message type... Imability to "fire and forget" undermines usefulness of whole connector. How will you for example implement hotplug notification over connector? Have kobject_hotplug wait and block other instances? But wait on what? -- Dmitry From dmitry.torokhov@gmail.com Tue Apr 26 10:34:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 10:34:16 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QHYDZf015394 for ; Tue, 26 Apr 2005 10:34:13 -0700 Received: by rproxy.gmail.com with SMTP id r35so7621rna for ; Tue, 26 Apr 2005 10:34:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ihXh3umBudXGuu9cMrdW2Q1G02WgIif8+vA0SkxfH6FkOBYamBo+E7U/rMg4HYu1Sqis2iX8FscsWH//oBRPIqGDRF3cQpqmdTJ1EcecxN0WhPxSBK4Hqn9Tu2ypDiXxkrqyOHmdLwpQST4kOBSS5467GXYOrFYutDEoxPWMsiE= Received: by 10.38.76.61 with SMTP id y61mr11444rna; Tue, 26 Apr 2005 10:34:13 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 26 Apr 2005 10:34:13 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 12:34:13 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050426203023.378e4831@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426203023.378e4831@zanzibar.2ka.mipt.ru> X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3QHYDZf015394 X-archive-position: 484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 846 Lines: 24 On 4/26/05, Evgeniy Polyakov wrote: > > --- orig/drivers/connector/connector.c > +++ mod/drivers/connector/connector.c > @@ -151,8 +151,8 @@ > __cbq->ddata = data; > __cbq->destruct_data = destruct_data; > > - queue_work(dev->cbdev->cn_queue, &__cbq->work); > - found = 1; > + if (queue_work(dev->cbdev->cn_queue, &__cbq->work)) > + found = 1; > break; What does it help exactly? By the time you checked result of queue_work you have already corrupted work structure wuth the new data (and probably destructor). Also, where is the rest of the code? Should we notify caller that cn_netlink_send has dropped the message? And how do we do that? -- Dmitry From johnpol@2ka.mipt.ru Tue Apr 26 11:04:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 11:04:43 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QI4YZf018918 for ; Tue, 26 Apr 2005 11:04:35 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3QI46Wm011165; Tue, 26 Apr 2005 22:04:07 +0400 Date: Tue, 26 Apr 2005 22:03:54 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426220354.5dd619bf@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 22:04:10 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 907 Lines: 29 On Tue, 26 Apr 2005 12:31:58 -0500 Dmitry Torokhov wrote: > > There may not be the same work with different data. > > > > Ugh, that really blows. Now every user of a particular message type > has to coordinate efforts with other users of the same message type... > > Imability to "fire and forget" undermines usefulness of whole > connector. How will you for example implement hotplug notification > over connector? Have kobject_hotplug wait and block other instances? > But wait on what? This is a simple load balancing schema. Netlink messages may be dropped in socket queue when they are bing delivered to userspace - this is the same - if work queue can not be scheduled, message will be dropped, but in this case userspace also can not be scheduled and message will be dropped. > -- > Dmitry > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From johnpol@2ka.mipt.ru Tue Apr 26 11:08:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 11:08:14 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QI80Zf019629 for ; Tue, 26 Apr 2005 11:08:00 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with SMTP id j3QI7Qro013047; Tue, 26 Apr 2005 22:07:29 +0400 Date: Tue, 26 Apr 2005 22:07:13 +0400 From: Evgeniy Polyakov To: dtor_core@ameritech.net Cc: dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426220713.7915e036@zanzibar.2ka.mipt.ru> In-Reply-To: References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426203023.378e4831@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 22:07:29 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2143 Lines: 62 On Tue, 26 Apr 2005 12:34:13 -0500 Dmitry Torokhov wrote: > On 4/26/05, Evgeniy Polyakov wrote: > > > > --- orig/drivers/connector/connector.c > > +++ mod/drivers/connector/connector.c > > @@ -151,8 +151,8 @@ > > __cbq->ddata = data; > > __cbq->destruct_data = destruct_data; > > > > - queue_work(dev->cbdev->cn_queue, &__cbq->work); > > - found = 1; > > + if (queue_work(dev->cbdev->cn_queue, &__cbq->work)) > > + found = 1; > > break; > > What does it help exactly? By the time you checked result of > queue_work you have already corrupted work structure wuth the new data > (and probably destructor). > > Also, where is the rest of the code? Should we notify caller that > cn_netlink_send has dropped the message? And how do we do that? Yes, I found it too. Following patch should be the solution: --- orig/drivers/connector/connector.c +++ mod/drivers/connector/connector.c @@ -146,13 +146,16 @@ spin_lock_bh(&dev->cbdev->queue_lock); list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { - __cbq->cb->priv = msg; + + if (!test_bit(0, &work->pending)) { + __cbq->cb->priv = msg; - __cbq->ddata = data; - __cbq->destruct_data = destruct_data; + __cbq->ddata = data; + __cbq->destruct_data = destruct_data; - if (queue_work(dev->cbdev->cn_queue, &__cbq->work)) - found = 1; + if (queue_work(dev->cbdev->cn_queue, &__cbq->work)) + found = 1; + } break; } } > -- > Dmitry > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From dmitry.torokhov@gmail.com Tue Apr 26 11:20:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Apr 2005 11:20:15 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3QIK9Zf022145 for ; Tue, 26 Apr 2005 11:20:09 -0700 Received: by rproxy.gmail.com with SMTP id r35so17017rna for ; Tue, 26 Apr 2005 11:20:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G/EcQb+mEW3M1rHFiiM31e1Btl30beC0s4Hqiv48zGUehE5m3fkqqZrfqDbbAnDPnEGDqrZHToyrBcO3OSi8MDxVK8jtIQkWShYwsoWQaY1oHhXejXFbhEN0yIBkpd69wsFUogSjOaII3ASzc+neIzA0fHLdQXN6cNdPARoI3Uc= Received: by 10.38.74.73 with SMTP id w73mr84627rna; Tue, 26 Apr 2005 11:20:08 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 26 Apr 2005 11:20:08 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 13:20:08 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050426220713.7915e036@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426203023.378e4831@zanzibar.2ka.mipt.ru> <20050426220713.7915e036@zanzibar.2ka.mipt.ru> X-Virus-Scanned: ClamAV 0.83/855/Tue Apr 26 06:40:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3QIK9Zf022145 X-archive-position: 489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 990 Lines: 27 On 4/26/05, Evgeniy Polyakov wrote: > Yes, I found it too. > Following patch should be the solution: > > --- orig/drivers/connector/connector.c > +++ mod/drivers/connector/connector.c > @@ -146,13 +146,16 @@ > spin_lock_bh(&dev->cbdev->queue_lock); > list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) { > if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { > - __cbq->cb->priv = msg; > + > + if (!test_bit(0, &work->pending)) { > + __cbq->cb->priv = msg; > > - __cbq->ddata = data; > - __cbq->destruct_data = destruct_data; > + __cbq->ddata = data; > + __cbq->destruct_data = destruct_data; > Still not good enough - work->pending bit gets cleared when work has been scheduled, but before executing payload. You still have the race. -- Dmitry From nicolas.dichtel@6wind.com Wed Apr 27 03:51:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 03:52:02 -0700 (PDT) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RApm5Z008478 for ; Wed, 27 Apr 2005 03:51:49 -0700 Received: from [10.16.0.135] (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id A3BB7228; Wed, 27 Apr 2005 09:45:09 +0200 (CEST) Message-ID: <426F42F0.9020609@6wind.com> Date: Wed, 27 Apr 2005 09:44:48 +0200 From: Nicolas DICHTEL Reply-To: nicolas.dichtel@6wind.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> In-Reply-To: <20050426191454.GU577@postel.suug.ch> Content-Type: multipart/mixed; boundary="------------000304030909050602090302" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nicolas.dichtel@6wind.com Precedence: bulk X-list: netdev Content-Length: 1806 Lines: 57 This is a multi-part message in MIME format. --------------000304030909050602090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >Yes I agree, it doesn't really matter what value we return and `bound' >is most likely to be correct. I think we should also fix the unlikely >but still possible case when tv1.tv_usec is slightly smaller than >tv2.tv_usec. I know it is very unlikely but do_gettimeofday really >is not that reliable and we have users which rely on a positive >delta. Can you extend your patch to return abs(delta) for case 0 >in PSCHED_TDIFF_SAFE? >- >To unsubscribe from this list: send the line "unsubscribe linux-net" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html > > You're right. Here is the new patch. [SCHED] Fix range in PSCHED_TDIFF_SAFE to 0..bound Signed-off-by: Nicolas Dichtel --------------000304030909050602090302 Content-Type: text/plain; name="x.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x.diff" diff -Nru linux-2.6-a/include/net/pkt_sched.h linux-2.6-b/include/net/pkt_sched.h --- linux-2.6-a/include/net/pkt_sched.h 2005-04-26 15:45:07.000000000 +0200 +++ linux-2.6-b/include/net/pkt_sched.h 2005-04-27 09:36:23.421634576 +0200 @@ -140,7 +140,7 @@ if (bound <= 1000000 || delta_sec > (0x7FFFFFFF/1000000)-1) return bound; delta = delta_sec * 1000000; - if (delta > bound) + if (delta > bound || delta < 0) delta = bound; return delta; } @@ -156,7 +156,8 @@ __delta += 1000000; \ case 1: \ __delta += 1000000; \ - case 0: ; \ + case 0: \ + __delta = abs(__delta); \ } \ __delta; \ }) --------------000304030909050602090302-- From dtor_core@ameritech.net Wed Apr 27 04:13:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:13:30 -0700 (PDT) Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RBDP5Z013605 for ; Wed, 27 Apr 2005 04:13:25 -0700 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.253.36.236 with plain) by smtp816.mail.sc5.yahoo.com with SMTP; 27 Apr 2005 05:46:42 -0000 From: Dmitry Torokhov To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Date: Wed, 27 Apr 2005 00:46:40 -0500 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan References: <20050411125932.GA19538@uganda.factory.vocord.ru> <200504270016.34002.dtor_core@ameritech.net> <1114579926.14282.16.camel@uganda> In-Reply-To: <1114579926.14282.16.camel@uganda> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504270046.41042.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 1352 Lines: 30 On Wednesday 27 April 2005 00:32, Evgeniy Polyakov wrote: > On Wed, 2005-04-27 at 00:16 -0500, Dmitry Torokhov wrote: > > On Tuesday 26 April 2005 23:06, Evgeniy Polyakov wrote: > > > Let's clarify that we are talking about userspace->kernelspace > > > direction. > > > Only for that messages callback path is invoked. > > > > What about kernelspace->userspace or kernelspace->kernelspace? > > From what I see nothing stops kernel code from calling cn_netlink_send, > > in fact your cbus does exactly that. So I am confused why you singled > > out userspace->kernelspace direction. > > You miunderstand the code - > cn_netlink_send() never ends up in callback invocation, > it can only deliver messages in kernelspace->userspace direction. > kernelspace->userspace direction ends up adding buffer into > socket queue, from which userspace may read data using recv() system > call. Yes, you are right, sorry. I missed the fact that message is not injected into callback queue. Hmm, might be useful if it was, for implementing various kinds of in-kernel notifications. Other thing to consider - even if there is explicit schedule on userspace-> kernelspace path there is no quarantee that connector thread will be scheduled before userspace - userspace could be higher-priority bursty task. Although this scenario it not likely I guess. -- Dmitry From tommy.christensen@tpack.net Wed Apr 27 04:18:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:18:33 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RBIP5Z015567 for ; Wed, 27 Apr 2005 04:18:25 -0700 Received: (qmail 26756 invoked from network); 26 Apr 2005 21:51:34 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.5) by 0 with SMTP; 26 Apr 2005 21:51:34 -0000 Message-ID: <426EB84C.90307@tpack.net> Date: Tue, 26 Apr 2005 23:53:16 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH] net: Disable queueing when carrier is lost Content-Type: multipart/mixed; boundary="------------060208070608070201020509" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 3128 Lines: 94 This is a multi-part message in MIME format. --------------060208070608070201020509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A while back we had a very long thread about the queueing behavior of netdevices in a loss-of-carrier situation. This thread had the poetic subject: [patch 4/10] s390: network driver. The executive summary: Certain network drivers call netif_stop_queue() when they detect a loss of carrier. This has some unfortunate effects on the current networking stack, since packets are now being queued up at the qdisc level for an unbound period of time: *) the socket send buffer may be exhausted, preventing transmission to all devices (from this particular socket) *) resources are held "indefinitely": memory, socket/dst/module refcounts *) when carrier is re-established stale packets are sent out on the network, which could have undesirable effects The best solution seems to be to simply disable the queueing at the qdisc layer when this situation arises. That approach has been implemented in the patch below. Hasso Tepper reports succesfull testing of the patch with Quagga. Signed-off-by: Tommy S. Christensen --------------060208070608070201020509 Content-Type: text/plain; name="carrier.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carrier.patch" diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-04-26 22:19:22.939393488 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,9 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev) && + dev->qdisc_sleeping != &noop_qdisc) + dev_activate(dev); netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-04-26 22:19:22.939393488 +0200 @@ -185,6 +185,7 @@ static void dev_watchdog(unsigned long arg) { struct net_device *dev = (struct net_device *)arg; + int check_carrier = 0; spin_lock(&dev->xmit_lock); if (dev->qdisc != &noop_qdisc) { @@ -198,10 +199,23 @@ } if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo)) dev_hold(dev); - } + } else + check_carrier = 1; } spin_unlock(&dev->xmit_lock); + if (check_carrier) { + spin_lock(&dev->queue_lock); + if (!netif_carrier_ok(dev) && netif_queue_stopped(dev)) { + struct Qdisc *qdisc; + + qdisc = dev->qdisc; + dev->qdisc = &noop_qdisc; + qdisc_reset(qdisc); + } + spin_unlock(&dev->queue_lock); + } + dev_put(dev); } --------------060208070608070201020509-- From mtk-lkml@gmx.net Wed Apr 27 04:33:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:33:38 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RB7C5Z011847 for ; Wed, 27 Apr 2005 04:07:13 -0700 Received: (qmail 21126 invoked by uid 0); 27 Apr 2005 08:20:28 -0000 Received: from 62.245.207.82 by www42.gmx.net with HTTP; Wed, 27 Apr 2005 10:20:28 +0200 (MEST) Date: Wed, 27 Apr 2005 10:20:28 +0200 (MEST) From: "Michael Kerrisk" To: Andi Kleen Cc: rick.jones2@hp.com, netdev@oss.sgi.com MIME-Version: 1.0 References: Subject: Re: is UDP_CORK "real" X-Priority: 3 (Normal) X-Authenticated: #23581172 Message-ID: <16241.1114590028@www42.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lkml@gmx.net Precedence: bulk X-list: netdev Content-Length: 1580 Lines: 41 > Rick Jones writes: > > today? While man tcp described TCP_CORK, on the two places I've > > checked thusfar, man udp does not describe UDP_CORK. I'm not sure if > > that means UDP_CORK is "unreal" or just that the udp manpage needs > > repair (or was out of date on my systems). > > AFAIK nobody has been updating the protocol manpages since I stopped > doing so several years ago when they were included into the > standard manpages. There are lots of missing features > etc. that could be documented, the BUGS sections are usually > out of date etc. It is roughly at the state of early 2.3. I make ocassional changes, as far as my knowledge permits. But there's lots that I don't know... > There is also unfortunately no policy to require a manpage > update when a new feature is added to the kernel. Yes, unfortunately. > Some manpages have been even never fully written like the ipv6 manpage. > Perhaps someone is interested in updating all these? It unfortunately > needs quite a lot of RTFS to figure out what the code actually does. I welcome all such patches, which will go into the standard man-pages set (get the latest set at ftp://ftp.win.tue.nl/pub/linux-local/manpages/ ). Please send patches to: mtk-manpages@gmx.net In terms of checking people's input, it helps if you identify how the knowledge going into a patch was obtained, and perhaps point me at some relevant parts of the source. Cheers, Michael -- +++ GMX - die erste Adresse für Mail, Message, More +++ 10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail From herbert@gondor.apana.org.au Wed Apr 27 04:36:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:36:11 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RBa15Z023191 for ; Wed, 27 Apr 2005 04:36:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQkpW-0005CN-00; Wed, 27 Apr 2005 21:35:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQkpS-0005qd-00; Wed, 27 Apr 2005 21:35:42 +1000 Date: Wed, 27 Apr 2005 21:35:42 +1000 To: Jozsef Kadlecsik Cc: Patrick McHardy , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, Yair@arx.com, linux-kernel@vger.kernel.org Subject: Re: Re-routing packets via netfilter (ip_rt_bug) Message-ID: <20050427113542.GB22433@gondor.apana.org.au> References: <20050425213400.GB29288@gondor.apana.org.au> <426D8672.1030001@trash.net> <20050426003925.GA13650@gondor.apana.org.au> <426E3F67.8090006@trash.net> <20050426232857.GA18358@gondor.apana.org.au> <426EE350.1070902@trash.net> <20050427010730.GA18919@gondor.apana.org.au> <426F68C5.4010109@trash.net> <20050427103056.GB22099@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1046 Lines: 24 On Wed, Apr 27, 2005 at 12:41:01PM +0200, Jozsef Kadlecsik wrote: > > > > > > Forwarded packets can't have any NAT manips in LOCAL_OUT, so it > > > should work. I'm not sure about it though because it would be > > > the only place where packets just appear in FORWARD, usually > > > all packets enters through PRE_ROUTING or LOCAL_OUT. > > > > It's also the only place where we generate a packet with a non-local > > source address :) > > Besides the REJECT target, TARPIT in patch-o-matic-ng also generates > packets with non-local source addresses. We cannot assume that REJECT is > the only one which can create such packets. Any reason why it can't be fed through the FORWARD chain as opposed to LOCAL_OUT? In general, is there anything that's generating packets with foreign addresses that can't be fed through FORWARD? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dmitry.torokhov@gmail.com Wed Apr 27 04:36:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:36:37 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RB6c5Z011731 for ; Wed, 27 Apr 2005 04:06:38 -0700 Received: by rproxy.gmail.com with SMTP id r35so144652rna for ; Wed, 27 Apr 2005 04:06:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mlh2DoaZjRDkD2utUnzk1zgSN/oB5GKAM0uaGseI0f+58wsZROwKASxMQGuYmjq9JRZmfUoDY/fFP73BOr+4hNlAch3GbEbEy2c9p8EnH3n36W9dKzl1lqivSaG7pQ/qQIzpmq99HQsElao6pvgwEprsWSObnptDcNs0golqyyo= Received: by 10.38.12.8 with SMTP id 8mr125171rnl; Tue, 26 Apr 2005 12:06:36 -0700 (PDT) Received: by 10.38.24.62 with HTTP; Tue, 26 Apr 2005 12:06:36 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 14:06:36 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: johnpol@2ka.mipt.ru Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Cc: netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan In-Reply-To: <20050426224833.3b6a0792@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426203023.378e4831@zanzibar.2ka.mipt.ru> <20050426220713.7915e036@zanzibar.2ka.mipt.ru> <20050426223126.37b7aea1@zanzibar.2ka.mipt.ru> <20050426224833.3b6a0792@zanzibar.2ka.mipt.ru> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3RB6c5Z011731 X-archive-position: 189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 1254 Lines: 31 On 4/26/05, Evgeniy Polyakov wrote: > On Tue, 26 Apr 2005 13:42:10 -0500 > Dmitry Torokhov wrote: > > Yes, that woudl work, although I would urge you to implement a message > > queue for callbacks (probably limit it to 1000 messages or so) to > > allow bursting. > > It already exist, btw, but not exactly in that way - > we have skb queue, which can not be filled from userspace > if pressure is so strong so work queue can not be scheduled. > It is of course different and is influenced by other things > but it handles bursts quite well - it was tested on both > SMP and UP machines with continuous flows of forks with > shape addon of new running tasks [both fith fork bomb and not], > so I think it can be called real bursty test. > Ok, hear me out and tell me where I am wrong: By default a socket can receive at least 128 skbs with 258-byte payload, correct? That means that user of cn_netlink_send, if started "fresh", 128 average - size connector messages. If sender does not want to wait for anything (unlike your fork tests that do schedule) that means that 127 of those 128 messages will be dropped, although netlink would deliver them in time just fine. What am I missing? -- Dmitry From sri@us.ibm.com Wed Apr 27 04:37:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 04:37:09 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RBb45Z024137 for ; Wed, 27 Apr 2005 04:37:04 -0700 Received: from e2.ny.us.ibm.com ([192.168.1.102]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIXLU7012930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Apr 2005 14:33:21 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWjcd010341 for ; Tue, 26 Apr 2005 14:32:45 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3QIWiNG088738 for ; Tue, 26 Apr 2005 14:32:44 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j3QIWiQa025692 for ; Tue, 26 Apr 2005 13:32:44 -0500 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWhF8025621; Tue, 26 Apr 2005 13:32:44 -0500 Date: Tue, 26 Apr 2005 11:32:43 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6 4/6][SCTP] Fix bug in sctp_init() error handling code. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 781 Lines: 26 [SCTP] Fix bug in sctp_init() error handling code. Signed-off-by: Neil Horman Signed-off-by: Sridhar Samudrala ------------------------------------------------------------------- diff -Nru a/net/sctp/protocol.c b/net/sctp/protocol.c --- a/net/sctp/protocol.c 2005-04-21 16:23:29 -07:00 +++ b/net/sctp/protocol.c 2005-04-21 16:23:29 -07:00 @@ -1159,8 +1159,6 @@ status = 0; out: return status; -err_add_protocol: - proto_unregister(&sctp_prot); err_ctl_sock_init: sctp_v6_exit(); err_v6_init: @@ -1188,6 +1186,8 @@ inet_del_protocol(&sctp_protocol, IPPROTO_SCTP); inet_unregister_protosw(&sctp_seqpacket_protosw); inet_unregister_protosw(&sctp_stream_protosw); +err_add_protocol: + proto_unregister(&sctp_prot); goto out; } From sri@us.ibm.com Wed Apr 27 05:06:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:06:10 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RC63LS031624 for ; Wed, 27 Apr 2005 05:06:03 -0700 Received: from e3.ny.us.ibm.com ([192.168.1.103]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIXKNV012928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Apr 2005 14:33:20 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWTpF030491 for ; Tue, 26 Apr 2005 14:32:29 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3QIWTNG087852 for ; Tue, 26 Apr 2005 14:32:29 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j3QIWT38024837 for ; Tue, 26 Apr 2005 13:32:29 -0500 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWSRZ024794; Tue, 26 Apr 2005 13:32:28 -0500 Date: Tue, 26 Apr 2005 11:32:28 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6 2/6][SCTP] Implement Sec 2.41 of SCTP Implementers guide. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10969 Lines: 271 [SCTP] Implement Sec 2.41 of SCTP Implementers guide. - Fixed sctp_vtag_verify_either() to comply with impguide 2.41 B) and C). - Make sure vtag is reflected when T-bit is set in SHUTDOWN-COMPLETE sent due to an OOTB SHUTDOWN-ACK and in ABORT sent due to an OOTB packet. - Do not set T-Bit in ABORT chunk in response to INIT. - Fixed some comments to reflect the new meaning of the T-Bit. Signed-off-by: Jerome Forissier Signed-off-by: Sridhar Samudrala -------------------------------------------------------------------------- diff -Nru a/include/net/sctp/sm.h b/include/net/sctp/sm.h --- a/include/net/sctp/sm.h 2005-04-21 16:20:59 -07:00 +++ b/include/net/sctp/sm.h 2005-04-21 16:20:59 -07:00 @@ -407,32 +407,38 @@ return 0; } -/* Check VTAG of the packet matches the sender's own tag OR its peer's - * tag and the T bit is set in the Chunk Flags. +/* Check VTAG of the packet matches the sender's own tag and the T bit is + * not set, OR its peer's tag and the T bit is set in the Chunk Flags. */ static inline int sctp_vtag_verify_either(const struct sctp_chunk *chunk, const struct sctp_association *asoc) { - /* RFC 2960 Section 8.5.1, sctpimpguide-06 Section 2.13.2 + /* RFC 2960 Section 8.5.1, sctpimpguide Section 2.41 * - * B) The receiver of a ABORT shall accept the packet if the - * Verification Tag field of the packet matches its own tag OR it - * is set to its peer's tag and the T bit is set in the Chunk - * Flags. Otherwise, the receiver MUST silently discard the packet - * and take no further action. - * - * (C) The receiver of a SHUTDOWN COMPLETE shall accept the - * packet if the Verification Tag field of the packet - * matches its own tag OR it is set to its peer's tag and - * the T bit is set in the Chunk Flags. Otherwise, the - * receiver MUST silently discard the packet and take no - * further action.... + * B) The receiver of a ABORT MUST accept the packet + * if the Verification Tag field of the packet matches its own tag + * and the T bit is not set + * OR + * it is set to its peer's tag and the T bit is set in the Chunk + * Flags. + * Otherwise, the receiver MUST silently discard the packet + * and take no further action. * + * C) The receiver of a SHUTDOWN COMPLETE shall accept the packet + * if the Verification Tag field of the packet matches its own tag + * and the T bit is not set + * OR + * it is set to its peer's tag and the T bit is set in the Chunk + * Flags. + * Otherwise, the receiver MUST silently discard the packet + * and take no further action. An endpoint MUST ignore the + * SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. */ - if ((ntohl(chunk->sctp_hdr->vtag) == asoc->c.my_vtag) || - (sctp_test_T_bit(chunk) && (ntohl(chunk->sctp_hdr->vtag) - == asoc->c.peer_vtag))) { + if ((!sctp_test_T_bit(chunk) && + (ntohl(chunk->sctp_hdr->vtag) == asoc->c.my_vtag)) || + (sctp_test_T_bit(chunk) && + (ntohl(chunk->sctp_hdr->vtag) == asoc->c.peer_vtag))) { return 1; } diff -Nru a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c --- a/net/sctp/sm_make_chunk.c 2005-04-21 16:20:59 -07:00 +++ b/net/sctp/sm_make_chunk.c 2005-04-21 16:20:59 -07:00 @@ -710,7 +710,9 @@ struct sctp_chunk *retval; __u8 flags = 0; - /* Maybe set the T-bit if we have no association. */ + /* Set the T-bit if we have no association (vtag will be + * reflected) + */ flags |= asoc ? 0 : SCTP_CHUNK_FLAG_T; retval = sctp_make_chunk(asoc, SCTP_CID_SHUTDOWN_COMPLETE, flags, 0); @@ -732,7 +734,7 @@ } /* Create an ABORT. Note that we set the T bit if we have no - * association. + * association, except when responding to an INIT (sctpimpguide 2.41). */ struct sctp_chunk *sctp_make_abort(const struct sctp_association *asoc, const struct sctp_chunk *chunk, @@ -741,8 +743,16 @@ struct sctp_chunk *retval; __u8 flags = 0; - /* Maybe set the T-bit if we have no association. */ - flags |= asoc ? 0 : SCTP_CHUNK_FLAG_T; + /* Set the T-bit if we have no association and 'chunk' is not + * an INIT (vtag will be reflected). + */ + if (!asoc) { + if (chunk && chunk->chunk_hdr && + chunk->chunk_hdr->type == SCTP_CID_INIT) + flags = 0; + else + flags = SCTP_CHUNK_FLAG_T; + } retval = sctp_make_chunk(asoc, SCTP_CID_ABORT, flags, hint); @@ -2744,7 +2754,6 @@ hint = (nstreams + 1) * sizeof(__u32); - /* Maybe set the T-bit if we have no association. */ retval = sctp_make_chunk(asoc, SCTP_CID_FWD_TSN, 0, hint); if (!retval) diff -Nru a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c --- a/net/sctp/sm_statefuns.c 2005-04-21 16:20:59 -07:00 +++ b/net/sctp/sm_statefuns.c 2005-04-21 16:20:59 -07:00 @@ -126,15 +126,18 @@ * should stop the T2-shutdown timer and remove all knowledge of the * association (and thus the association enters the CLOSED state). * - * Verification Tag: 8.5.1(C) + * Verification Tag: 8.5.1(C), sctpimpguide 2.41. * C) Rules for packet carrying SHUTDOWN COMPLETE: * ... - * - The receiver of a SHUTDOWN COMPLETE shall accept the packet if the - * Verification Tag field of the packet matches its own tag OR it is - * set to its peer's tag and the T bit is set in the Chunk Flags. - * Otherwise, the receiver MUST silently discard the packet and take - * no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if - * it is not in the SHUTDOWN-ACK-SENT state. + * - The receiver of a SHUTDOWN COMPLETE shall accept the packet + * if the Verification Tag field of the packet matches its own tag and + * the T bit is not set + * OR + * it is set to its peer's tag and the T bit is set in the Chunk + * Flags. + * Otherwise, the receiver MUST silently discard the packet + * and take no further action. An endpoint MUST ignore the + * SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. * * Inputs * (endpoint, asoc, chunk) @@ -2858,16 +2861,16 @@ /* * Generate an ABORT in response to a packet. * - * Section: 8.4 Handle "Out of the blue" Packets + * Section: 8.4 Handle "Out of the blue" Packets, sctpimpguide 2.41 * - * 8) The receiver should respond to the sender of the OOTB packet - * with an ABORT. When sending the ABORT, the receiver of the - * OOTB packet MUST fill in the Verification Tag field of the - * outbound packet with the value found in the Verification Tag - * field of the OOTB packet and set the T-bit in the Chunk Flags - * to indicate that no TCB was found. After sending this ABORT, - * the receiver of the OOTB packet shall discard the OOTB packet - * and take no further action. + * 8) The receiver should respond to the sender of the OOTB packet with + * an ABORT. When sending the ABORT, the receiver of the OOTB packet + * MUST fill in the Verification Tag field of the outbound packet + * with the value found in the Verification Tag field of the OOTB + * packet and set the T-bit in the Chunk Flags to indicate that the + * Verification Tag is reflected. After sending this ABORT, the + * receiver of the OOTB packet shall discard the OOTB packet and take + * no further action. * * Verification Tag: * @@ -2895,6 +2898,10 @@ return SCTP_DISPOSITION_NOMEM; } + /* Reflect vtag if T-Bit is set */ + if (sctp_test_T_bit(abort)) + packet->vtag = ntohl(chunk->sctp_hdr->vtag); + /* Set the skb to the belonging sock for accounting. */ abort->skb->sk = ep->base.sk; @@ -3026,22 +3033,24 @@ } /* - * RFC 2960, 8.4 - Handle "Out of the blue" Packets + * RFC 2960, 8.4 - Handle "Out of the blue" Packets, sctpimpguide 2.41. + * * 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should * respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. * When sending the SHUTDOWN COMPLETE, the receiver of the OOTB * packet must fill in the Verification Tag field of the outbound * packet with the Verification Tag received in the SHUTDOWN ACK and - * set the T-bit in the Chunk Flags to indicate that no TCB was - * found. Otherwise, + * set the T-bit in the Chunk Flags to indicate that the Verification + * Tag is reflected. * * 8) The receiver should respond to the sender of the OOTB packet with * an ABORT. When sending the ABORT, the receiver of the OOTB packet * MUST fill in the Verification Tag field of the outbound packet * with the value found in the Verification Tag field of the OOTB - * packet and set the T-bit in the Chunk Flags to indicate that no - * TCB was found. After sending this ABORT, the receiver of the OOTB - * packet shall discard the OOTB packet and take no further action. + * packet and set the T-bit in the Chunk Flags to indicate that the + * Verification Tag is reflected. After sending this ABORT, the + * receiver of the OOTB packet shall discard the OOTB packet and take + * no further action. */ sctp_disposition_t sctp_sf_ootb(const struct sctp_endpoint *ep, const struct sctp_association *asoc, @@ -3090,13 +3099,15 @@ /* * Handle an "Out of the blue" SHUTDOWN ACK. * - * Section: 8.4 5) + * Section: 8.4 5, sctpimpguide 2.41. + * * 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should - * respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. - * When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet - * must fill in the Verification Tag field of the outbound packet with - * the Verification Tag received in the SHUTDOWN ACK and set the - * T-bit in the Chunk Flags to indicate that no TCB was found. + * respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. + * When sending the SHUTDOWN COMPLETE, the receiver of the OOTB + * packet must fill in the Verification Tag field of the outbound + * packet with the Verification Tag received in the SHUTDOWN ACK and + * set the T-bit in the Chunk Flags to indicate that the Verification + * Tag is reflected. * * Inputs * (endpoint, asoc, type, arg, commands) @@ -3128,6 +3139,10 @@ return SCTP_DISPOSITION_NOMEM; } + /* Reflect vtag if T-Bit is set */ + if (sctp_test_T_bit(shut)) + packet->vtag = ntohl(chunk->sctp_hdr->vtag); + /* Set the skb to the belonging sock for accounting. */ shut->skb->sk = ep->base.sk; @@ -3591,7 +3606,6 @@ * * 2) If the OOTB packet contains an ABORT chunk, the receiver MUST * silently discard the OOTB packet and take no further action. - * Otherwise, * * Verification Tag: No verification necessary * @@ -4961,6 +4975,11 @@ sctp_ootb_pkt_free(packet); return NULL; } + + /* Reflect vtag if T-Bit is set */ + if (sctp_test_T_bit(abort)) + packet->vtag = ntohl(chunk->sctp_hdr->vtag); + /* Add specified error causes, i.e., payload, to the * end of the chunk. */ From kaber@trash.net Wed Apr 27 05:05:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:05:14 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RC59LS031275 for ; Wed, 27 Apr 2005 05:05:09 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DQlHu-0008HZ-UW; Wed, 27 Apr 2005 14:05:06 +0200 Message-ID: <426F7FF2.4070506@trash.net> Date: Wed, 27 Apr 2005 14:05:06 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Jozsef Kadlecsik , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, Yair@arx.com, linux-kernel@vger.kernel.org Subject: Re: Re-routing packets via netfilter (ip_rt_bug) References: <426D8672.1030001@trash.net> <20050426003925.GA13650@gondor.apana.org.au> <426E3F67.8090006@trash.net> <20050426232857.GA18358@gondor.apana.org.au> <426EE350.1070902@trash.net> <20050427010730.GA18919@gondor.apana.org.au> <426F68C5.4010109@trash.net> <20050427103056.GB22099@gondor.apana.org.au> <20050427113542.GB22433@gondor.apana.org.au> <20050427115414.GA22562@gondor.apana.org.au> In-Reply-To: <20050427115414.GA22562@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 679 Lines: 17 Herbert Xu wrote: > Here is another reason why these packets should go through FORWARD. > They were generated in response to packets in INPUT/FORWARD/OUTPUT. > The original packet has not undergone SNAT in any of these cases. > > However, if we feed the response packet through LOCAL_OUT it will > be subject to DNAT. This creates a NAT asymmetry and we may end > up with the wrong destination address. > > By pushing it through FORWARD it will only undergo SNAT which is > correct since the original packet would have undergone DNAT. This is only a problem since the recent NAT changes, but I agree that we should fix it by moving these packets to FORWARD. Regards Patrick From hadi@znyx.com Wed Apr 27 05:10:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:10:37 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCAWLS032556 for ; Wed, 27 Apr 2005 05:10:32 -0700 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042704551655:31194 ; Wed, 27 Apr 2005 04:55:16 -0700 Subject: patch: policy update by id From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Herbert Xu Cc: netdev@oss.sgi.com Organization: ZNYX Networks Date: Wed, 27 Apr 2005 07:54:34 -0400 Message-Id: <1114602874.7670.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 04:55:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 05:11:12 AM, Serialize complete at 04/27/2005 05:11:12 AM Content-Type: multipart/mixed; boundary="=-hAbxU4CA+qUy6baSQSE7" X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 40 --=-hAbxU4CA+qUy6baSQSE7 Content-Transfer-Encoding: 7bit Content-Type: text/plain Herbert, I think this is a reasonable thing to have. I should be able to update (just like delete or get) a policy by id. And that it trumps a selector when both are specified.. I am assuming ids are unique - otherwise we have a serious problem. If this patch looks good, please add it to your patch collection that you are queueing for Dave; btw - is that stuff supposed to show up around .13? cheers, jamal --=-hAbxU4CA+qUy6baSQSE7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=polid_p Content-Type: text/plain; name=polid_p; charset=UTF-8 --- a/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ b/net/xfrm/xfrm_policy.c 2005/04/27 11:48:42 @@ -345,7 +345,9 @@ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { + if (!delpol && + ((!excl && policy->id && (policy->id == pol->id)) || + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { if (excl) { write_unlock_bh(&xfrm_policy_lock); return -EEXIST; --=-hAbxU4CA+qUy6baSQSE7-- From hadi@cyberus.ca Wed Apr 27 05:24:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:24:32 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCON1O001447 for ; Wed, 27 Apr 2005 05:24:23 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQlaY-00010h-9y for netdev@oss.sgi.com; Wed, 27 Apr 2005 08:24:22 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQlaV-0008FI-CH; Wed, 27 Apr 2005 08:24:19 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <1114602874.7670.4.camel@localhost.localdomain> References: <1114602874.7670.4.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-svPqSGhbObaErkWu9yim" Organization: unknown Date: Wed, 27 Apr 2005 08:24:17 -0400 Message-Id: <1114604657.7670.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 201 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: 1438 Lines: 45 --=-svPqSGhbObaErkWu9yim Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-27-04 at 07:54 -0400, Jamal Hadi Salim wrote: > Herbert, > > I think this is a reasonable thing to have. I should be able to update > (just like delete or get) a policy by id. And that it trumps a selector > when both are specified.. > I am assuming ids are unique - otherwise we have a serious problem. > If this patch looks good, please add it to your patch collection that > you are queueing for Dave; btw - is that stuff supposed to show up > around .13? > Sorry, should have tried to compile first ;-> here it is. I will test in 5 minutes or so. cheers, jamal --=-svPqSGhbObaErkWu9yim Content-Disposition: attachment; filename=polid_p Content-Type: text/plain; name=polid_p; charset=utf-8 Content-Transfer-Encoding: 7bit --- /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 12:23:03 @@ -345,7 +345,9 @@ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { + if (!delpol && + ((!excl && policy->id && (policy->index == pol->index)) || + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { if (excl) { write_unlock_bh(&xfrm_policy_lock); return -EEXIST; --=-svPqSGhbObaErkWu9yim-- From hadi@znyx.com Wed Apr 27 05:27:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:27:16 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCRC1O002157 for ; Wed, 27 Apr 2005 05:27:12 -0700 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042705274838:31225 ; Wed, 27 Apr 2005 05:27:48 -0700 Subject: Re: patch: policy update by id From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <1114604657.7670.22.camel@localhost.localdomain> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> Organization: ZNYX Networks Date: Wed, 27 Apr 2005 08:27:06 -0400 Message-Id: <1114604826.7670.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 05:27:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 05:27:52 AM, Serialize complete at 04/27/2005 05:27:52 AM Content-Type: multipart/mixed; boundary="=-zfQAy5DITNpt42sShRMm" X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 911 Lines: 32 --=-zfQAy5DITNpt42sShRMm Content-Transfer-Encoding: 7bit Content-Type: text/plain dammit. here it is now compiling ;-> cheers, jamal --=-zfQAy5DITNpt42sShRMm Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=polid_p Content-Type: text/plain; name=polid_p; charset=utf-8 --- /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 12:25:24 @@ -345,7 +345,9 @@ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { + if (!delpol && + ((!excl && policy->index && (policy->index == pol->index)) || + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { if (excl) { write_unlock_bh(&xfrm_policy_lock); return -EEXIST; --=-zfQAy5DITNpt42sShRMm-- From ak@muc.de Wed Apr 27 05:26:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:26:59 -0700 (PDT) Received: from colin2.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCQu1O002048 for ; Wed, 27 Apr 2005 05:26:57 -0700 Received: (qmail 16333 invoked by uid 3709); 27 Apr 2005 12:26:48 -0000 Date: 27 Apr 2005 14:26:48 +0200 Date: Wed, 27 Apr 2005 14:26:48 +0200 From: Andi Kleen To: Glen Turner Cc: netdev@oss.sgi.com Subject: network manpages was Re: is UDP_CORK "real" Message-ID: <20050427122648.GA12597@muc.de> References: <426833F0.9010803@hp.com> <426F2A1D.10001@aarnet.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426F2A1D.10001@aarnet.edu.au> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 202 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: 1052 Lines: 23 On Wed, Apr 27, 2005 at 03:28:53PM +0930, Glen Turner wrote: > Please mail me with what you think is required here. I've > been getting grief from our high performance users on > exactly this point (and the sysctl maze of twisty options) sysctl is mostly documented in Documentation/*. Also the sysctls change sometimes, so I am not sure it is a good idea to put them into the manpages which are supposed to be more version independent. At least I would only put the more important ones there. In particular the ipv6 protocol manpage needs a rewrite, it was only a relatively poor quick&dirty job. For the others it would be probably sufficient to just check what new ioctls/socket options are missing and document them and perhaps check if the NOTES/BUGS caveats still apply. An sctp manpage is also lacking I think, that was a completely new protocol. It would be nice of course if David could enforce a policy to require a manpage patch for new ioctls/socket options etc. in the future, then such documentation lag would not happen. -Andi From hadi@znyx.com Wed Apr 27 05:28:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:28:38 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCSZ1O003050 for ; Wed, 27 Apr 2005 05:28:36 -0700 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042705291462:31226 ; Wed, 27 Apr 2005 05:29:14 -0700 Subject: Re: patch: policy update by id From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Patrick McHardy Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <426F830E.4060404@trash.net> References: <1114602874.7670.4.camel@localhost.localdomain> <426F830E.4060404@trash.net> Organization: ZNYX Networks Date: Wed, 27 Apr 2005 08:28:32 -0400 Message-Id: <1114604912.7670.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 05:29:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2005 05:29:15 AM, Serialize complete at 04/27/2005 05:29:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 268 Lines: 13 On Wed, 2005-27-04 at 14:18 +0200, Patrick McHardy wrote: > struct xfrm_policy doesn't have an id member in my tree. Did I miss > something or do you mean to use index? > I meant index, sorry. I am going to give it a quick test in about 3 minutes. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 05:43:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:43:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RChU1O005093 for ; Wed, 27 Apr 2005 05:43:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQlsr-0005dx-00; Wed, 27 Apr 2005 22:43:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQlsn-0005yd-00; Wed, 27 Apr 2005 22:43:13 +1000 From: Herbert Xu To: tommy.christensen@tpack.net (Tommy Christensen) Subject: Re: [PATCH] net: Disable queueing when carrier is lost Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <426EB84C.90307@tpack.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 27 Apr 2005 22:43:13 +1000 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1199 Lines: 31 Tommy Christensen wrote: > > A while back we had a very long thread about the queueing behavior of > netdevices in a loss-of-carrier situation. This thread had the poetic > subject: [patch 4/10] s390: network driver. I remember that thread :) Thanks for chasing this up. > The executive summary: Agreed. > The best solution seems to be to simply disable the queueing at the qdisc > layer when this situation arises. That approach has been implemented in > the patch below. Hasso Tepper reports succesfull testing > of the patch with Quagga. The idea is good. However, the implementation has a problem in it. You're relying on the watchdog which may not be there. The watchdog is only present if tx_timeout is defined. Also, this still doesn't help us if the driver itself has a TX queue that is hoarding the packets. So the driver itself needs to make sure that when the carrier goes off that its TX queue is flushed too. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Wed Apr 27 05:48:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:48:35 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCmS1P005856 for ; Wed, 27 Apr 2005 05:48:30 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DQlUl-0008JQ-1y; Wed, 27 Apr 2005 14:18:23 +0200 Message-ID: <426F830E.4060404@trash.net> Date: Wed, 27 Apr 2005 14:18:22 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@znyx.com CC: Herbert Xu , netdev@oss.sgi.com Subject: Re: patch: policy update by id References: <1114602874.7670.4.camel@localhost.localdomain> In-Reply-To: <1114602874.7670.4.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 324 Lines: 10 Jamal Hadi Salim wrote: > I think this is a reasonable thing to have. I should be able to update > (just like delete or get) a policy by id. And that it trumps a selector > when both are specified.. struct xfrm_policy doesn't have an id member in my tree. Did I miss something or do you mean to use index? Regards Patrick From kaber@trash.net Wed Apr 27 05:48:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:48:46 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCmS1O005856 for ; Wed, 27 Apr 2005 05:48:29 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DQarA-0002R4-NR; Wed, 27 Apr 2005 02:56:48 +0200 Message-ID: <426EE350.1070902@trash.net> Date: Wed, 27 Apr 2005 02:56:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Yair@arx.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: Re-routing packets via netfilter (ip_rt_bug) References: <426D0CB9.4060500@trash.net> <20050425213400.GB29288@gondor.apana.org.au> <426D8672.1030001@trash.net> <20050426003925.GA13650@gondor.apana.org.au> <426E3F67.8090006@trash.net> <20050426232857.GA18358@gondor.apana.org.au> In-Reply-To: <20050426232857.GA18358@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1382 Lines: 32 Herbert Xu wrote: > Let's look at the bigger picture. There are three users of > ip_route_me_harder: nat, mangle and queue. They're all done > in LOCAL_OUT. > > For nat/mangle, the source address cannot change so it's > guaranteed to be a local IP address. On the face of it, > queue could be changing the source address. However, the > more I think about it the more I reckon that it should > be disallowed. The ipt_REJECT target can send TCP RSTs with foreign source which go through LOCAL_OUT. Restricting it to this case and adding proper checks to ipt_REJECT would relieve us of having to handle the last case you pointed out (foreign saddr, broadcast/multicast daddr), but it shouldn't be hard to also handle this case. > If the user is changing the source address in LOCAL_OUT/queue > then he's doing SNAT in LOCAL_OUT. This violates some fundamental > assumptions in netfilter. The user also isn't going to have > an easy time setting up the reverse DNAT since the corresponding > location on the reverse side does not have a ip_route_me_harder > call. These assumptions are only for stateful NAT, the mangle table seems to try to deal with stateless NAT by rerouting in LOCAL_OUT when saddr/daddr changed. But it could also just be some left-over cut-n-pasted from ip_nat_standalone.c, I don't think anyone is doing stateless NAT with netfilter. Regards Patrick From hadi@cyberus.ca Wed Apr 27 05:52:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 05:52:20 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RCqH1O007190 for ; Wed, 27 Apr 2005 05:52:17 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DQm1X-0006au-O7 for netdev@oss.sgi.com; Wed, 27 Apr 2005 08:52:15 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQm1S-0005z5-VT; Wed, 27 Apr 2005 08:52:11 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <1114604912.7670.25.camel@localhost.localdomain> References: <1114602874.7670.4.camel@localhost.localdomain> <426F830E.4060404@trash.net> <1114604912.7670.25.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 08:52:08 -0400 Message-Id: <1114606328.7670.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 208 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: 514 Lines: 19 On Wed, 2005-27-04 at 08:28 -0400, Jamal Hadi Salim wrote: > On Wed, 2005-27-04 at 14:18 +0200, Patrick McHardy wrote: > > > struct xfrm_policy doesn't have an id member in my tree. Did I miss > > something or do you mean to use index? > > > > I meant index, sorry. I am going to give it a quick test in about 3 > minutes. > Sorry, cant test, have to rush to work - and it looks like the priorities may interfere. I will test when i get back home. It also appears there may be a bug in ip x. cheers, jamal From fubar@us.ibm.com Wed Apr 27 06:00:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 06:00:36 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RD0Q1O008084 for ; Wed, 27 Apr 2005 06:00:32 -0700 Received: from e35.co.us.ibm.com (e35.esmtp.ibm.com [9.14.4.133]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3R29El4028494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 26 Apr 2005 22:09:15 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3R299Lg594474 for ; Tue, 26 Apr 2005 22:09:09 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3R2992i253740 for ; Tue, 26 Apr 2005 20:09:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3R298ku027277 for ; Tue, 26 Apr 2005 20:09:08 -0600 Received: from death.nxdomain.ibm.com (sig-9-49-128-123.mts.ibm.com [9.49.128.123]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3R298eB027228; Tue, 26 Apr 2005 20:09:08 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j3R295FP007440; Tue, 26 Apr 2005 19:09:05 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j3R291ml007431; Tue, 26 Apr 2005 19:09:04 -0700 Message-Id: <200504270209.j3R291ml007431@death.nxdomain.ibm.com> To: Herbert Xu cc: "David S. Miller" , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address In-Reply-To: Message from Herbert Xu of "Tue, 26 Apr 2005 21:18:45 +1000." <20050426111845.GA8968@gondor.apana.org.au> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 26 Apr 2005 19:09:01 -0700 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1100 Lines: 29 Herbert Xu wrote: [...] >Indeed. But how can this stuff work at all? Surely if use_carrier is >disabled while miimon is enabled we should get a dead-lock as soon as >this call chain is run: > >dev_ioctl => bond_enslave => bond_check_dev_link => slave_dev->ioctl Why would it deadlock? dev_ioctl holds RTNL, bonding grabs various bond locks, and the slave device ioctl handler may or may not get a lock of its own. >> It is better, performance-wise, to run the "main" part of the >> link monitoring in a timer, and then call out to a work queue only for >> those operations that need a context? I.e., how expensive are work >> queues compared to timers? > >For the amount of work that these timers are doing, the overhead is >pretty small. It is also gentler on the system when the CPU load >goes up. Just so I'm clear: by "the overhead" do you mean the overhead of running everything in a work queue, or the overhead of calling out from a timer to a work queue for "special occasions"? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From sri@us.ibm.com Wed Apr 27 06:07:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 06:08:01 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RD7v1O008874 for ; Wed, 27 Apr 2005 06:07:57 -0700 Received: from e1.ny.us.ibm.com ([192.168.1.101]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIXl8s012977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Apr 2005 14:33:47 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWEBo024976 for ; Tue, 26 Apr 2005 14:32:14 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3QIWDNG090608 for ; Tue, 26 Apr 2005 14:32:13 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j3QIWD8D024148 for ; Tue, 26 Apr 2005 13:32:13 -0500 Received: from dyn9047018105.beaverton.ibm.com (dyn9047018105.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3QIWCTV024120; Tue, 26 Apr 2005 13:32:13 -0500 Date: Tue, 26 Apr 2005 11:32:12 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@dyn9047018105.beaverton.ibm.com To: davem@davemloft.net cc: netdev@oss.sgi.com Subject: [PATCH 2.6 1/6][SCTP] Fix SCTP_ASSOCINFO getsockopt for 1-1 style sockets. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 819 Lines: 25 Hi Dave, I am resubmitting SCTP patches pine after fixing the leading space problem. Please apply. Thanks Sridhar [SCTP] Fix SCTP_ASSOCINFO getsockopt for 1-1 style sockets. Signed-off-by: Vladislav Yasevich Signed-off-by: Sridhar Samudrala ---------------------------------------------------------------------- diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c 2005-04-21 16:20:07 -07:00 +++ b/net/sctp/socket.c 2005-04-21 16:20:07 -07:00 @@ -3473,7 +3473,7 @@ return -EINVAL; /* Values correspoinding to the specific association */ - if (assocparams.sasoc_assoc_id != 0) { + if (asoc) { assocparams.sasoc_asocmaxrxt = asoc->max_retrans; assocparams.sasoc_peer_rwnd = asoc->peer.rwnd; assocparams.sasoc_local_rwnd = asoc->a_rwnd; From herbert@gondor.apana.org.au Wed Apr 27 06:23:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 06:23:10 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RDN41O010176 for ; Wed, 27 Apr 2005 06:23:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQb1a-0002MI-00; Wed, 27 Apr 2005 11:07:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQb1W-0004vh-00; Wed, 27 Apr 2005 11:07:30 +1000 Date: Wed, 27 Apr 2005 11:07:30 +1000 To: Patrick McHardy Cc: Yair@arx.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: Re-routing packets via netfilter (ip_rt_bug) Message-ID: <20050427010730.GA18919@gondor.apana.org.au> References: <426D0CB9.4060500@trash.net> <20050425213400.GB29288@gondor.apana.org.au> <426D8672.1030001@trash.net> <20050426003925.GA13650@gondor.apana.org.au> <426E3F67.8090006@trash.net> <20050426232857.GA18358@gondor.apana.org.au> <426EE350.1070902@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426EE350.1070902@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 663 Lines: 16 On Wed, Apr 27, 2005 at 02:56:48AM +0200, Patrick McHardy wrote: > > The ipt_REJECT target can send TCP RSTs with foreign source which > go through LOCAL_OUT. Restricting it to this case and adding proper Couldn't we feed the TCP RST packets with foreign sources through the FORWARD table? We're lying to the routing system already by telling it that the packet is forwarded. So I don't see anything wrong with lying to netfilter as well :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From rmk+netdev=oss.sgi.com@arm.linux.org.uk Wed Apr 27 07:05:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 07:05:43 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RE5Y1O012563 for ; Wed, 27 Apr 2005 07:05:39 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1DQnAH-0001cd-Lr for netdev@oss.sgi.com; Wed, 27 Apr 2005 15:05:22 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.41) id 1DQnAF-0004yW-FE for netdev@oss.sgi.com; Wed, 27 Apr 2005 15:05:19 +0100 Date: Wed, 27 Apr 2005 15:05:18 +0100 From: Russell King To: netdev@oss.sgi.com Subject: Badness in cache_free_debugcheck at linux/mm/slab.c:1909 Message-ID: <20050427150518.A15989@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev Content-Length: 1650 Lines: 39 Hi, This pretty much sums up the problem: Badness in cache_free_debugcheck at linux/mm/slab.c:1909 [] (cache_free_debugcheck+0x0/0x24c) from [] (kmem_cache_free+0x3c/0xb0) r8 = A0000013 r7 = C0A5E198 r6 = C7C9A220 r5 = C7C995C0 r4 = C018435C [] (kmem_cache_free+0x0/0xb0) from [] (sk_free+0xc0/0x114) r8 = C002A4C4 r7 = C64690C4 r6 = C03F6494 r5 = 00000000 r4 = C0A5E198 [] (sk_free+0x0/0x114) from [] (inet_release+0x60/0x68) r5 = C474370C r4 = C0A5E198 [] (inet_release+0x0/0x68) from [] (sock_release+0x28/0xb0) r5 = C474370C r4 = 00000000 [] (sock_release+0x0/0xb0) from [] (sock_close+0x38/0x44) r5 = C4743730 r4 = C4743730 [] (sock_close+0x0/0x44) from [] (__fput+0x58/0x140) r4 = C4EFEEC4 [] (__fput+0x0/0x140) from [] (filp_close+0x84/0x90) r7 = 00000006 r6 = C3E96DA0 r5 = 00000000 r4 = C4EFEEC4 [] (filp_close+0x0/0x90) from [] (ret_fast_syscall+0x0/0x2c) r6 = 00000006 r5 = FFFFFFFF r4 = 00000006 mismatch in kmem_cache_free: expected cache c7d57820, got c7c995c0 c7c995c0 is TCP. c7d57820 is TCPv6. At a guess, what's happening is that the socket is initially owned by tcpv6, so the struct sock is allocated in the TCPv6 slab. A userspace program is probably doing an ADDRFORM sockopt, converting it to a TCP socket. At a later time, we free the socket using the new sk->sk_prot slabs - which would be the TCP slab. The above messages are from 2.6.12-rc2, but the above diagnosis came from a quick look at the 2.6.12-rc3 sources. -- Russell King From herbert@gondor.apana.org.au Wed Apr 27 07:23:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 07:23:16 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3REN41O013610 for ; Wed, 27 Apr 2005 07:23:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQc5A-0002eZ-00; Wed, 27 Apr 2005 12:15:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQc51-00052u-00; Wed, 27 Apr 2005 12:15:11 +1000 Date: Wed, 27 Apr 2005 12:15:11 +1000 To: Jay Vosburgh Cc: "David S. Miller" , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 2.6.12-rc2] bonding: partially back out dev_set_mac_address Message-ID: <20050427021511.GA19353@gondor.apana.org.au> References: <20050426111845.GA8968@gondor.apana.org.au> <200504270209.j3R291ml007431@death.nxdomain.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504270209.j3R291ml007431@death.nxdomain.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1138 Lines: 30 On Tue, Apr 26, 2005 at 07:09:01PM -0700, Jay Vosburgh wrote: > > >dev_ioctl => bond_enslave => bond_check_dev_link => slave_dev->ioctl > > Why would it deadlock? dev_ioctl holds RTNL, bonding grabs > various bond locks, and the slave device ioctl handler may or may not > get a lock of its own. I get it now. I had thought that it was calling sys_ioctl but it's going direct to slave_dev->ioctl which bypasses the rtnl. So the bond_enslave path is safe but the timer path isn't as you noted previously. > >For the amount of work that these timers are doing, the overhead is > >pretty small. It is also gentler on the system when the CPU load > >goes up. > > Just so I'm clear: by "the overhead" do you mean the overhead of > running everything in a work queue, or the overhead of calling out from > a timer to a work queue for "special occasions"? I'm referring to running everything out of a work queue. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bernd.schubert@pci.uni-heidelberg.de Wed Apr 27 07:47:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 07:47:41 -0700 (PDT) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3REla1O014721 for ; Wed, 27 Apr 2005 07:47:36 -0700 Received: from hamilton1.pci.uni-heidelberg.de (hamilton1.pci.uni-heidelberg.de [129.206.21.201]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j3REnJfK012573 for ; Wed, 27 Apr 2005 16:49:20 +0200 (MET DST) Received: from euklid.pci.uni-heidelberg.de ([129.206.21.104] helo=euklid ident=foobar) by hamilton1.pci.uni-heidelberg.de with smtp (Exim 3.35 #1 (Debian)) id 1DQnp3-0006bM-00 for ; Wed, 27 Apr 2005 16:47:29 +0200 Received: by euklid (sSMTP sendmail emulation); Wed, 27 Apr 2005 16:47:29 +0200 From: Bernd Schubert Reply-To: bernd-schubert@gmx.de To: netdev@oss.sgi.com Subject: list admin? unsubscribing from the list? Date: Wed, 27 Apr 2005 16:47:25 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200504271647.28759.bernd.schubert@pci.uni-heidelberg.de> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3REla1O014721 X-archive-position: 214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd.schubert@pci.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 2056 Lines: 70 Hi, several month ago I subscribed to this list and about two moth ago I unsubscribed again. About two weeks ago I receiced mail from the list, after unsubscribing again this stopped. Today I'm again receiving mail from the list, but unsubscribing fails: From: Ecartis To: bernd.schubert@tc.pci.uni-heidelberg.de Date: Today 16:19:58 Ecartis command results: unsubscribe netdev List context changed to 'netdev' by following command. >> unsubscribe netdev 'Unsubscribe' request denied. Your request was rejected for the following reason: You are not on the list 'netdev'. Valid command was found in subject field, body won't be checked for further commands. The mails are definitely sent to me by netdev: >From bernd Wed Apr 27 16:39:13 2005 Return-Path: Delivered-To: pci-Bernd.Schubert@tc.pci.uni-heidelberg.de Received: from instmail.uni-heidelberg.de [129.206.100.224] by localhost with POP3 (fetchmail-5.9.11) for bernd@localhost (single-drop); Wed, 27 Apr 2005 16:39:13 +0200 (CEST) Received: (qmail 31193 invoked from network); 27 Apr 2005 14:24:26 -0000 Received: from unknown (HELO relay2.uni-heidelberg.de) (129.206.210.211) by instmail.uni-heidelberg.de with SMTP; 27 Apr 2005 14:24:26 -0000 Received: from oss.sgi.com (oss.sgi.com [192.48.159.27]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j3REQ1tL006453 for ; Wed, 27 Apr 2005 16:26:02 +0200 (MET DST) Received: from oss (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RENn1O013725; Wed, 27 Apr 2005 07:23:49 -0700 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 07:23:16 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) So, Whom should I approach to properly unsubscribe? Thanks, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert@pci.uni-heidelberg.de From kernel@linuxace.com Wed Apr 27 08:42:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 08:42:21 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RFgF1O020024 for ; Wed, 27 Apr 2005 08:42:15 -0700 Received: (qmail 18174 invoked by uid 0); 27 Apr 2005 15:42:13 -0000 Date: Wed, 27 Apr 2005 08:42:13 -0700 From: Phil Oester To: netdev@oss.sgi.com Subject: NMI lockup in fib_sync_down Message-ID: <20050427154213.GA18158@linuxace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev Content-Length: 2192 Lines: 53 Been trying to upgrade a netfilter box from 2.6.10 to 2.6.11, but it panics within a few hours due to an NMI lockup. 2.6.10 never exhibits this problem. There were some fib cleanups done in the 2.6.11-rc series which may be related -- any ideas? Phil NMI Watchdog detected LOCKUP on CPU1, eip c026a8d4, registers: CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00001482 (2.6.11) EIP is at fib_sync_down+0x74/0x140 eax: c11c42f0 ebx: 00001920 ecx: c11c42f8 edx: c11c42f8 esi: f69327fc edi: f742d034 ebp: f69327ec esp: c032ada8 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c032a000 task=c191a530) Stack: f7c07934 c1919334 c1919349 f75c1020 f7b94c80 c024440c 00000004 00000304 00000000 c02281ee b6a02450 c11c4241 b6a02174 b6a02450 c11c4241 b6a02174 00000003 00000001 f69327ec c11c42f8 00000002 00000003 00000001 f69327b4 Call Trace: [] ip_finish_output2+0xac/0x1b0 [] skb_checksum+0x4e/0x2a0 [] tcp_packet+0xe3/0x430 [] ip_finish_output2+0x0/0x1b0 [] ip_forward_finish+0x0/0x50 [] __ip_conntrack_find+0x12/0xe0 [] ip_conntrack_in+0xde/0x290 [] nf_iterate+0x72/0xb0 [] ip_rcv_finish+0x0/0x240 [] ip_rcv_finish+0x0/0x240 [] nf_hook_slow+0x68/0xf0 [] ip_rcv_finish+0x0/0x240 [] ip_rcv+0x3c2/0x480 [] ip_rcv_finish+0x0/0x240 [] alloc_skb+0x32/0xd0 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x16e/0x4c0 [] try_to_wake_up+0x237/0x260 [] e1000_clean_tx_irq+0x14e/0x220 [] e1000_clean+0x42/0xf0 [] net_rx_action+0x7f/0x110 [] __do_softirq+0xb6/0xd0 [] do_softirq+0x4a/0x60 ======================= [] do_IRQ+0x4d/0x70 [] common_interrupt+0x1a/0x20 [] default_idle+0x23/0x30 [] cpu_idle+0x5f/0x70 Code: 31 ca 48 21 c2 8b 0c 96 85 c9 74 2b 8d 74 26 00 8d bc 27 00 00 00 00 8b 11 0f 18 02 90 8d 41 f8 39 58 24 0f 84 b8 00 00 00 85 d2 <89> d1 75 e8 90 8d b4 26 00 00 00 00 85 ff 74 47 c7 04 24 00 00 console shuts up ... From ralf@linux-mips.org Wed Apr 27 10:08:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:08:46 -0700 (PDT) Received: from bacchus.net.dhis.org (extgw-uk.mips.com [62.254.210.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RH8h1O023520 for ; Wed, 27 Apr 2005 10:08:44 -0700 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by bacchus.net.dhis.org (8.13.1/8.13.1) with ESMTP id j3RH8quS017605; Wed, 27 Apr 2005 18:08:52 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j3RH8oig017604; Wed, 27 Apr 2005 18:08:50 +0100 Date: Wed, 27 Apr 2005 18:08:50 +0100 From: Ralf Baechle To: bernd-schubert@gmx.de Cc: netdev@oss.sgi.com Subject: Re: list admin? unsubscribing from the list? Message-ID: <20050427170850.GA30431@linux-mips.org> References: <200504271647.28759.bernd.schubert@pci.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504271647.28759.bernd.schubert@pci.uni-heidelberg.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 578 Lines: 14 On Wed, Apr 27, 2005 at 04:47:25PM +0200, Bernd Schubert wrote: > several month ago I subscribed to this list and about two moth ago I > unsubscribed again. > About two weeks ago I receiced mail from the list, after unsubscribing again > this stopped. Today I'm again receiving mail from the list, but unsubscribing > fails: A funny little accident due to oss recently having changed hardware twice after the old machine died - with some chaos following. I fixed up the subscriber lists, so you should no longer receive email. Things should to run smoothly now. Ralf From domen@coderock.org Wed Apr 27 10:07:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:07:20 -0700 (PDT) Received: from trashy.coderock.org (coderock.org [193.77.147.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RH7D1O023404 for ; Wed, 27 Apr 2005 10:07:14 -0700 Received: by trashy.coderock.org (Postfix, from userid 780) id 8131D1ED3D; Wed, 27 Apr 2005 19:07:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 95B271ECC2; Wed, 27 Apr 2005 19:07:08 +0200 (CEST) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id D26841EC71; Wed, 27 Apr 2005 19:07:04 +0200 (CEST) Date: Wed, 27 Apr 2005 19:07:04 +0200 From: Domen Puncer To: Ismail Donmez Cc: kernel-janitors@lists.osdl.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [KJ] [PATCH] Documentation/networking/dmfe.txt : Make documentation nicer Message-ID: <20050427170703.GA3762@nd47.coderock.org> Mail-Followup-To: Ismail Donmez , kernel-janitors@lists.osdl.org, netdev@oss.sgi.com, jgarzik@pobox.com References: <200504262244.01258.ismail@kde.org.tr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200504262244.01258.ismail@kde.org.tr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1011 Lines: 30 On 26/04/05 22:44 +0300, Ismail Donmez wrote: > Hi, > > attached patch indents dmfe.txt to look like other docs. It adds a tip about > CNET cards using Davicom chipsets. Also it removes parts where it refers to > how to build driver out-of-kernel which seems to be cruft from times where > the driver was out of the kernel. Please, no quoted-printable, it makes it hard for scripts to parse right. (=20 and similar "characters") > > Signed-off-by: ??smail Dönmez Uhh... I don't recall being discussed in which encoding this should be, ascii is a safe bet. > --- dmfe.txt 2004-07-24 09:45:13.000000000 +0300 > +++ dmfe2.txt 2004-07-24 09:46:37.000000000 +0300 Patch should be -p1 appliable... meaning these lines will be something like: --- linux-2.6.12-rc3/Documentation/dmfe.txt ... +++ linux-dev/Documentation/dmfe.txt ... > @@ -1,59 +1,65 @@ > - dmfe.c: Version 1.28 01/18/2000 > +Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. Trailing whitespace. From ismail@kde.org.tr Wed Apr 27 10:27:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:27:06 -0700 (PDT) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHR01O025760 for ; Wed, 27 Apr 2005 10:27:00 -0700 Received: from dsl85-99-40872.ttnet.net.tr kde [85.99.159.168] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 1.4 $ on Linux; Wed, 27 Apr 2005 11:26:47 -0600 From: Ismail Donmez Organization: Bogazici University To: kernel-janitors@lists.osdl.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [KJ] [PATCH] Documentation/networking/dmfe.txt : Make documentation nicer Date: Wed, 27 Apr 2005 20:26:28 +0300 User-Agent: KMail/1.8.50 References: <200504262244.01258.ismail@kde.org.tr> <20050427170703.GA3762@nd47.coderock.org> In-Reply-To: <20050427170703.GA3762@nd47.coderock.org> Cc: ismail@kde.org.tr MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Ft8bCp6v85r2St9" Message-Id: <200504272026.29047.ismail@kde.org.tr> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ismail@kde.org.tr Precedence: bulk X-list: netdev Content-Length: 6558 Lines: 170 --Boundary-00=_Ft8bCp6v85r2St9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline On Wednesday 27 April 2005 20:07, Domen Puncer wrote: > On 26/04/05 22:44 +0300, Ismail Donmez wrote: > > Hi, > > > > attached patch indents dmfe.txt to look like other docs. It adds a tip > > about CNET cards using Davicom chipsets. Also it removes parts where it > > refers to how to build driver out-of-kernel which seems to be cruft from > > times where the driver was out of the kernel. > > Please, no quoted-printable, it makes it hard for scripts to parse right. > (=20 and similar "characters") Ok hopefully its ok now > > > Signed-off-by: ??smail Dönmez > Ok my unicode name is buggy ;) > Uhh... I don't recall being discussed in which encoding this should be, > ascii is a safe bet. > > > --- dmfe.txt 2004-07-24 09:45:13.000000000 +0300 > > +++ dmfe2.txt 2004-07-24 09:46:37.000000000 +0300 > > Patch should be -p1 appliable... meaning these lines will be something > like: --- linux-2.6.12-rc3/Documentation/dmfe.txt ... > +++ linux-dev/Documentation/dmfe.txt ... > > > @@ -1,59 +1,65 @@ > > - dmfe.c: Version 1.28 01/18/2000 > > +Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. > > Trailing whitespace. Nice catch. Here goes the new one : Attached patch indents dmfe.txt to look like other docs. It adds a tip about CNET cards using Davicom chipsets. Also it removes parts where it refers to how to build driver out-of-kernel which seems to be cruft from times where the driver was out of the kernel. Signed-off-by: Ismail Dönmez --Boundary-00=_Ft8bCp6v85r2St9 Content-Type: text/x-diff; charset="Iso-8859-1"; name="dmfe.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmfe.patch" --- linux-2.6.12/Documentation/networking/dmfe.txt 2005-04-27 20:13:04.000000000 +0300 +++ linux-2.6.12/Documentation/networking/dmfe2.txt 2005-04-27 20:22:35.000000000 +0300 @@ -1,59 +1,65 @@ - dmfe.c: Version 1.28 01/18/2000 +Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. - A Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. - Copyright (C) 1997 Sten Wang +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License - as published by the Free Software Foundation; either version 2 - of the License, or (at your option) any later version. +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. +This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET +10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you +didn't compile this driver as a module, it will automatically load itself on boot and print a +line similar to : - A. Compiler command: + dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17) - A-1: For normal single or multiple processor kernel - "gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall - -Wstrict-prototypes -O6 -c dmfe.c" +If you compiled this driver as a module, you have to load it on boot.You can load it with command : - A-2: For single or multiple processor with kernel module version function - "gcc -DMODULE -DMODVERSIONS -D__KERNEL__ -I/usr/src/linux/net/inet - -Wall -Wstrict-prototypes -O6 -c dmfe.c" + insmod dmfe +This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass +a mode= setting to module while loading, like : - B. The following steps teach you how to activate a DM9102 board: + insmod dmfe mode=0 # Force 10M Half Duplex + insmod dmfe mode=1 # Force 100M Half Duplex + insmod dmfe mode=4 # Force 10M Full Duplex + insmod dmfe mode=5 # Force 100M Full Duplex - 1. Used the upper compiler command to compile dmfe.c +Next you should configure your network interface with a command similar to : - 2. Insert dmfe module into kernel - "insmod dmfe" ;;Auto Detection Mode (Suggest) - "insmod dmfe mode=0" ;;Force 10M Half Duplex - "insmod dmfe mode=1" ;;Force 100M Half Duplex - "insmod dmfe mode=4" ;;Force 10M Full Duplex - "insmod dmfe mode=5" ;;Force 100M Full Duplex + ifconfig eth0 172.22.3.18 + ^^^^^^^^^^^ + Your IP Adress - 3. Config a dm9102 network interface - "ifconfig eth0 172.22.3.18" - ^^^^^^^^^^^ Your IP address +Then you may have to modify the default routing table with command : - 4. Activate the IP routing table. For some distributions, it is not - necessary. You can type "route" to check. + route add default eth0 - "route add default eth0" +Now your ethernet card should be up and running. - 5. Well done. Your DM9102 adapter is now activated. +TODO: - C. Object files description: - 1. dmfe_rh61.o: For Redhat 6.1 +Implement pci_driver::suspend() and pci_driver::resume() power management methods. +Check on 64 bit boxes. +Check and fix on big endian boxes. +Test and make sure PCI latency is now correct for all cases. - If you can make sure your kernel version, you can rename - to dmfe.o and directly use it without re-compiling. +Authors: - Author: Sten Wang, 886-3-5798797-8517, E-mail: sten_wang@davicom.com.tw +Sten Wang : Original Author +Tobias Ringstrom : Current Maintainer + +Contributors: + +Marcelo Tosatti +Alan Cox +Jeff Garzik +Vojtech Pavlik --Boundary-00=_Ft8bCp6v85r2St9-- From mallikarjuna.chilakala@intel.com Wed Apr 27 10:27:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:28:03 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHRw1O026186 for ; Wed, 27 Apr 2005 10:27:58 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3PJZgJf018856; Mon, 25 Apr 2005 19:35:42 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3PJZcj1006178; Mon, 25 Apr 2005 19:35:42 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042512354228739 ; Mon, 25 Apr 2005 12:35:42 -0700 Date: Mon, 25 Apr 2005 12:35:42 -0700 (PDT) From: Malli Chilakala To: "jgarzik@pobox.com" cc: netdev Subject: [PATCH net-drivers-2.6 4/11] ixgb: Mask RXO interrupt (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHRw1O026186 X-archive-position: 219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1056 Lines: 23 Disable RXO interrupt to decrease recovery time when system is overloaded with data Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -224,8 +224,8 @@ ixgb_irq_enable(struct ixgb_adapter *ada  {         if(atomic_dec_and_test(&adapter->irq_sem)) {                 IXGB_WRITE_REG(&adapter->hw, IMS, -                          IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | -                          IXGB_INT_RXO | IXGB_INT_LSC); +                              IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | +                              IXGB_INT_LSC);                 IXGB_WRITE_FLUSH(&adapter->hw);         }  } From mallikarjuna.chilakala@intel.com Wed Apr 27 10:34:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:34:06 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHY11O027220 for ; Wed, 27 Apr 2005 10:34:01 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHXxCQ018275; Wed, 27 Apr 2005 17:33:59 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHXpkS004576; Wed, 27 Apr 2005 17:33:59 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710335925588 ; Wed, 27 Apr 2005 10:33:59 -0700 Date: Wed, 27 Apr 2005 10:33:59 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 0/6] e100: driver update (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHY11O027220 X-archive-position: 220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 523 Lines: 15 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak   1. Execute tx_timeout task outside the interrupt context 2. Render e100 NAPI state machine to be similar to the non-NAPI one. 3. Synchronize interface link state with e100 poll routine. 4. Fix wake on lan related issues 5. Performance optimizations to e100 Tx path 6. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Wed Apr 27 10:35:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:35:28 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHZP1O027531 for ; Wed, 27 Apr 2005 10:35:25 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHZKLd025436; Wed, 27 Apr 2005 17:35:20 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHZ12h001760; Wed, 27 Apr 2005 17:35:20 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710352030087 ; Wed, 27 Apr 2005 10:35:20 -0700 Date: Wed, 27 Apr 2005 10:35:20 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 1/6] e100: Execute tx_timeout task outside interrupt context (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHZP1O027531 X-archive-position: 221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1695 Lines: 48 Execute tx_timeout task outside the interrupt context Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -539,6 +539,7 @@ struct nic {         struct timer_list watchdog;         struct timer_list blink_timer;         struct mii_if_info mii; +       struct work_struct tx_timeout_task;         enum loopback loopback;           struct mem *mem; @@ -1716,6 +1717,15 @@ static void e100_tx_timeout(struct net_d  {         struct nic *nic = netdev_priv(netdev);   +       /* Reset outside of interrupt context, to avoid request_irq +        * in interrupt context */ +       schedule_work(&nic->tx_timeout_task); +} + +static void e100_tx_timeout_task(struct net_device *netdev) +{ +       struct nic *nic = netdev_priv(netdev); +         DPRINTK(TX_ERR, DEBUG, "scb.status=0x%02X\n",                 readb(&nic->csr->scb.status));         e100_down(netdev_priv(netdev)); @@ -2240,6 +2250,9 @@ static int __devinit e100_probe(struct p         nic->blink_timer.function = e100_blink_led;         nic->blink_timer.data = (unsigned long)nic;   +       INIT_WORK(&nic->tx_timeout_task, +               (void (*)(void *))e100_tx_timeout_task, netdev); +         if((err = e100_alloc(nic))) {                 DPRINTK(PROBE, ERR, "Cannot alloc driver memory, aborting.\n");                 goto err_out_iounmap; From mallikarjuna.chilakala@intel.com Wed Apr 27 10:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:40:29 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHeQ1O028469 for ; Wed, 27 Apr 2005 10:40:26 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHeMgx014247; Wed, 27 Apr 2005 17:40:22 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHeHkG010338; Wed, 27 Apr 2005 17:40:22 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710402126443 ; Wed, 27 Apr 2005 10:40:21 -0700 Date: Wed, 27 Apr 2005 10:40:22 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 2/6] e100: Render e100 NAPI state machine (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHeQ1O028469 X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 8608 Lines: 240 Render e100 NAPI state machine to be similar to the non-NAPI one. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -269,6 +269,12 @@ enum scb_status {         rus_mask         = 0x3C,  };   +enum ru_state  { +       RU_SUSPENDED = 0, +       RU_RUNNING       = 1, +       RU_UNINITIALIZED = -1, +}; +  enum scb_stat_ack {         stat_ack_not_ours    = 0x00,         stat_ack_sw_gen      = 0x04, @@ -510,7 +515,7 @@ struct nic {         struct rx *rx_to_use;         struct rx *rx_to_clean;         struct rfd blank_rfd; -       int ru_running; +       enum ru_state ru_running;           spinlock_t cb_lock                      ____cacheline_aligned;         spinlock_t cmd_lock; @@ -1204,7 +1210,9 @@ static void e100_update_stats(struct nic                 }         }   -       e100_exec_cmd(nic, cuc_dump_reset, 0); +       +       if(e100_exec_cmd(nic, cuc_dump_reset, 0)) +               DPRINTK(TX_ERR, DEBUG, "exec cuc_dump_reset failed\n");  }    static void e100_adjust_adaptive_ifs(struct nic *nic, int speed, int duplex) @@ -1298,7 +1306,8 @@ static int e100_xmit_frame(struct sk_buf                 /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang.                    Issue a NOP command followed by a 1us delay before                    issuing the Tx command. */ -               e100_exec_cmd(nic, cuc_nop, 0); +               if(e100_exec_cmd(nic, cuc_nop, 0)) +                       DPRINTK(TX_ERR, DEBUG, "exec cuc_nop failed\n");                 udelay(1);         }   @@ -1416,12 +1425,18 @@ static int e100_alloc_cbs(struct nic *ni         return 0;  }   -static inline void e100_start_receiver(struct nic *nic) +static inline void e100_start_receiver(struct nic *nic, struct rx *rx)  { +       if(!nic->rxs) return; +       if(RU_SUSPENDED != nic->ru_running) return; + +       /* handle init time starts */ +       if(!rx) rx = nic->rxs; +         /* (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; +       if(rx->skb) { +               e100_exec_cmd(nic, ruc_start, rx->dma_addr); +               nic->ru_running = RU_RUNNING;         }  }   @@ -1438,6 +1453,13 @@ static inline int e100_rx_alloc_skb(stru         rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data,                 RFD_BUF_LEN, PCI_DMA_BIDIRECTIONAL);   +       if(pci_dma_mapping_error(rx->dma_addr)) { +               dev_kfree_skb_any(rx->skb); +               rx->skb = 0; +               rx->dma_addr = 0; +               return -ENOMEM; +       } +         /* Link the RFD to end of RFA by linking previous RFD to          * this one, and clearing EL bit of previous.  */         if(rx->prev->skb) { @@ -1472,7 +1494,7 @@ static inline int e100_rx_indicate(struc           /* If data isn't ready, nothing to indicate */         if(unlikely(!(rfd_status & cb_complete))) -               return -EAGAIN; +               return -ENODATA;           /* Get actual data size */         actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1483,6 +1505,10 @@ static inline int e100_rx_indicate(struc         pci_unmap_single(nic->pdev, rx->dma_addr,                 RFD_BUF_LEN, PCI_DMA_FROMDEVICE);   +       /* this allows for a fast restart without re-enabling interrupts */ +       if(le16_to_cpu(rfd->command) & cb_el) +               nic->ru_running = RU_SUSPENDED; +         /* Pull off the RFD and put the actual data (minus eth hdr) */         skb_reserve(skb, sizeof(struct rfd));         skb_put(skb, actual_size); @@ -1515,20 +1541,45 @@ static inline void e100_rx_clean(struct         unsigned int work_to_do)  {         struct rx *rx; +       int restart_required = 0; +       struct rx *rx_to_start = NULL; + +       /* are we already rnr? then pay attention!!! this ensures that +        * the state machine progression never allows a start with a +        * partially cleaned list, avoiding a race between hardware +        * and rx_to_clean when in NAPI mode */ +       if(RU_SUSPENDED == nic->ru_running) +               restart_required = 1;           /* Indicate newly arrived packets */         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)) +               int err = e100_rx_indicate(nic, rx, work_done, work_to_do); +               if(-EAGAIN == err) { +                       /* hit quota so have more work to do, restart once +                        * cleanup is complete */ +                       restart_required = 0; +                       break; +               } else if(-ENODATA == err)                         break; /* No more to clean */         }   +       /* save our starting point as the place we'll restart the receiver */ +       if(restart_required) +               rx_to_start = nic->rx_to_clean; +         /* Alloc new skbs to refill list */         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) */         }   -       e100_start_receiver(nic); +       if(restart_required) { +               // ack the rnr? +               writeb(stat_ack_rnr, &nic->csr->scb.stat_ack); +               e100_start_receiver(nic, rx_to_start); +               if(work_done) +                       (*work_done)++; +       }  }    static void e100_rx_clean_list(struct nic *nic) @@ -1536,6 +1587,8 @@ static void e100_rx_clean_list(struct ni         struct rx *rx;         unsigned int i, count = nic->params.rfds.count;   +       nic->ru_running = RU_UNINITIALIZED; +         if(nic->rxs) {                 for(rx = nic->rxs, i = 0; i < count; rx++, i++) {                         if(rx->skb) { @@ -1549,7 +1602,6 @@ static void e100_rx_clean_list(struct ni         }           nic->rx_to_use = nic->rx_to_clean = NULL; -       nic->ru_running = 0;  }    static int e100_rx_alloc_list(struct nic *nic) @@ -1558,6 +1610,7 @@ static int e100_rx_alloc_list(struct nic         unsigned int i, count = nic->params.rfds.count;           nic->rx_to_use = nic->rx_to_clean = NULL; +       nic->ru_running = RU_UNINITIALIZED;           if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC)))                 return -ENOMEM; @@ -1573,6 +1626,7 @@ static int e100_rx_alloc_list(struct nic         }           nic->rx_to_use = nic->rx_to_clean = nic->rxs; +       nic->ru_running = RU_SUSPENDED;           return 0;  } @@ -1594,7 +1648,7 @@ static irqreturn_t e100_intr(int irq, vo           /* We hit Receive No Resource (RNR); restart RU after cleaning */         if(stat_ack & stat_ack_rnr) -               nic->ru_running = 0; +               nic->ru_running = RU_SUSPENDED;           e100_disable_irq(nic);         netif_rx_schedule(netdev); @@ -1684,7 +1700,7 @@ static int e100_up(struct nic *nic)         if((err = e100_hw_init(nic)))                 goto err_clean_cbs;         e100_set_multicast_list(nic->netdev); -       e100_start_receiver(nic); +       e100_start_receiver(nic, 0);         mod_timer(&nic->watchdog, jiffies);         if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,                 nic->netdev->name, nic->netdev))) @@ -1759,7 +1813,7 @@ static int e100_loopback_test(struct nic                 mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR,                         BMCR_LOOPBACK);   -       e100_start_receiver(nic); +       e100_start_receiver(nic, 0);           if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) {                 err = -ENOMEM; @@ -2233,6 +2287,7 @@ static int __devinit e100_probe(struct p           e100_get_defaults(nic);   +       /* locks must be initialized before calling hw_reset */         spin_lock_init(&nic->cb_lock);         spin_lock_init(&nic->cmd_lock);   @@ -2348,7 +2355,8 @@ static int e100_resume(struct pci_dev *p           pci_set_power_state(pdev, PCI_D0);         pci_restore_state(pdev); -       e100_hw_init(nic); +       if(e100_hw_init(nic)) +               DPRINTK(HW, ERR, "e100_hw_init failed\n");           netif_device_attach(netdev);         if(netif_running(netdev)) From mallikarjuna.chilakala@intel.com Wed Apr 27 10:42:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:42:17 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHgE1O028956 for ; Wed, 27 Apr 2005 10:42:14 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHgBCQ023298; Wed, 27 Apr 2005 17:42:11 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHgB2Y012710; Wed, 27 Apr 2005 17:42:11 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710421130892 ; Wed, 27 Apr 2005 10:42:11 -0700 Date: Wed, 27 Apr 2005 10:42:11 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 4/6] e100: Fix Wake on lan related issues (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHgE1O028956 X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3313 Lines: 101 Fix Wake on lan related issues                                                                                                  Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -971,7 +971,8 @@ static void e100_configure(struct nic *n         if(nic->flags & multicast_all)                 config->multicast_all = 0x1;            /* 1=accept, 0=no */   -       if(!(nic->flags & wol_magic)) +       /* disable WoL when up */ +       if(netif_running(nic->netdev) || !(nic->flags & wol_magic))                 config->magic_packet_disable = 0x1;     /* 1=off, 0=on */           if(nic->mac >= mac_82558_D101_A4) { @@ -1718,6 +1719,7 @@ static int e100_change_mtu(struct net_de         return 0;  }   +#ifdef CONFIG_PM  static int e100_asf(struct nic *nic)  {         /* ASF can be enabled from eeprom */ @@ -1726,6 +1728,7 @@ static int e100_asf(struct nic *nic)            !(nic->eeprom[eeprom_config_asf] & eeprom_gcl) &&            ((nic->eeprom[eeprom_smbus_addr] & 0xFF) != 0xFE));  } +#endif    static int e100_up(struct nic *nic)  { @@ -1938,7 +1941,6 @@ static int e100_set_wol(struct net_devic         else                 nic->flags &= ~wol_magic;   -       pci_enable_wake(nic->pdev, 0, nic->flags & (wol_magic | e100_asf(nic)));         e100_exec_cb(nic, NULL, e100_configure);           return 0; @@ -2336,7 +2338,8 @@ static int __devinit e100_probe(struct p            (nic->eeprom[eeprom_id] & eeprom_id_wol))                 nic->flags |= wol_magic;   -       pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); +       /* ack any pending wake events, disable PME */ +       pci_enable_wake(pdev, 0, 0);           strcpy(netdev->name, "eth%d");         if((err = register_netdev(netdev))) { @@ -2408,6 +2347,8 @@ static int e100_resume(struct pci_dev *p           pci_set_power_state(pdev, PCI_D0);         pci_restore_state(pdev); +       /* ack any pending wake events, disable PME */ +       pci_enable_wake(pdev, 0, 0);         if(e100_hw_init(nic))                 DPRINTK(HW, ERR, "e100_hw_init failed\n");   @@ -2419,6 +2424,21 @@ static int e100_resume(struct pci_dev *p  }  #endif   + +static void e100_shutdown(struct device *dev) +{ +       struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); +       struct net_device *netdev = pci_get_drvdata(pdev); +       struct nic *nic = netdev_priv(netdev); + +#ifdef CONFIG_PM +       pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); +#else +       pci_enable_wake(pdev, 0, nic->flags & (wol_magic)); +#endif +} + +  static struct pci_driver e100_driver = {         .name =         DRV_NAME,         .id_table =     e100_id_table, @@ -2428,6 +2448,11 @@ static struct pci_driver e100_driver = {         .suspend =      e100_suspend,         .resume =       e100_resume,  #endif + +       .driver = { +               .shutdown = e100_shutdown, +       } +  };    static int __init e100_init_module(void) From mallikarjuna.chilakala@intel.com Wed Apr 27 10:43:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:43:15 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHhA1O029307 for ; Wed, 27 Apr 2005 10:43:10 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHh6CQ023858; Wed, 27 Apr 2005 17:43:06 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHgZka012072; Wed, 27 Apr 2005 17:43:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710430609443 ; Wed, 27 Apr 2005 10:43:06 -0700 Date: Wed, 27 Apr 2005 10:43:06 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 5/6] e100: Performance optimizations to e100 Tx Path (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHhA1O029307 X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3053 Lines: 71 Performance optimizations to e100 Tx Path Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -777,7 +777,7 @@ static int e100_eeprom_save(struct nic *         return 0;  }   -#define E100_WAIT_SCB_TIMEOUT 40 +#define E100_WAIT_SCB_TIMEOUT 20000 /* we might have to wait 100ms!!! */  static inline int e100_exec_cmd(struct nic *nic, u8 cmd, dma_addr_t dma_addr)  {         unsigned long flags; @@ -847,6 +847,10 @@ static inline int e100_exec_cb(struct ni                          * because the controller is too busy, so                          * let's just queue the command and try again                          * when another command is scheduled. */ +                       if(err == -ENOSPC) { +                               //request a reset +                               schedule_work(&nic->tx_timeout_task); +                       }                         break;                 } else {                         nic->cuc_cmd = cuc_resume; @@ -891,7 +895,7 @@ static void mdio_write(struct net_device    static void e100_get_defaults(struct nic *nic)  { -       struct param_range rfds = { .min = 64, .max = 256, .count = 64 }; +       struct param_range rfds = { .min = 16, .max = 256, .count = 64 };         struct param_range cbs  = { .min = 64, .max = 256, .count = 64 };           pci_read_config_byte(nic->pdev, PCI_REVISION_ID, &nic->rev_id); @@ -906,8 +910,9 @@ static void e100_get_defaults(struct nic         /* Quadwords to DMA into FIFO before starting frame transmit */         nic->tx_threshold = 0xE0;   -       nic->tx_command = cpu_to_le16(cb_tx | cb_i | cb_tx_sf | -               ((nic->mac >= mac_82558_D101_A4) ? cb_cid : 0)); +       /* no interrupt for every tx completion, delay = 256us if not 557*/ +       nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf | +               ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));           /* Template for a freshly allocated RFD */         nic->blank_rfd.command = cpu_to_le16(cb_el); @@ -1289,12 +1294,15 @@ static inline void e100_xmit_prepare(str         struct sk_buff *skb)  {         cb->command = nic->tx_command; +       /* interrupt every 16 packets regardless of delay */ +       if((nic->cbs_avail & ~15) == nic->cbs_avail) cb->command |= cb_i;         cb->u.tcb.tbd_array = cb->dma_addr + offsetof(struct cb, u.tcb.tbd);         cb->u.tcb.tcb_byte_count = 0;         cb->u.tcb.threshold = nic->tx_threshold;         cb->u.tcb.tbd_count = 1;         cb->u.tcb.tbd.buf_addr = cpu_to_le32(pci_map_single(nic->pdev,                 skb->data, skb->len, PCI_DMA_TODEVICE)); +       // check for mapping failure?         cb->u.tcb.tbd.size = cpu_to_le16(skb->len);  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 10:43:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:43:46 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHhe1O029467 for ; Wed, 27 Apr 2005 10:43:41 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHhajI007696; Wed, 27 Apr 2005 17:43:36 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHhHkK012605; Wed, 27 Apr 2005 17:43:35 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710433526775 ; Wed, 27 Apr 2005 10:43:35 -0700 Date: Wed, 27 Apr 2005 10:43:35 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 6/6] e100: Driver version, white space, comments, device id (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHhe1O029467 X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1817 Lines: 45 Driver version, white space, comments. Also enabled ICH-7 support Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -155,9 +155,9 @@    #define DRV_NAME               "e100"  #define DRV_EXT                "-NAPI" -#define DRV_VERSION            "3.3.6-k2"DRV_EXT +#define DRV_VERSION            "3.4.8-k2"DRV_EXT  #define DRV_DESCRIPTION                "Intel(R) PRO/100 Network Driver" -#define DRV_COPYRIGHT          "Copyright(c) 1999-2004 Intel Corporation" +#define DRV_COPYRIGHT          "Copyright(c) 1999-2005 Intel Corporation"  #define PFX                    DRV_NAME ": "    #define E100_WATCHDOG_PERIOD   (2 * HZ) @@ -210,11 +210,17 @@ static struct pci_device_id e100_id_tabl         INTEL_8255X_ETHERNET_DEVICE(0x1069, 6),         INTEL_8255X_ETHERNET_DEVICE(0x106A, 6),         INTEL_8255X_ETHERNET_DEVICE(0x106B, 6), +       INTEL_8255X_ETHERNET_DEVICE(0x1091, 7), +       INTEL_8255X_ETHERNET_DEVICE(0x1092, 7), +       INTEL_8255X_ETHERNET_DEVICE(0x1093, 7), +       INTEL_8255X_ETHERNET_DEVICE(0x1094, 7), +       INTEL_8255X_ETHERNET_DEVICE(0x1095, 7),         INTEL_8255X_ETHERNET_DEVICE(0x1209, 0),         INTEL_8255X_ETHERNET_DEVICE(0x1229, 0),         INTEL_8255X_ETHERNET_DEVICE(0x2449, 2),         INTEL_8255X_ETHERNET_DEVICE(0x2459, 2),         INTEL_8255X_ETHERNET_DEVICE(0x245D, 2), +       INTEL_8255X_ETHERNET_DEVICE(0x27DC, 7),         { 0, }  };  MODULE_DEVICE_TABLE(pci, e100_id_table); From mallikarjuna.chilakala@intel.com Wed Apr 27 10:46:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:46:29 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHkO1O030791 for ; Wed, 27 Apr 2005 10:46:24 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHkG4C008259; Wed, 27 Apr 2005 17:46:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHjJft019532; Wed, 27 Apr 2005 17:46:13 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710405704820 ; Wed, 27 Apr 2005 10:41:00 -0700 Date: Wed, 27 Apr 2005 10:40:56 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 3/6] e100: Synchronize interface link state with poll routine (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHkO1O030791 X-archive-position: 227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1458 Lines: 42 Synchronize interface link state with e100 poll routine Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c  2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new      2005-04-07 03:22:37.251205992 -0700 @@ -1743,8 +1743,11 @@ static int e100_up(struct nic *nic)         if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,                 nic->netdev->name, nic->netdev)))                 goto err_no_irq; -       e100_enable_irq(nic);         netif_wake_queue(nic->netdev); +       netif_poll_enable(nic->netdev); +       /* enable ints _after_ enabling poll, preventing a race between +        * disable ints+schedule */ +       e100_enable_irq(nic);         return 0;    err_no_irq: @@ -1758,11 +1758,13 @@ err_rx_clean_list:    static void e100_down(struct nic *nic)  { +       /* wait here for poll to complete */ +       netif_poll_disable(nic->netdev); +       netif_stop_queue(nic->netdev);         e100_hw_reset(nic);         free_irq(nic->pdev->irq, nic->netdev);         del_timer_sync(&nic->watchdog);         netif_carrier_off(nic->netdev); -       netif_stop_queue(nic->netdev);         e100_clean_cbs(nic);         e100_rx_clean_list(nic);  } From mallikarjuna.chilakala@intel.com Wed Apr 27 10:46:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:46:21 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHkG1O030768 for ; Wed, 27 Apr 2005 10:46:18 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHkCgx016576; Wed, 27 Apr 2005 17:46:12 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHk3kK014912; Wed, 27 Apr 2005 17:46:12 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710461209776 ; Wed, 27 Apr 2005 10:46:12 -0700 Date: Wed, 27 Apr 2005 10:46:12 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 0/11] ixgb: driver update (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 698 Lines: 18 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Fix multi-cast packet count in statistics 2. Do not set the RS bit on context descriptors 3. Change RDT write bump size back to 4 4. Mask RXO interrupt 5. Reset status in the Rx descriptor prior to handing it to the controller 6. Fix EEPROM functions to be endian-aware 7. Support for ethtool -d 8. Remove hook for suspend. No power management in 10GbE Controllers 9. Code optimization 10. Fixed msec_delay in osdep to use msleep 11. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Wed Apr 27 10:46:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:46:56 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHkn1O030854 for ; Wed, 27 Apr 2005 10:46:49 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHkkLd031133; Wed, 27 Apr 2005 17:46:46 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHkk2Y019623; Wed, 27 Apr 2005 17:46:46 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710464631474 ; Wed, 27 Apr 2005 10:46:46 -0700 Date: Wed, 27 Apr 2005 10:46:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 1/11] ixgb: Fix multi-cast packet count in statistics (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHkn1O030854 X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2590 Lines: 53 Fix multi-cast packet count in statistics Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -1526,14 +1526,33 @@ ixgb_change_mtu(struct net_device *netde  void  ixgb_update_stats(struct ixgb_adapter *adapter)  { +       struct net_device *netdev = adapter->netdev; + +       if((netdev->flags & IFF_PROMISC) || (netdev->flags & IFF_ALLMULTI) || +          (netdev->mc_count > IXGB_MAX_NUM_MULTICAST_ADDRESSES)) { +               u64 multi = IXGB_READ_REG(&adapter->hw, MPRCL); +               u32 bcast_l = IXGB_READ_REG(&adapter->hw, BPRCL); +               u32 bcast_h = IXGB_READ_REG(&adapter->hw, BPRCH); +               u64 bcast = ((u64)bcast_h << 32) | bcast_l; + +               multi |= ((u64)IXGB_READ_REG(&adapter->hw, MPRCH) << 32); +               /* fix up multicast stats by removing broadcasts */ +               multi -= bcast; +               +               adapter->stats.mprcl += (multi & 0xFFFFFFFF); +               adapter->stats.mprch += (multi >> 32); +               adapter->stats.bprcl += bcast_l; +               adapter->stats.bprch += bcast_h; +       } else { +               adapter->stats.mprcl += IXGB_READ_REG(&adapter->hw, MPRCL); +               adapter->stats.mprch += IXGB_READ_REG(&adapter->hw, MPRCH); +               adapter->stats.bprcl += IXGB_READ_REG(&adapter->hw, BPRCL); +               adapter->stats.bprch += IXGB_READ_REG(&adapter->hw, BPRCH); +       }         adapter->stats.tprl += IXGB_READ_REG(&adapter->hw, TPRL);         adapter->stats.tprh += IXGB_READ_REG(&adapter->hw, TPRH);         adapter->stats.gprcl += IXGB_READ_REG(&adapter->hw, GPRCL);         adapter->stats.gprch += IXGB_READ_REG(&adapter->hw, GPRCH); -       adapter->stats.bprcl += IXGB_READ_REG(&adapter->hw, BPRCL); -       adapter->stats.bprch += IXGB_READ_REG(&adapter->hw, BPRCH); -       adapter->stats.mprcl += IXGB_READ_REG(&adapter->hw, MPRCL); -       adapter->stats.mprch += IXGB_READ_REG(&adapter->hw, MPRCH);         adapter->stats.uprcl += IXGB_READ_REG(&adapter->hw, UPRCL);         adapter->stats.uprch += IXGB_READ_REG(&adapter->hw, UPRCH);         adapter->stats.vprcl += IXGB_READ_REG(&adapter->hw, VPRCL); From mallikarjuna.chilakala@intel.com Wed Apr 27 10:47:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:47:32 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHlR1O031432 for ; Wed, 27 Apr 2005 10:47:27 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHlMgx017032; Wed, 27 Apr 2005 17:47:23 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHkk38019623; Wed, 27 Apr 2005 17:47:22 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710472131547 ; Wed, 27 Apr 2005 10:47:22 -0700 Date: Wed, 27 Apr 2005 10:47:21 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 2/11] ixgb: Do not set the RS bit on context descriptors (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHlR1O031432 X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1795 Lines: 37 Don't set the RS bit on context descriptors, causes un-necessary bus activity Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -1209,9 +1209,9 @@ ixgb_tso(struct ixgb_adapter *adapter, s                                                 | IXGB_CONTEXT_DESC_CMD_TSE                                                 | IXGB_CONTEXT_DESC_CMD_IP                                                 | IXGB_CONTEXT_DESC_CMD_TCP -                                               | IXGB_CONTEXT_DESC_CMD_RS                                                 | IXGB_CONTEXT_DESC_CMD_IDE                                                 | (skb->len - (hdr_len))); +                   if(++i == adapter->tx_ring.count) i = 0;                 adapter->tx_ring.next_to_use = i; @@ -1246,9 +1246,8 @@ ixgb_tx_csum(struct ixgb_adapter *adapte                 context_desc->hdr_len = 0;                 context_desc->mss = 0;                 context_desc->cmd_type_len = -                       cpu_to_le32(IXGB_CONTEXT_DESC_TYPE -                                       | IXGB_TX_DESC_CMD_RS -                                       | IXGB_TX_DESC_CMD_IDE); +                       cpu_to_le32(IXGB_CONTEXT_DESC_TYPE +                                   | IXGB_TX_DESC_CMD_IDE);                   if(++i == adapter->tx_ring.count) i = 0;                 adapter->tx_ring.next_to_use = i; From mallikarjuna.chilakala@intel.com Wed Apr 27 10:48:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:48:14 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHm91O032097 for ; Wed, 27 Apr 2005 10:48:09 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHm6Ld031853; Wed, 27 Apr 2005 17:48:06 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHm6kC016595; Wed, 27 Apr 2005 17:48:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710480506329 ; Wed, 27 Apr 2005 10:48:05 -0700 Date: Wed, 27 Apr 2005 10:48:06 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 3/11] ixgb: Change RDT write bump size to 4 (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHm91O032097 X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 900 Lines: 23 Change RDT write bump size back to 4 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb.h net-drivers-2.6/drivers/net/ixgb.new/ixgb.h --- net-drivers-2.6/drivers/net/ixgb/ixgb.h     2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb.h 2005-04-05 23:06:38.056967256 -0700 @@ -110,7 +110,7 @@ struct ixgb_adapter;  #define IXGB_TX_QUEUE_WAKE 16    /* How many Rx Buffers do we bundle into one write to the hardware ? */ -#define IXGB_RX_BUFFER_WRITE   16      /* Must be power of 2 */ +#define IXGB_RX_BUFFER_WRITE   4       /* Must be power of 2 */    /* only works for sizes that are powers of 2 */  #define IXGB_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) & ~((size) - 1))) From mallikarjuna.chilakala@intel.com Wed Apr 27 10:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:48:49 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHmg1O032596 for ; Wed, 27 Apr 2005 10:48:42 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHmdCQ027031; Wed, 27 Apr 2005 17:48:39 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHmdkC016922; Wed, 27 Apr 2005 17:48:39 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710483810048 ; Wed, 27 Apr 2005 10:48:38 -0700 Date: Wed, 27 Apr 2005 10:48:38 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 4/11] ixgb: Mask RXO interrupt (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHmg1O032596 X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1058 Lines: 25 Disable RXO interrupt to decrease recovery time when system is overloaded with data Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -224,8 +224,8 @@ ixgb_irq_enable(struct ixgb_adapter *ada  {         if(atomic_dec_and_test(&adapter->irq_sem)) {                 IXGB_WRITE_REG(&adapter->hw, IMS, -                          IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | -                          IXGB_INT_RXO | IXGB_INT_LSC); +                              IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | +                              IXGB_INT_LSC);                 IXGB_WRITE_FLUSH(&adapter->hw);         }  } From mallikarjuna.chilakala@intel.com Wed Apr 27 10:49:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:50:03 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHnx1O001300 for ; Wed, 27 Apr 2005 10:49:59 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHnoCQ027907; Wed, 27 Apr 2005 17:49:51 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHnfkM017786; Wed, 27 Apr 2005 17:49:50 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710495027542 ; Wed, 27 Apr 2005 10:49:50 -0700 Date: Wed, 27 Apr 2005 10:49:50 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 6/11] ixgb: Fix EEPROM functions to be endian-aware (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHnx1O001300 X-archive-position: 232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 4544 Lines: 123 Fix EEPROM functions to be endian-aware Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c  2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c      2005-04-05 23:06:37.998976072 -0700 @@ -411,7 +411,7 @@ ixgb_write_eeprom(struct ixgb_hw *hw, ui         ixgb_cleanup_eeprom(hw);           /* clear the init_ctrl_reg_1 to signify that the cache is invalidated */ -       ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; +       ee_map->init_ctrl_reg_1 = le16_to_cpu(EEPROM_ICW1_SIGNATURE_CLEAR);           return;  } @@ -483,7 +461,7 @@ ixgb_get_eeprom_data(struct ixgb_hw *hw)                 DEBUGOUT("ixgb_ee: Checksum invalid.\n");                 /* clear the init_ctrl_reg_1 to signify that the cache is                  * invalidated */ -               ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; +               ee_map->init_ctrl_reg_1 = le16_to_cpu(EEPROM_ICW1_SIGNATURE_CLEAR);                 return (FALSE);         }   @@ -579,7 +568,7 @@ ixgb_get_ee_compatibility(struct ixgb_hw         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->compatibility); +               return (le16_to_cpu(ee_map->compatibility));           return(0);  } @@ -616,7 +605,7 @@ ixgb_get_ee_init_ctrl_reg_1(struct ixgb_         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->init_ctrl_reg_1); +               return (le16_to_cpu(ee_map->init_ctrl_reg_1));           return(0);  } @@ -635,7 +624,7 @@ ixgb_get_ee_init_ctrl_reg_2(struct ixgb_         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->init_ctrl_reg_2); +               return (le16_to_cpu(ee_map->init_ctrl_reg_2));           return(0);  } @@ -654,7 +643,7 @@ ixgb_get_ee_subsystem_id(struct ixgb_hw         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -          return(ee_map->subsystem_id); +               return (le16_to_cpu(ee_map->subsystem_id));           return(0);  } @@ -673,7 +662,7 @@ ixgb_get_ee_subvendor_id(struct ixgb_hw         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->subvendor_id); +               return (le16_to_cpu(ee_map->subvendor_id));           return(0);  } @@ -692,7 +681,7 @@ ixgb_get_ee_device_id(struct ixgb_hw *hw         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->device_id); +               return (le16_to_cpu(ee_map->device_id));           return(0);  } @@ -711,7 +700,7 @@ ixgb_get_ee_vendor_id(struct ixgb_hw *hw         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->vendor_id); +               return (le16_to_cpu(ee_map->vendor_id));           return(0);  } @@ -730,7 +719,7 @@ ixgb_get_ee_swdpins_reg(struct ixgb_hw *         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->swdpins_reg); +               return (le16_to_cpu(ee_map->swdpins_reg));           return(0);  } @@ -749,7 +738,7 @@ ixgb_get_ee_d3_power(struct ixgb_hw *hw)         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->d3_power); +               return (le16_to_cpu(ee_map->d3_power));           return(0);  } @@ -768,7 +757,7 @@ ixgb_get_ee_d0_power(struct ixgb_hw *hw)         struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;           if(ixgb_check_and_get_eeprom_data(hw) == TRUE) -               return(ee_map->d0_power); +               return (le16_to_cpu(ee_map->d0_power));           return(0);  } From mallikarjuna.chilakala@intel.com Wed Apr 27 10:50:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:50:29 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHoO1O001554 for ; Wed, 27 Apr 2005 10:50:24 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHoKjI011247; Wed, 27 Apr 2005 17:50:20 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHoJkG018469; Wed, 27 Apr 2005 17:50:20 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710502006599 ; Wed, 27 Apr 2005 10:50:20 -0700 Date: Wed, 27 Apr 2005 10:50:20 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 7/11] ixgb: Support for ethtool -d (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHoO1O001554 X-archive-position: 233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1034 Lines: 26 ixgb support for ethtool -d Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c     2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c 2005-04-05 23:06:38.037970144 -0700 @@ -252,7 +252,9 @@ ixgb_get_regs(struct net_device *netdev,         uint32_t *reg_start = reg;         uint8_t i;   -       regs->version = (adapter->hw.device_id << 16) | adapter->hw.subsystem_id; +       /* the 1 (one) below indicates an attempt at versioning, if the +        * interface in ethtool or the driver this 1 should be incremented */ +       regs->version = (1<<24) | hw->revision_id << 16 | hw->device_id;           /* General Registers */         *reg++ = IXGB_READ_REG(hw, CTRL0);      /*   0 */ From mallikarjuna.chilakala@intel.com Wed Apr 27 10:50:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:51:01 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHov1O002000 for ; Wed, 27 Apr 2005 10:50:57 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHorLd000869; Wed, 27 Apr 2005 17:50:53 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHorkC018959; Wed, 27 Apr 2005 17:50:53 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710505206653 ; Wed, 27 Apr 2005 10:50:52 -0700 Date: Wed, 27 Apr 2005 10:50:53 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 8/11] ixgb: Remove hook for suspend, no power management (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHov1O002000 X-archive-position: 234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 4004 Lines: 133 Remove hook for suspend. No power management in 10GbE Controllers   Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -120,33 +120,20 @@ static int ixgb_change_mtu(struct net_de  static void ixgb_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid);  static void ixgb_restore_vlan(struct ixgb_adapter *adapter);   -static int ixgb_notify_reboot(struct notifier_block *, unsigned long event, -                             void *ptr); -static int ixgb_suspend(struct pci_dev *pdev, uint32_t state); -  #ifdef CONFIG_NET_POLL_CONTROLLER  /* for netdump / net console */  static void ixgb_netpoll(struct net_device *dev);  #endif   -struct notifier_block ixgb_notifier_reboot = { -       .notifier_call = ixgb_notify_reboot, -       .next = NULL, -       .priority = 0 -}; -  /* Exported from other modules */    extern void ixgb_check_options(struct ixgb_adapter *adapter);    static struct pci_driver ixgb_driver = { -       .name = ixgb_driver_name, +       .name     = ixgb_driver_name,         .id_table = ixgb_pci_tbl, -       .probe = ixgb_probe, -       .remove = __devexit_p(ixgb_remove), -       /* Power Managment Hooks */ -       .suspend = NULL, -       .resume = NULL +       .probe    = ixgb_probe, +       .remove   = __devexit_p(ixgb_remove),  };    MODULE_AUTHOR("Intel Corporation, "); @@ -169,17 +179,12 @@ MODULE_LICENSE("GPL");  static int __init  ixgb_init_module(void)  { -       int ret;         printk(KERN_INFO "%s - version %s\n",                ixgb_driver_string, ixgb_driver_version);           printk(KERN_INFO "%s\n", ixgb_copyright);   -       ret = pci_module_init(&ixgb_driver); -       if(ret >= 0) { -               register_reboot_notifier(&ixgb_notifier_reboot); -       } -       return ret; +       return pci_module_init(&ixgb_driver);  }    module_init(ixgb_init_module); @@ -194,7 +194,6 @@ module_init(ixgb_init_module);  static void __exit  ixgb_exit_module(void)  { -       unregister_reboot_notifier(&ixgb_notifier_reboot);         pci_unregister_driver(&ixgb_driver);  }   @@ -2121,54 +2092,6 @@ ixgb_restore_vlan(struct ixgb_adapter *a         }  }   -/** - * ixgb_notify_reboot - handles OS notification of reboot event. - * @param nb notifier block, unused - * @param event Event being passed to driver to act upon - * @param p A pointer to our net device - **/ -static int -ixgb_notify_reboot(struct notifier_block *nb, unsigned long event, void *p) -{ -       struct pci_dev *pdev = NULL; - -       switch(event) { -       case SYS_DOWN: -       case SYS_HALT: -       case SYS_POWER_OFF: -               while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { -                       if (pci_dev_driver(pdev) == &ixgb_driver) -                               ixgb_suspend(pdev, 3); -               } -       } -       return NOTIFY_DONE; -} - -/** - * ixgb_suspend - driver suspend function called from notify. - * @param pdev pci driver structure used for passing to - * @param state power state to enter - **/ -static int -ixgb_suspend(struct pci_dev *pdev, uint32_t state) -{ -       struct net_device *netdev = pci_get_drvdata(pdev); -       struct ixgb_adapter *adapter = netdev->priv; - -       netif_device_detach(netdev); - -       if(netif_running(netdev)) -               ixgb_down(adapter, TRUE); - -       pci_save_state(pdev); - -       state = (state > 0) ? 3 : 0; -       pci_set_power_state(pdev, state); -       msec_delay(200); - -       return 0; -} -  #ifdef CONFIG_NET_POLL_CONTROLLER  /*   * Polling 'interrupt' - used by things like netconsole to send skbs From mallikarjuna.chilakala@intel.com Wed Apr 27 10:51:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:51:37 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHpX1O002505 for ; Wed, 27 Apr 2005 10:51:33 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHpSCQ028962; Wed, 27 Apr 2005 17:51:28 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHpHkM019295; Wed, 27 Apr 2005 17:51:28 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710512710396 ; Wed, 27 Apr 2005 10:51:27 -0700 Date: Wed, 27 Apr 2005 10:51:27 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 9/11] ixgb: Code optimization (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHpX1O002505 X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 4151 Lines: 110 Code optimization Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -1822,7 +1822,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a         struct pci_dev *pdev = adapter->pdev;         struct ixgb_rx_desc *rx_desc, *next_rxd;         struct ixgb_buffer *buffer_info, *next_buffer, *next2_buffer; -       struct sk_buff *skb, *next_skb;         uint32_t length;         unsigned int i, j;         boolean_t cleaned = FALSE; @@ -1832,6 +1831,8 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a         buffer_info = &rx_ring->buffer_info[i];           while(rx_desc->status & IXGB_RX_DESC_STATUS_DD) { +               struct sk_buff *skb, *next_skb; +               u8 status;    #ifdef CONFIG_IXGB_NAPI                 if(*work_done >= work_to_do) @@ -1839,7 +1840,9 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a                   (*work_done)++;  #endif +               status = rx_desc->status;                 skb = buffer_info->skb; +                 prefetch(skb->data);                   if(++i == rx_ring->count) i = 0; @@ -1864,7 +1835,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a                   length = le16_to_cpu(rx_desc->length);   -               if(unlikely(!(rx_desc->status & IXGB_RX_DESC_STATUS_EOP))) { +               if(unlikely(!(status & IXGB_RX_DESC_STATUS_EOP))) {                           /* All receives must fit into a single buffer */   @@ -1872,12 +1835,7 @@                                          "length<%x>\n", length);                           dev_kfree_skb_irq(skb); -                       rx_desc->status = 0; -                       buffer_info->skb = NULL; - -                       rx_desc = next_rxd; -                       buffer_info = next_buffer; -                       continue; +                       goto rxdesc_done;                 }                   if (unlikely(rx_desc->errors @@ -1886,12 +1835,7 @@                                 IXGB_RX_DESC_ERRORS_RXE))) {                           dev_kfree_skb_irq(skb); -                       rx_desc->status = 0; -                       buffer_info->skb = NULL; - -                       rx_desc = next_rxd; -                       buffer_info = next_buffer; -                       continue; +                       goto rxdesc_done;                 }                   /* Good Receive */ @@ -1902,7 +1879,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a                   skb->protocol = eth_type_trans(skb, netdev);  #ifdef CONFIG_IXGB_NAPI -               if(adapter->vlgrp && (rx_desc->status & IXGB_RX_DESC_STATUS_VP)) { +               if(adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) {                         vlan_hwaccel_receive_skb(skb, adapter->vlgrp,                                 le16_to_cpu(rx_desc->special) &                                         IXGB_RX_DESC_SPECIAL_VLAN_MASK); @@ -1910,7 +1879,7 @@                         netif_receive_skb(skb);                 }  #else /* CONFIG_IXGB_NAPI */ -               if(adapter->vlgrp && (rx_desc->status & IXGB_RX_DESC_STATUS_VP)) { +               if(adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) {                         vlan_hwaccel_rx(skb, adapter->vlgrp,                                 le16_to_cpu(rx_desc->special) &                                         IXGB_RX_DESC_SPECIAL_VLAN_MASK); @@ -1920,9 +1913,12 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a  #endif /* CONFIG_IXGB_NAPI */                 netdev->last_rx = jiffies;   +rxdesc_done: +               /* clean up descriptor, might be written over by hw */                 rx_desc->status = 0;                 buffer_info->skb = NULL;   +               /* use prefetched values */                 rx_desc = next_rxd;                 buffer_info = next_buffer;         } From mallikarjuna.chilakala@intel.com Wed Apr 27 10:53:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:53:30 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHrR1O003830 for ; Wed, 27 Apr 2005 10:53:28 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHrOLd002217; Wed, 27 Apr 2005 17:53:24 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHr42k029155; Wed, 27 Apr 2005 17:53:24 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710532432335 ; Wed, 27 Apr 2005 10:53:24 -0700 Date: Wed, 27 Apr 2005 10:53:24 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 10/11] ixgb: Fixed msec_delay in osdep to use msleep (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHrR1O003830 X-archive-position: 236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 934 Lines: 24 Fixed msec_delay in osdep to use msleep Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h       2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h   2005-04-05 23:06:38.300930168 -0700 @@ -45,8 +45,7 @@                                 /* Don't mdelay in interrupt context! */ \                                 BUG(); \                         } else { \ -                               set_current_state(TASK_UNINTERRUPTIBLE); \ -                               schedule_timeout((x * HZ)/1000 + 2); \ +                               msleep(x); \                         } } while(0)  #endif   From mallikarjuna.chilakala@intel.com Wed Apr 27 10:54:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:54:04 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHrx1O003966 for ; Wed, 27 Apr 2005 10:54:00 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHruCQ030283; Wed, 27 Apr 2005 17:53:56 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHrkkG021257; Wed, 27 Apr 2005 17:53:56 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710535510671 ; Wed, 27 Apr 2005 10:53:55 -0700 Date: Wed, 27 Apr 2005 10:53:55 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 11/11] ixgb: Driver version, white space, comments, device id (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RHrx1O003966 X-archive-position: 237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2019 Lines: 55 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c        2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c    2005-04-05 23:06:38.283932752 -0700 @@ -47,7 +47,7 @@ char ixgb_driver_string[] = "Intel(R) PR  #else  #define DRIVERNAPI "-NAPI"  #endif -char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_driver_version[] = "1.0.95-k2"DRIVERNAPI;  char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";    /* ixgb_pci_tbl - PCI Device ID Table @@ -103,6 +103,7 @@ static int ixgb_change_mtu(struct net_de  static int ixgb_set_mac(struct net_device *netdev, void *p);  static irqreturn_t ixgb_intr(int irq, void *data, struct pt_regs *regs);  static boolean_t ixgb_clean_tx_irq(struct ixgb_adapter *adapter); +  #ifdef CONFIG_IXGB_NAPI  static int ixgb_clean(struct net_device *netdev, int *budget);  static boolean_t ixgb_clean_rx_irq(struct ixgb_adapter *adapter, @@ -1253,6 +1254,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter           unsigned int nr_frags = skb_shinfo(skb)->nr_frags;         unsigned int f; +         len -= skb->data_len;           i = tx_ring->next_to_use; @@ -1857,7 +1833,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a                 next_skb = next_buffer->skb;                 prefetch(next_skb);   -                 cleaned = TRUE;                   pci_unmap_single(pdev, @@ -2108,6 +2095,7 @@ ixgb_restore_vlan(struct ixgb_adapter *a  static void ixgb_netpoll(struct net_device *dev)  {         struct ixgb_adapter *adapter = dev->priv; +         disable_irq(adapter->pdev->irq);         ixgb_intr(adapter->pdev->irq, dev, NULL);         enable_irq(adapter->pdev->irq); From mallikarjuna.chilakala@intel.com Wed Apr 27 10:54:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 10:54:06 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RHs21O003992 for ; Wed, 27 Apr 2005 10:54:02 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RHrw15011104; Wed, 27 Apr 2005 17:53:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RHpggb024185; Wed, 27 Apr 2005 17:53:53 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042710491207975 ; Wed, 27 Apr 2005 10:49:15 -0700 Date: Wed, 27 Apr 2005 10:49:12 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 5/11] ixgb: Reset status in the Rx descriptor prior to handing it to the controller (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1537 Lines: 37 Reset status in the Rx descriptor prior to handing it to the controller. Leave three Rx descriptors unused Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1977,8 +1977,8 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte num_group_tail_writes = IXGB_RX_BUFFER_WRITE; - /* leave one descriptor unused */ - while(--cleancount > 0) { + /* leave three descriptors unused */ + while(--cleancount > 2) { rx_desc = IXGB_RX_DESC(*rx_ring, i); skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); @@ -2005,6 +1933,10 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte PCI_DMA_FROMDEVICE); rx_desc->buff_addr = cpu_to_le64(buffer_info->dma); + /* guarantee DD bit not set now before h/w gets descriptor + * this is the rest of the workaround for h/w double + * writeback. */ + rx_desc->status = 0; if((i & ~(num_group_tail_writes- 1)) == i) { /* Force memory writes to complete before letting h/w From mallikarjuna.chilakala@intel.com Wed Apr 27 11:00:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:01:04 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI0v1O006787 for ; Wed, 27 Apr 2005 11:00:57 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI0oCQ001797; Wed, 27 Apr 2005 18:00:50 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI0MkX026424; Wed, 27 Apr 2005 18:00:50 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711005028791 ; Wed, 27 Apr 2005 11:00:50 -0700 Date: Wed, 27 Apr 2005 11:00:50 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 0/16] e1000: driver update (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI0v1O006787 X-archive-position: 239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1463 Lines: 28 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Added enhanced functionality to the loopback diags to wrap the descriptor rings. 2. Fix msec-delay definition in e1000_osdep.h to use msleep 3. MSI support for PCI-e adapters 4. Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] 5. Fix kernel panic with 82541 LOM when using a 100M cable 6. Delay clean-up of last Tx packet to fix pre-mature writeback issue of Tx descriptors only when TSO is enabled 7. Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached 8. Fix computation of netdev stats from controller stats counters 9. e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch 10. Implement 82546 errata 10 --  first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. 11. Removed redundant statement in e1000_clean_tx_irq 12. Modified e1000_clean:: exit poll if no Tx and work_done == 0 13. 82573 specific code & packet split code 14. Fix Packet Buffer Allocation logic for 82547_rev_2 controller 15. Adjust flow control watermarks for Jumbo Frames 16. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Wed Apr 27 11:02:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:02:54 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI2l1O007906 for ; Wed, 27 Apr 2005 11:02:50 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI2ggx022094; Wed, 27 Apr 2005 18:02:42 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI2dkE028475; Wed, 27 Apr 2005 18:02:42 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711024129058 ; Wed, 27 Apr 2005 11:02:41 -0700 Date: Wed, 27 Apr 2005 11:02:41 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 2/16] e1000: Fix msec-delay definition to use msleep (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI2l1O007906 X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1175 Lines: 26 Fix msec-delay definition in e1000_osdep.h to use msleep Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_osdep.h net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.4/drivers/net/e1000/e1000_osdep.h     2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h 2005-04-12 23:00:55.000000000 -0700 @@ -46,9 +46,9 @@                                 /* Don't mdelay in interrupt context! */ \                                 BUG(); \                         } else { \ -                               set_current_state(TASK_UNINTERRUPTIBLE); \ -                               schedule_timeout((x * HZ)/1000 + 2); \ +                               msleep(x); \                         } } while(0) +  /* Some workarounds require millisecond delays and are run during interrupt   * context.  Most notably, when establishing link, the phy may need tweaking   * but cannot process phy register reads/writes faster than millisecond From mallikarjuna.chilakala@intel.com Wed Apr 27 11:04:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:04:14 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI4B1O008856 for ; Wed, 27 Apr 2005 11:04:11 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI46jI018558; Wed, 27 Apr 2005 18:04:06 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI3vkK029729; Wed, 27 Apr 2005 18:04:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711040608099 ; Wed, 27 Apr 2005 11:04:06 -0700 Date: Wed, 27 Apr 2005 11:04:06 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 4/16] e1000:Enable polling before enabling interrupts (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI4B1O008856 X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 977 Lines: 29 Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -325,11 +325,12 @@ e1000_up(struct e1000_adapter *adapter)                 return err;           mod_timer(&adapter->watchdog_timer, jiffies); -       e1000_irq_enable(adapter);    #ifdef CONFIG_E1000_NAPI         netif_poll_enable(netdev);  #endif +       e1000_irq_enable(adapter); +         return 0;  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:04:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:04:42 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI4c1O009160 for ; Wed, 27 Apr 2005 11:04:38 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI4ZLd008209; Wed, 27 Apr 2005 18:04:35 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI4RkK030165; Wed, 27 Apr 2005 18:04:35 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711043429259 ; Wed, 27 Apr 2005 11:04:35 -0700 Date: Wed, 27 Apr 2005 11:04:35 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 5/16] e1000:Fix kernel panic with 82541 LOM (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI4c1O009160 X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 834 Lines: 22 Fix kernel panic with 82541 LOM when using a 100M cable Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -369,6 +369,7 @@ e1000_down(struct e1000_adapter *adapter                 e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg);                 mii_reg |= MII_CR_POWER_DOWN;                 e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg); +               mdelay(1);         }  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:05:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:05:11 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI561O009492 for ; Wed, 27 Apr 2005 11:05:06 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI53gx023249; Wed, 27 Apr 2005 18:05:03 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI52kE030637; Wed, 27 Apr 2005 18:05:03 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711050308209 ; Wed, 27 Apr 2005 11:05:03 -0700 Date: Wed, 27 Apr 2005 11:05:03 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 6/16] e1000: Delay clean-up of last Tx packet (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from BASE64 to 8bit by oss.sgi.com id j3RI561O009492 X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3937 Lines: 81 Delay clean-up of last Tx packet to fix pre-mature writeback issue of Tx descriptors only when TSO is enabled Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -2341,11 +2341,10 @@ e1000_clean_tx_irq(struct e1000_adapter         eop_desc = E1000_TX_DESC(*tx_ring, eop);           while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { -               /* pre-mature writeback of Tx descriptors     */ -               /* clear (free buffers and unmap pci_mapping) */ -               /* previous_buffer_info                       */ +               /* Premature writeback of Tx descriptors clear (free buffers +                * and unmap pci_mapping) previous_buffer_info */                 if (likely(adapter->previous_buffer_info.skb != NULL)) { -                       e1000_unmap_and_free_tx_resource(adapter, +                       e1000_unmap_and_free_tx_resource(adapter,                                         &adapter->previous_buffer_info);                 }   @@ -2354,20 +2725,25 @@ e1000_clean_tx_irq(struct e1000_adapter                         buffer_info = &tx_ring->buffer_info[i];                         cleaned = (i == eop);   -                       /* pre-mature writeback of Tx descriptors */ -                       /* save the cleaning of the this for the  */ -                       /* next iteration                         */ -                       if (cleaned) { -                               memcpy(&adapter->previous_buffer_info, -                                       buffer_info, -                                       sizeof(struct e1000_buffer)); -                               memset(buffer_info, -                                       0, -                                       sizeof(struct e1000_buffer)); +#ifdef NETIF_F_TSO +                       if (!(netdev->features & NETIF_F_TSO)) { +#endif +                               e1000_unmap_and_free_tx_resource(adapter, +                                                                buffer_info); +#ifdef NETIF_F_TSO                         } else { -                               e1000_unmap_and_free_tx_resource(adapter, -                                                       buffer_info); +                               if (cleaned) { +                                       memcpy(&adapter->previous_buffer_info, +                                              buffer_info, +                                              sizeof(struct e1000_buffer)); +                                       memset(buffer_info, 0, +                                              sizeof(struct e1000_buffer)); +                               } else { +                                       e1000_unmap_and_free_tx_resource( +                                           adapter, buffer_info); +                               }                         } +#endif                           tx_desc->buffer_addr = 0;                         tx_desc->lower.data = 0; @@ -2400,7 +2760,14 @@ e1000_clean_tx_irq(struct e1000_adapter                    !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF))                         netif_stop_queue(netdev);         } +#ifdef NETIF_F_TSO + +       if( unlikely(!(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) && +           time_after(jiffies, adapter->previous_buffer_info.time_stamp + HZ))) +               e1000_unmap_and_free_tx_resource( +                   adapter, &adapter->previous_buffer_info);   +#endif         return cleaned;  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:05:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:05:52 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI5d1O010060 for ; Wed, 27 Apr 2005 11:05:39 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI5Zgx023427; Wed, 27 Apr 2005 18:05:35 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI5YkE031210; Wed, 27 Apr 2005 18:05:35 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711053512026 ; Wed, 27 Apr 2005 11:05:35 -0700 Date: Wed, 27 Apr 2005 11:05:35 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 7/16] e1000: Dump information on Tx ring (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI5d1O010060 X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2914 Lines: 55 Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -2399,10 +2399,37 @@ e1000_clean_tx_irq(struct e1000_adapter                 /* detect a transmit hang in hardware, this serializes the                  * check with the clearing of time_stamp and movement of i */                 adapter->detect_tx_hung = FALSE; -               if(tx_ring->buffer_info[i].dma && -                  time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && -                  !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) +               if (tx_ring->buffer_info[i].dma && +                   time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) +                   && !(E1000_READ_REG(&adapter->hw, STATUS) & +                       E1000_STATUS_TXOFF)) { + +                       /* detected Tx unit hang */ +                       i = tx_ring->next_to_clean; +                       eop = tx_ring->buffer_info[i].next_to_watch; +                       eop_desc = E1000_TX_DESC(*tx_ring, eop); +                       DPRINTK(TX_ERR, ERR, "Detected Tx Unit Hang\n" +                                       "  TDH                  <%x>\n" +                                       "  TDT                  <%x>\n" +                                       "  next_to_use          <%x>\n" +                                       "  next_to_clean        <%x>\n" +                                       "buffer_info[next_to_clean]\n" +                                       "  dma                  <%llx>\n" +                                       "  time_stamp           <%lx>\n" +                                       "  next_to_watch        <%x>\n" +                                       "  jiffies              <%lx>\n" +                                       "  next_to_watch.status <%x>\n", +                               E1000_READ_REG(&adapter->hw, TDH), +                               E1000_READ_REG(&adapter->hw, TDT), +                               tx_ring->next_to_use, +                               i, +                               tx_ring->buffer_info[i].dma, +                               tx_ring->buffer_info[i].time_stamp, +                               eop, +                               jiffies, +                               eop_desc->upper.fields.status);                         netif_stop_queue(netdev); +               }         }  #ifdef NETIF_F_TSO   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:06:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:06:15 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI611O010553 for ; Wed, 27 Apr 2005 11:06:01 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI5qMb009642; Wed, 27 Apr 2005 18:05:52 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI45gR002156; Wed, 27 Apr 2005 18:05:48 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711013212903 ; Wed, 27 Apr 2005 11:01:35 -0700 Date: Wed, 27 Apr 2005 11:01:31 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 1/16] e1000: made loopback diags robust (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI611O010553 X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 5354 Lines: 127 Added enhanced functionality to the loopback diags to wrap the descriptor rings. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c   2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c       2005-04-12 23:00:55.000000000 -0700 @@ -919,7 +919,8 @@ e1000_setup_desc_rings(struct e1000_adap           /* Setup Tx descriptor ring and Tx buffers */   -       txdr->count = 80; +       if(!txdr->count) +               txdr->count = E1000_DEFAULT_TXD;             size = txdr->count * sizeof(struct e1000_buffer);         if(!(txdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -974,7 +975,8 @@ e1000_setup_desc_rings(struct e1000_adap           /* Setup Rx descriptor ring and Rx buffers */   -       rxdr->count = 80; +       if(!rxdr->count) +               rxdr->count = E1000_DEFAULT_RXD;             size = rxdr->count * sizeof(struct e1000_buffer);         if(!(rxdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -1309,31 +1311,62 @@ e1000_run_loopback_test(struct e1000_ada         struct e1000_desc_ring *txdr = &adapter->test_tx_ring;         struct e1000_desc_ring *rxdr = &adapter->test_rx_ring;         struct pci_dev *pdev = adapter->pdev; -       int i, ret_val; +       int i, j, k, l, lc, good_cnt, ret_val=0; +       unsigned long time;           E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1);   -       for(i = 0; i < 64; i++) { -               e1000_create_lbtest_frame(txdr->buffer_info[i].skb, 1024); -               pci_dma_sync_single(pdev, txdr->buffer_info[i].dma, -                                   txdr->buffer_info[i].length, -                                   PCI_DMA_TODEVICE); -       } -       E1000_WRITE_REG(&adapter->hw, TDT, i); - -       msec_delay(200); - -       i = 0; -       do { -               pci_dma_sync_single(pdev, rxdr->buffer_info[i].dma, -                                           rxdr->buffer_info[i].length, -                                           PCI_DMA_FROMDEVICE); - -               ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, -                                                  1024); -               i++; -       } while (ret_val != 0 && i < 64); +       /* Calculate the loop count based on the largest descriptor ring +        * The idea is to wrap the largest ring a number of times using 64 +        * send/receive pairs during each loop +        */ + +       if(rxdr->count <= txdr->count) +               lc = ((txdr->count / 64) * 2) + 1; +       else +               lc = ((rxdr->count / 64) * 2) + 1;   +       k = l = 0; +       for(j = 0; j <= lc; j++) { /* loop count loop */ +               for(i = 0; i < 64; i++) { /* send the packets */ +                       e1000_create_lbtest_frame(txdr->buffer_info[i].skb, +                                       1024); +                       pci_dma_sync_single(pdev, +                                       txdr->buffer_info[k].dma, +                                       txdr->buffer_info[k].length, +                                       PCI_DMA_TODEVICE); +                       if(unlikely(++k == txdr->count)) k = 0; +               } +               E1000_WRITE_REG(&adapter->hw, TDT, k); +               msec_delay(200); +               time = jiffies; /* set the start time for the receive */ +               good_cnt = 0; +               do { /* receive the sent packets */ +                       pci_dma_sync_single(pdev, +                                       rxdr->buffer_info[l].dma, +                                       rxdr->buffer_info[l].length, +                                       PCI_DMA_FROMDEVICE); +       +                       ret_val = e1000_check_lbtest_frame( +                                       rxdr->buffer_info[l].skb, +                                       1024); +                       if(!ret_val) +                               good_cnt++; +                       if(unlikely(++l == rxdr->count)) l = 0; +                       /* time + 20 msecs (200 msecs on 2.4) is more than +                        * enough time to complete the receives, if it's +                        * exceeded, break and error off +                        */ +               } while (good_cnt < 64 && jiffies < (time + 20)); +               if(good_cnt != 64) { +                       ret_val = 13; /* ret_val is the same as mis-compare */ +                       break; +               } +               if(jiffies >= (time + 2)) { +                       ret_val = 14; /* error code for time out error */ +                       break; +               } +       } /* end loop count loop */         return ret_val;  }   @@ -1370,6 +1404,8 @@ e1000_link_test(struct e1000_adapter *ad                 *data = 1;         } else {                 e1000_check_for_link(&adapter->hw); +               if(adapter->hw.autoneg)  /* if auto_neg is set wait for it */ +                       msec_delay(4000);                   if(!(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU)) {                         *data = 1; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:07:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:07:41 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI7T1O012128 for ; Wed, 27 Apr 2005 11:07:29 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI7Q15014810; Wed, 27 Apr 2005 18:07:26 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI4Ygc002606; Wed, 27 Apr 2005 18:07:22 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711032413544 ; Wed, 27 Apr 2005 11:03:27 -0700 Date: Wed, 27 Apr 2005 11:03:24 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: {RESEND][PATCH net-drivers-2.4 3/16] e1000:MSI support for PCI-e adapters (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI7T1O012128 X-archive-position: 247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2161 Lines: 55 MSI support for PCI-e adapters Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h   2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h       2005-04-12 23:00:55.000000000 -0700 @@ -259,5 +259,8 @@ struct e1000_adapter {           uint32_t pci_state[16];         int msg_enable; +#ifdef CONFIG_PCI_MSI +       boolean_t have_msi; +#endif  };  #endif /* _E1000_H_ */ diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -309,6 +309,16 @@ e1000_up(struct e1000_adapter *adapter)         e1000_configure_rx(adapter);         e1000_alloc_rx_buffers(adapter);   +#ifdef CONFIG_PCI_MSI +       if(adapter->hw.mac_type > e1000_82547_rev_2) { +               adapter->have_msi = TRUE; +               if((err = pci_enable_msi(adapter->pdev))) { +                       DPRINTK(PROBE, ERR, +                        "Unable to allocate MSI interrupt Error: %d\n", err); +                       adapter->have_msi = FALSE; +               } +       } +#endif         if((err = request_irq(adapter->pdev->irq, &e1000_intr,                               SA_SHIRQ | SA_SAMPLE_RANDOM,                               netdev->name, netdev))) @@ -330,6 +330,11 @@ e1000_down(struct e1000_adapter *adapter           e1000_irq_disable(adapter);         free_irq(adapter->pdev->irq, netdev); +#ifdef CONFIG_PCI_MSI +       if(adapter->hw.mac_type > e1000_82547_rev_2 && +          adapter->have_msi == TRUE) +               pci_disable_msi(adapter->pdev); +#endif         del_timer_sync(&adapter->tx_fifo_stall_timer);         del_timer_sync(&adapter->watchdog_timer);         del_timer_sync(&adapter->phy_info_timer); From mallikarjuna.chilakala@intel.com Wed Apr 27 11:07:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:07:50 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RI7a1O012202 for ; Wed, 27 Apr 2005 11:07:37 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RI7XjI020283; Wed, 27 Apr 2005 18:07:33 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI7DkN032374; Wed, 27 Apr 2005 18:07:33 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711073312243 ; Wed, 27 Apr 2005 11:07:33 -0700 Date: Wed, 27 Apr 2005 11:07:33 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 9/16] e1000: stops working after resume (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RI7a1O012202 X-archive-position: 248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 26 e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -3128,9 +3128,10 @@ e1000_resume(struct pci_dev *pdev)         struct e1000_adapter *adapter = netdev->priv;         uint32_t manc, ret;   -       ret = pci_enable_device(pdev);         pci_set_power_state(pdev, 0);         pci_restore_state(pdev, adapter->pci_state); +       ret = pci_enable_device(pdev); +       pci_set_master(pdev);           pci_enable_wake(pdev, 3, 0);         pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */ From mallikarjuna.chilakala@intel.com Wed Apr 27 11:10:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:10:18 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIAF1O014515 for ; Wed, 27 Apr 2005 11:10:15 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIA9Mb012011; Wed, 27 Apr 2005 18:10:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RI9Ifv006553; Wed, 27 Apr 2005 18:10:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711065014813 ; Wed, 27 Apr 2005 11:06:52 -0700 Date: Wed, 27 Apr 2005 11:06:49 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 8/16] e1000: Fix computation of netdev stats from controller stats counters (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1314 Lines: 31 Fix computation of netdev stats from controller stats counters - from sfeldma@pobox.com Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2187,9 +2187,9 @@ e1000_update_stats(struct e1000_adapter adapter->net_stats.rx_errors = adapter->stats.rxerrc + adapter->stats.crcerrs + adapter->stats.algnerrc + - adapter->stats.rlec + adapter->stats.rnbc + - adapter->stats.mpc + adapter->stats.cexterr; - adapter->net_stats.rx_dropped = adapter->stats.rnbc; + adapter->stats.rlec + adapter->stats.mpc + + adapter->stats.cexterr; + adapter->net_stats.rx_dropped = adapter->stats.mpc; adapter->net_stats.rx_length_errors = adapter->stats.rlec; adapter->net_stats.rx_crc_errors = adapter->stats.crcerrs; adapter->net_stats.rx_frame_errors = adapter->stats.algnerrc; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:14:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:14:27 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIEO1O016973 for ; Wed, 27 Apr 2005 11:14:24 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIEHCQ010396; Wed, 27 Apr 2005 18:14:18 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIE4kO005912; Wed, 27 Apr 2005 18:14:17 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711141709322 ; Wed, 27 Apr 2005 11:14:17 -0700 Date: Wed, 27 Apr 2005 11:14:17 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 15/16] e1000: Adjust flow control watermarks for JumboFrames (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIEO1O016973 X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2141 Lines: 54 Adjust flow control watermarks for Jumbo Frames Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -406,7 +406,10 @@ e1000_down(struct e1000_adapter *adapter  void  e1000_reset(struct e1000_adapter *adapter)  { +       struct net_device *netdev = adapter->netdev;         uint32_t pba, manc; +       uint16_t fc_high_water_mark = E1000_FC_HIGH_DIFF; +       uint16_t fc_low_water_mark = E1000_FC_LOW_DIFF;           /* Repartition Pba for greater than 9k mtu          * To take effect CTRL.RST is required. @@ -425,6 +425,16 @@                 break;         }   +       if((adapter->hw.mac_type != e1000_82573) && +          (adapter->rx_buffer_len > E1000_RXBUFFER_8192)) { +               pba -= 8; /* allocate more FIFO for Tx */ +               /* send an XOFF when there is enough space in the +                * Rx FIFO to hold one extra full size Rx packet +               */ +               fc_high_water_mark = netdev->mtu + ENET_HEADER_SIZE + +                                       ETHERNET_FCS_SIZE + 1; +               fc_low_water_mark = fc_high_water_mark + 8; +       }             if(adapter->hw.mac_type == e1000_82547) { @@ -439,9 +439,9 @@           /* flow control settings */         adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - -                                   E1000_FC_HIGH_DIFF; +                                   fc_high_water_mark;         adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - -                                  E1000_FC_LOW_DIFF; +                                  fc_low_water_mark;         adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME;         adapter->hw.fc_send_xon = 1;         adapter->hw.fc = adapter->hw.original_fc; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:12:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:12:48 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RICV1O015727 for ; Wed, 27 Apr 2005 11:12:35 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RICRCQ009122; Wed, 27 Apr 2005 18:12:27 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RICRkC004468; Wed, 27 Apr 2005 18:12:27 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711122730203 ; Wed, 27 Apr 2005 11:12:27 -0700 Date: Wed, 27 Apr 2005 11:12:27 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 12/16] e1000: Modified e1000_clean:: exit poll (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RICV1O015727 X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1127 Lines: 25 Modified e1000_clean:: exit poll if no Tx and work_done == 0 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -2325,9 +2325,8 @@ e1000_clean(struct net_device *netdev, i         *budget -= work_done;         netdev->quota -= work_done;         -       /* if no Tx and not enough Rx work done, exit the polling mode */ -       if((!tx_cleaned && (work_done < work_to_do)) || -                               !netif_running(netdev)) { +       /* If no Tx and no Rx work done, exit the polling mode */ +       if ((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) {                 netif_rx_complete(netdev);                 e1000_irq_enable(adapter);                 return 0; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:11:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:11:32 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIBI1O014947 for ; Wed, 27 Apr 2005 11:11:19 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIBFLd011720; Wed, 27 Apr 2005 18:11:15 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIBAkE003245; Wed, 27 Apr 2005 18:11:15 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711111512673 ; Wed, 27 Apr 2005 11:11:15 -0700 Date: Wed, 27 Apr 2005 11:11:15 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 10/16] e1000:Implement a workaround for 82546 errata 10 (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2030 Lines: 49 Implement a workaround for 82546 errata 10 -- first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -1750,6 +1750,15 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif + /* work-around for errata 10 and it applies + * to all controllers in PCI-X mode + * The fix is to make sure that the first descriptor of a + * packet is smaller than 2048 - 16 - 16 (or 2016) bytes + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (size > 2015) && count == 0)) + size = 2015; + /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ if(unlikely(adapter->pcix_82544 && @@ -1951,6 +1960,13 @@ e1000_xmit_frame(struct sk_buff *skb, st if(adapter->pcix_82544) count++; + /* work-around for errata 10 and it applies to all controllers + * in PCI-X mode, so add one more descriptor to the count + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (len > 2015))) + count++; + nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, From mallikarjuna.chilakala@intel.com Wed Apr 27 11:11:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:12:02 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIBn1O015252 for ; Wed, 27 Apr 2005 11:11:49 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIBigx026572; Wed, 27 Apr 2005 18:11:44 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIBikC003789; Wed, 27 Apr 2005 18:11:44 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711114412720 ; Wed, 27 Apr 2005 11:11:44 -0700 Date: Wed, 27 Apr 2005 11:11:44 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 11/16] e1000:Removed redundant statement in e1000_clean_tx_irq (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIBn1O015252 X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 848 Lines: 22 Removed redundant statement in e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -2393,7 +2393,6 @@ e1000_clean_tx_irq(struct e1000_adapter                         tx_desc->lower.data = 0;                         tx_desc->upper.data = 0;   -                       cleaned = (i == eop);                         if(unlikely(++i == tx_ring->count)) i = 0;                 }                 From mallikarjuna.chilakala@intel.com Wed Apr 27 11:15:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:15:39 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIFZ1O017728 for ; Wed, 27 Apr 2005 11:15:35 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIFU4C024641; Wed, 27 Apr 2005 18:15:30 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIFFfS011416; Wed, 27 Apr 2005 18:15:26 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711132417133 ; Wed, 27 Apr 2005 11:13:27 -0700 Date: Wed, 27 Apr 2005 11:13:24 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 14/16] e1000: Fix Packet Buffer logic for 82547_rev_2 (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIFZ1O017728 X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 798 Lines: 22 Fix Packet Buffer Allocation logic for 82547_rev_2 controller Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -414,6 +414,7 @@ e1000_down(struct e1000_adapter *adapter           switch (adapter->hw.mac_type) {         case e1000_82547: +       case e1000_82547_rev_2:                 pba = E1000_PBA_30K;                 break;         case e1000_82573: From mallikarjuna.chilakala@intel.com Wed Apr 27 11:16:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:16:45 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIGV1O018493 for ; Wed, 27 Apr 2005 11:16:31 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIGP15017173; Wed, 27 Apr 2005 18:16:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIDThE010170; Wed, 27 Apr 2005 18:16:21 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711144817608 ; Wed, 27 Apr 2005 11:14:51 -0700 Date: Wed, 27 Apr 2005 11:14:48 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.4 16/16] e1000: Driver version, white space, comments, deviceid (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIGV1O018493 X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 30119 Lines: 667 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c   2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c       2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -69,6 +69,7 @@ static const struct e1000_stats e1000_gs         { "rx_crc_errors", E1000_STAT(net_stats.rx_crc_errors) },         { "rx_frame_errors", E1000_STAT(net_stats.rx_frame_errors) },         { "rx_fifo_errors", E1000_STAT(net_stats.rx_fifo_errors) }, +       { "rx_no_buffer_count", E1000_STAT(stats.rnbc) },         { "rx_missed_errors", E1000_STAT(net_stats.rx_missed_errors) },         { "tx_aborted_errors", E1000_STAT(net_stats.tx_aborted_errors) },         { "tx_carrier_errors", E1000_STAT(net_stats.tx_carrier_errors) }, @@ -593,7 +594,7 @@ e1000_set_ringparam(struct net_device *n         tx_old = adapter->tx_ring;         rx_old = adapter->rx_ring;   -       if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) +       if((ring->rx_mini_pending) || (ring->rx_jumbo_pending))                 return -EINVAL;           if(netif_running(adapter->netdev)) @@ -784,8 +785,8 @@ e1000_intr_test(struct e1000_adapter *ad         /* Hook up test interrupt handler just for this test */         if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {                 shared_int = FALSE; -       } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, -                       netdev->name, netdev)){ +       } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, +                             netdev->name, netdev)){                 *data = 1;                 return -1;         } @@ -842,10 +843,8 @@ e1000_intr_test(struct e1000_adapter *ad                          * test failed.                          */                         adapter->test_icr = 0; -                       E1000_WRITE_REG(&adapter->hw, IMC, -                                       (~mask & 0x00007FFF)); -                       E1000_WRITE_REG(&adapter->hw, ICS, -                                       (~mask & 0x00007FFF)); +                       E1000_WRITE_REG(&adapter->hw, IMC, ~mask & 0x00007FFF); +                       E1000_WRITE_REG(&adapter->hw, ICS, ~mask & 0x00007FFF);                         msec_delay(10);                           if(adapter->test_icr) { @@ -1386,13 +1385,12 @@ static int  e1000_link_test(struct e1000_adapter *adapter, uint64_t *data)  {         *data = 0; -         if (adapter->hw.media_type == e1000_media_type_internal_serdes) {                 int i = 0;                 adapter->hw.serdes_link_down = TRUE;   -               /* on some blade server designs link establishment */ -               /* could take as long as 2-3 minutes.              */ +               /* On some blade server designs, link establishment +                * could take as long as 2-3 minutes */                 do {                         e1000_check_for_link(&adapter->hw);                         if (adapter->hw.serdes_link_down == FALSE) @@ -1400,7 +1373,7 @@ e1000_link_test(struct e1000_adapter *ad                         msec_delay(20);                 } while (i++ < 3750);   -               *data = 1; +               *data = 1;         } else {                 e1000_check_for_link(&adapter->hw);                 if(adapter->hw.autoneg)  /* if auto_neg is set wait for it */ diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h   2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h       2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -141,9 +138,9 @@ struct e1000_adapter;  /* How many Rx Buffers do we bundle into one write to the hardware ? */  #define E1000_RX_BUFFER_WRITE  16      /* Must be power of 2 */   -#define AUTO_ALL_MODES       0 -#define E1000_EEPROM_82544_APM 0x0004 -#define E1000_EEPROM_APME    0x0400 +#define AUTO_ALL_MODES            0 +#define E1000_EEPROM_82544_APM    0x0400 +#define E1000_EEPROM_APME         0x0400    #ifndef E1000_MASTER_SLAVE  /* Switch to override PHY master/slave setting */ diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.c net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.4/drivers/net/e1000/e1000_hw.c        2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c    2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -144,7 +144,6 @@ e1000_phy_init_script(struct e1000_hw *h        DEBUGFUNC("e1000_phy_init_script");   -      if(hw->phy_init_script) {          msec_delay(20);   diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.h net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.4/drivers/net/e1000/e1000_hw.h        2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h    2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c      2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c  2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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,33 +29,9 @@  #include "e1000.h"    /* Change Log - * 5.3.12      6/7/04 - * - kcompat NETIF_MSG for older kernels (2.4.9) - * - if_mii support and associated kcompat for older kernels - * - More errlogging support from Jon Mason - * - Fix TSO issues on PPC64 machines -- Jon Mason - * 5.7.1       12/16/04 - * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This - *   fix was removed as it caused system instability. The suspected cause of - *   this is the called to e1000_irq_disable in e1000_intr. Inlined the - *   required piece of e1000_irq_disable into e1000_intr. - * 5.7.0       12/10/04 - * - include fix to the condition that determines when to quit NAPI - Robert Olsson - * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down - * 5.6.5       11/01/04 - * - Enabling NETIF_F_SG without checksum offload is illegal - -     John Mason - * 5.6.3        10/26/04 - * - Remove redundant initialization - Jamal Hadi - * - Reset buffer_info->dma in tx resource cleanup logic - * 5.6.2       10/12/04 - * - Avoid filling tx_ring completely - shemminger@osdl.org - * - Replace schedule_timeout() with msleep()/msleep_interruptible() - - *   nacc@us.ibm.com - * - Sparse cleanup - shemminger@osdl.org - * - Fix tx resource cleanup logic - * - LLTX support - ak@suse.de and hadi@cyberus.ca - * - {set, get}_wol is now symmetric for 82545EM adapters + * 6.0.44+     2/15/05 + *   o applied Anton's patch to resolve tx hang in hardware + *   o Applied Andrew Mortons patch - e1000 stops working after resume   */    char e1000_driver_name[] = "e1000"; @@ -65,8 +110,8 @@ char e1000_driver_string[] = "Intel(R) P  #else  #define DRIVERNAPI "-NAPI"  #endif -char e1000_driver_version[] = "5.7.6-k1"DRIVERNAPI; -char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +char e1000_driver_version[] = "6.0.54-k1"DRIVERNAPI; +char e1000_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";    /* e1000_pci_tbl - PCI Device ID Table   * @@ -95,6 +71,7 @@ static struct pci_device_id e1000_pci_tb         INTEL_E1000_ETHERNET_DEVICE(0x1017),         INTEL_E1000_ETHERNET_DEVICE(0x1018),         INTEL_E1000_ETHERNET_DEVICE(0x1019), +       INTEL_E1000_ETHERNET_DEVICE(0x101A),         INTEL_E1000_ETHERNET_DEVICE(0x101D),         INTEL_E1000_ETHERNET_DEVICE(0x101E),         INTEL_E1000_ETHERNET_DEVICE(0x1026), @@ -109,6 +86,9 @@ static struct pci_device_id e1000_pci_tb         INTEL_E1000_ETHERNET_DEVICE(0x107B),         INTEL_E1000_ETHERNET_DEVICE(0x107C),         INTEL_E1000_ETHERNET_DEVICE(0x108A), +       INTEL_E1000_ETHERNET_DEVICE(0x108B), +       INTEL_E1000_ETHERNET_DEVICE(0x108C), +       INTEL_E1000_ETHERNET_DEVICE(0x1099),         /* required last entry */         {0,}  }; @@ -347,8 +351,11 @@ e1000_up(struct e1000_adapter *adapter)  #endif         if((err = request_irq(adapter->pdev->irq, &e1000_intr,                               SA_SHIRQ | SA_SAMPLE_RANDOM, -                             netdev->name, netdev))) +                             netdev->name, netdev))) { +               DPRINTK(PROBE, ERR, +                   "Unable to allocate interrupt Error: %d\n", err);                 return err; +       }           mod_timer(&adapter->watchdog_timer, jiffies);   @@ -630,7 +613,7 @@ e1000_probe(struct pci_dev *pdev,           /* copy the MAC address out of the EEPROM */   -       if (e1000_read_mac_addr(&adapter->hw)) +       if(e1000_read_mac_addr(&adapter->hw))                 DPRINTK(PROBE, ERR, "EEPROM Read Error\n");         memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len);   @@ -950,12 +933,10 @@ e1000_check_64k_bound(struct e1000_adapt         unsigned long begin = (unsigned long) start;         unsigned long end = begin + len;   -       /* first rev 82545 and 82546 need to not allow any memory -        * write location to cross a 64k boundary due to errata 23 */ +       /* First rev 82545 and 82546 need to not allow any memory +        * write location to cross 64k boundary due to errata 23 */         if (adapter->hw.mac_type == e1000_82545 || -           adapter->hw.mac_type == e1000_82546 ) { - -               /* check buffer doesn't cross 64kB */ +           adapter->hw.mac_type == e1000_82546) {                 return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE;         }   @@ -979,8 +960,8 @@ e1000_setup_tx_resources(struct e1000_ad         size = sizeof(struct e1000_buffer) * txdr->count;         txdr->buffer_info = vmalloc(size);         if(!txdr->buffer_info) { -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Transmit descriptor ring\n"); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the transmit descriptor ring\n");                 return -ENOMEM;         }         memset(txdr->buffer_info, 0, size); @@ -993,22 +925,22 @@ e1000_setup_tx_resources(struct e1000_ad         txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma);         if(!txdr->desc) {  setup_tx_desc_die: -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Transmit descriptor ring\n");                 vfree(txdr->buffer_info); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the transmit descriptor ring\n");                 return -ENOMEM;         }   -       /* fix for errata 23, cant cross 64kB boundary */ +       /* Fix for errata 23, can't cross 64kB boundary */         if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) {                 void *olddesc = txdr->desc;                 dma_addr_t olddma = txdr->dma; -               DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", -                       txdr->size, txdr->desc); -               /* try again, without freeing the previous */ +               DPRINTK(TX_ERR, ERR, "txdr align check failed: %u bytes " +                                    "at %p\n", txdr->size, txdr->desc); +               /* Try again, without freeing the previous */                 txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); -               /* failed allocation, critial failure */                 if(!txdr->desc) { +               /* Failed allocation, critical failure */                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                         goto setup_tx_desc_die;                 } @@ -1015,16 +925,16 @@                   if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) {                         /* give up */ -                       pci_free_consistent(pdev, txdr->size, -                            txdr->desc, txdr->dma); +                       pci_free_consistent(pdev, txdr->size, txdr->desc, +                                           txdr->dma);                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                         DPRINTK(PROBE, ERR, -                        "Unable to Allocate aligned Memory for the Transmit" -                        " descriptor ring\n"); +                               "Unable to allocate aligned memory " +                               "for the transmit descriptor ring\n");                         vfree(txdr->buffer_info);                         return -ENOMEM;                 } else { -                       /* free old, move on with the new one since its okay */ +                       /* Free old allocation, new allocation was successful */                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                 }         } @@ -1131,8 +1058,8 @@ e1000_setup_rx_resources(struct e1000_ad         size = sizeof(struct e1000_buffer) * rxdr->count;         rxdr->buffer_info = vmalloc(size);         if(!rxdr->buffer_info) { -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Recieve descriptor ring\n"); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the receive descriptor ring\n");                 return -ENOMEM;         }         memset(rxdr->buffer_info, 0, size); @@ -1172,25 +1058,24 @@           if(!rxdr->desc) {  setup_rx_desc_die: -               DPRINTK(PROBE, ERR, -               "Unble to Allocate Memory for the Recieve descriptor ring\n");                 vfree(rxdr->buffer_info);                 kfree(rxdr->ps_page);                 kfree(rxdr->ps_page_dma); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the receive descriptor ring\n");                 return -ENOMEM;         }   -       /* fix for errata 23, cant cross 64kB boundary */ +       /* Fix for errata 23, can't cross 64kB boundary */         if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) {                 void *olddesc = rxdr->desc;                 dma_addr_t olddma = rxdr->dma; -               DPRINTK(RX_ERR,ERR, -                       "rxdr align check failed: %u bytes at %p\n", -                       rxdr->size, rxdr->desc); -               /* try again, without freeing the previous */ +               DPRINTK(RX_ERR, ERR, "rxdr align check failed: %u bytes " +                                    "at %p\n", rxdr->size, rxdr->desc); +               /* Try again, without freeing the previous */                 rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); -               /* failed allocation, critial failure */                 if(!rxdr->desc) { +               /* Failed allocation, critical failure */                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma);                         goto setup_rx_desc_die;                 } @@ -1197,18 +1058,18 @@                   if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) {                         /* give up */ -                       pci_free_consistent(pdev, rxdr->size, -                            rxdr->desc, rxdr->dma); +                       pci_free_consistent(pdev, rxdr->size, rxdr->desc, +                                           rxdr->dma);                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma); -                       DPRINTK(PROBE, ERR, -                               "Unable to Allocate aligned Memory for the" -                               " Receive descriptor ring\n"); +                       DPRINTK(PROBE, ERR, +                               "Unable to allocate aligned memory " +                               "for the receive descriptor ring\n");                         vfree(rxdr->buffer_info);                         kfree(rxdr->ps_page);                         kfree(rxdr->ps_page_dma);                         return -ENOMEM;                 } else { -                       /* free old, move on with the new one since its okay */ +                       /* Free old allocation, new allocation was successful */                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma);                 }         } @@ -1221,7 +1123,7 @@ setup_rx_desc_die:  }    /** - * e1000_setup_rctl - configure the receive control register + * e1000_setup_rctl - configure the receive control registers   * @adapter: Board private structure   **/   @@ -1413,13 +1393,11 @@ static inline void  e1000_unmap_and_free_tx_resource(struct e1000_adapter *adapter,                         struct e1000_buffer *buffer_info)  { -       struct pci_dev *pdev = adapter->pdev; -         if(buffer_info->dma) { -               pci_unmap_page(pdev, -                              buffer_info->dma, -                              buffer_info->length, -                              PCI_DMA_TODEVICE); +               pci_unmap_page(adapter->pdev, +                               buffer_info->dma, +                               buffer_info->length, +                               PCI_DMA_TODEVICE);                 buffer_info->dma = 0;         }         if(buffer_info->skb) { @@ -1444,7 +1422,7 @@ e1000_clean_tx_ring(struct e1000_adapter         /* Free all the Tx ring sk_buffs */           if (likely(adapter->previous_buffer_info.skb != NULL)) { -               e1000_unmap_and_free_tx_resource(adapter, +               e1000_unmap_and_free_tx_resource(adapter,                                 &adapter->previous_buffer_info);         }   @@ -1646,15 +1624,15 @@ e1000_set_multi(struct net_device *netde         struct e1000_adapter *adapter = netdev->priv;         struct e1000_hw *hw = &adapter->hw;         struct dev_mc_list *mc_ptr; +       unsigned long flags;         uint32_t rctl;         uint32_t hash_value;         int i; -       unsigned long flags; - -       /* Check for Promiscuous and All Multicast modes */           spin_lock_irqsave(&adapter->tx_lock, flags);   +       /* Check for Promiscuous and All Multicast modes */ +         rctl = E1000_READ_REG(hw, RCTL);           if(netdev->flags & IFF_PROMISC) { @@ -1854,7 +1832,7 @@ e1000_watchdog(unsigned long data)         /* Cause software interrupt to ensure rx ring is cleaned */         E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0);   -       /* Force detection of hung controller every watchdog period*/ +       /* Force detection of hung controller every watchdog period */         adapter->detect_tx_hung = TRUE;           /* Reset the timer */ @@ -2240,7 +2218,7 @@ e1000_xmit_frame(struct sk_buff *skb, st           if((mss) || (skb->ip_summed == CHECKSUM_HW))                 count++; -       count++;        /* for sentinel desc */ +       count++;  #else         if(skb->ip_summed == CHECKSUM_HW)                 count++; @@ -2615,7 +2315,7 @@ e1000_intr(int irq, void *data, struct p         */         if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){                 atomic_inc(&adapter->irq_sem); -               E1000_WRITE_REG(&adapter->hw, IMC, ~0); +               E1000_WRITE_REG(hw, IMC, ~0);         }           for(i = 0; i < E1000_MAX_INTR; i++) @@ -2643,7 +2355,7 @@ e1000_clean(struct net_device *netdev, i         int work_to_do = min(*budget, netdev->quota);         int tx_cleaned;         int work_done = 0; -       +         tx_cleaned = e1000_clean_tx_irq(adapter);         adapter->clean_rx(adapter, &work_done, work_to_do);   @@ -2733,9 +2443,9 @@ e1000_clean_tx_irq(struct e1000_adapter                 netif_wake_queue(netdev);           spin_unlock(&adapter->tx_lock); -         if(adapter->detect_tx_hung) { -               /* detect a transmit hang in hardware, this serializes the + +               /* Detect a transmit hang in hardware, this serializes the                  * check with the clearing of time_stamp and movement of i */                 adapter->detect_tx_hung = FALSE;                 if (tx_ring->buffer_info[i].dma && @@ -2880,7 +2858,7 @@ e1000_clean_rx_irq(struct e1000_adapter                 if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) {                         /* All receives must fit into a single buffer */                         E1000_DBG("%s: Receive packet consumed multiple" -                                       " buffers\n", netdev->name); +                                 " buffers\n", netdev->name);                         dev_kfree_skb_irq(skb);                         goto next_desc;                 } @@ -3088,32 +2619,33 @@ e1000_alloc_rx_buffers(struct e1000_adap         struct e1000_buffer *buffer_info;         struct sk_buff *skb;         int reserve_len = 2; -       unsigned int i, bufsz; +       unsigned int i; +       unsigned int bufsz = adapter->rx_buffer_len + 2;           i = rx_ring->next_to_use;         buffer_info = &rx_ring->buffer_info[i];           while(!buffer_info->skb) { -               bufsz = adapter->rx_buffer_len + reserve_len; -                 skb = dev_alloc_skb(bufsz); +                 if(unlikely(!skb)) {                         /* Better luck next round */                         break;                 }   -               /* fix for errata 23, cant cross 64kB boundary */ +               /* Fix for errata 23, can't cross 64kB boundary */                 if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {                         struct sk_buff *oldskb = skb; -                       DPRINTK(RX_ERR,ERR, -                               "skb align check failed: %u bytes at %p\n", -                               bufsz, skb->data); -                       /* try again, without freeing the previous */ +                       DPRINTK(RX_ERR, ERR, "skb align check failed: %u bytes " +                                            "at %p\n", bufsz, skb->data); +                       /* Try again, without freeing the previous */                         skb = dev_alloc_skb(bufsz); +                       /* Failed allocation, critical failure */                         if (!skb) {                                 dev_kfree_skb(oldskb);                                 break;                         } +                         if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {                                 /* give up */                                 dev_kfree_skb(skb); @@ -3120,11 +2619,10 @@                                 dev_kfree_skb(oldskb);                                 break; /* while !buffer_info->skb */                         } else { -                               /* move on with the new one */ +                               /* Use new allocation */                                 dev_kfree_skb(oldskb);                         }                 } -                 /* Make buffer alignment 2 beyond a 16 byte boundary                  * this will result in a 16 byte aligned IP header after                  * the 14 byte MAC header is removed @@ -3140,25 +3118,23 @@ e1000_alloc_rx_buffers(struct e1000_adap                                                   adapter->rx_buffer_len,                                                   PCI_DMA_FROMDEVICE);   -               /* fix for errata 23, cant cross 64kB boundary */ -               if(!e1000_check_64k_bound(adapter, -                                              (void *)(unsigned long)buffer_info->dma, -                                              adapter->rx_buffer_len)) { -                       DPRINTK(RX_ERR,ERR, -                               "dma align check failed: %u bytes at %ld\n", -                               adapter->rx_buffer_len, (unsigned long)buffer_info->dma); - +               /* Fix for errata 23, can't cross 64kB boundary */ +               if (!e1000_check_64k_bound(adapter, +                                       (void *)(unsigned long)buffer_info->dma, +                                       adapter->rx_buffer_len)) { +                       DPRINTK(RX_ERR, ERR, +                               "dma align check failed: %u bytes at %p\n", +                               adapter->rx_buffer_len, +                               (void *)(unsigned long)buffer_info->dma);                         dev_kfree_skb(skb);                         buffer_info->skb = NULL;   -                       pci_unmap_single(pdev, -                                        buffer_info->dma, +                       pci_unmap_single(pdev, buffer_info->dma,                                          adapter->rx_buffer_len,                                          PCI_DMA_FROMDEVICE);                           break; /* while !buffer_info->skb */                 } -                 rx_desc = E1000_RX_DESC(*rx_ring, i);                 rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);   @@ -3168,7 +3144,6 @@ e1000_alloc_rx_buffers(struct e1000_adap                          * applicable for weak-ordered memory model archs,                          * such as IA-64). */                         wmb(); -                         E1000_WRITE_REG(&adapter->hw, RDT, i);                 }   @@ -3441,9 +3416,10 @@ void  e1000_pci_set_mwi(struct e1000_hw *hw)  {         struct e1000_adapter *adapter = hw->back; +       int ret_val = pci_set_mwi(adapter->pdev);   -       int ret; -       ret = pci_set_mwi(adapter->pdev); +       if(ret_val) +               DPRINTK(PROBE, ERR, "Error in setting MWI\n");  }    void @@ -3601,8 +3577,7 @@ e1000_set_spd_dplx(struct e1000_adapter                 break;         case SPEED_1000 + DUPLEX_HALF: /* not supported */         default: -               DPRINTK(PROBE, ERR, -                       "Unsupported Speed/Duplexity configuration\n"); +               DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n");                 return -EINVAL;         }         return 0; @@ -3768,7 +3743,7 @@ e1000_resume(struct pci_dev *pdev)   * the interrupt routine is executing.   */  static void -e1000_netpoll (struct net_device *netdev) +e1000_netpoll(struct net_device *netdev)  {         struct e1000_adapter *adapter = netdev->priv;         disable_irq(adapter->pdev->irq); diff -up net-drivers-2.4/drivers/net/e1000/e1000_osdep.h net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.4/drivers/net/e1000/e1000_osdep.h     2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.4/drivers/net/e1000/e1000_param.c net-drivers-2.4/drivers/net/e1000.new/e1000_param.c --- net-drivers-2.4/drivers/net/e1000/e1000_param.c     2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_param.c 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -455,7 +532,6 @@ e1000_check_options(struct e1000_adapter                                 DPRINTK(PROBE, INFO, "%s set to dynamic mode\n",                                         opt.name);                                 break; -                       case -1:                         default:                                 e1000_validate_option(&adapter->itr, &opt,                                         adapter); From mallikarjuna.chilakala@intel.com Wed Apr 27 11:19:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:19:47 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIJW1O019560 for ; Wed, 27 Apr 2005 11:19:34 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIJSjI026543; Wed, 27 Apr 2005 18:19:28 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIJMkE009898; Wed, 27 Apr 2005 18:19:28 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711192713578 ; Wed, 27 Apr 2005 11:19:28 -0700 Date: Wed, 27 Apr 2005 11:19:28 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 0/16] e1000: driver update (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIJW1O019560 X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1461 Lines: 24 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Added enhanced functionality to the loopback diags to wrap the descriptor rings. 2. Fix msec-delay definition in e1000_osdep.h to use msleep 3. MSI support for PCI-e adapters 4. Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] 5. Fix kernel panic with 82541 LOM when using a 100M cable 6. Delay clean-up of last Tx packet to fix pre-mature writeback issue of  Tx descriptors only when TSO is enabled 7. Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached 8. Fix computation of netdev stats from controller stats counters 9. e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch 10. Implement 82546 errata 10 --  first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. 11. Removed redundant statement in e1000_clean_tx_irq 12. Modified e1000_clean:: exit poll if no Tx and work_done == 0 13. 82573 specific code & packet split code 14. Fix Packet Buffer Allocation logic for 82547_rev_2 controller 15. Adjust flow control watermarks for Jumbo Frames 16. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Wed Apr 27 11:19:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:20:01 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIJw1O019592 for ; Wed, 27 Apr 2005 11:19:58 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIJrLd016154; Wed, 27 Apr 2005 18:19:53 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIJMkY009898; Wed, 27 Apr 2005 18:19:53 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711195313619 ; Wed, 27 Apr 2005 11:19:53 -0700 Date: Wed, 27 Apr 2005 11:19:53 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 1/16] e1000: made loopback test robust (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIJw1O019592 X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 5408 Lines: 127 Added enhanced functionality to the loopback diags to wrap the descriptor rings. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c   2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c       2005-04-11 02:22:28.000000000 -0700 @@ -919,7 +919,8 @@ e1000_setup_desc_rings(struct e1000_adap           /* Setup Tx descriptor ring and Tx buffers */   -       txdr->count = 80; +       if(!txdr->count) +               txdr->count = E1000_DEFAULT_TXD;             size = txdr->count * sizeof(struct e1000_buffer);         if(!(txdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -974,7 +975,8 @@ e1000_setup_desc_rings(struct e1000_adap           /* Setup Rx descriptor ring and Rx buffers */   -       rxdr->count = 80; +       if(!rxdr->count) +               rxdr->count = E1000_DEFAULT_RXD;             size = rxdr->count * sizeof(struct e1000_buffer);         if(!(rxdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -1310,31 +1312,62 @@ e1000_run_loopback_test(struct e1000_ada         struct e1000_desc_ring *txdr = &adapter->test_tx_ring;         struct e1000_desc_ring *rxdr = &adapter->test_rx_ring;         struct pci_dev *pdev = adapter->pdev; -       int i, ret_val; +       int i, j, k, l, lc, good_cnt, ret_val=0; +       unsigned long time;           E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1);   -       for(i = 0; i < 64; i++) { -               e1000_create_lbtest_frame(txdr->buffer_info[i].skb, 1024); -               pci_dma_sync_single_for_device(pdev, txdr->buffer_info[i].dma, -                                           txdr->buffer_info[i].length, -                                           PCI_DMA_TODEVICE); -       } -       E1000_WRITE_REG(&adapter->hw, TDT, i); - -       msec_delay(200); - -       i = 0; -       do { -               pci_dma_sync_single_for_cpu(pdev, rxdr->buffer_info[i].dma, -                                           rxdr->buffer_info[i].length, -                                           PCI_DMA_FROMDEVICE); - -               ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, -                                                  1024); -               i++; -       } while (ret_val != 0 && i < 64); +       /* Calculate the loop count based on the largest descriptor ring +        * The idea is to wrap the largest ring a number of times using 64 +        * send/receive pairs during each loop +        */   +       if(rxdr->count <= txdr->count) +               lc = ((txdr->count / 64) * 2) + 1; +       else +               lc = ((rxdr->count / 64) * 2) + 1; + +       k = l = 0; +       for(j = 0; j <= lc; j++) { /* loop count loop */ +               for(i = 0; i < 64; i++) { /* send the packets */ +                       e1000_create_lbtest_frame(txdr->buffer_info[i].skb, +                                       1024); +                       pci_dma_sync_single_for_device(pdev, +                                       txdr->buffer_info[k].dma, +                                       txdr->buffer_info[k].length, +                                       PCI_DMA_TODEVICE); +                       if(unlikely(++k == txdr->count)) k = 0; +               } +               E1000_WRITE_REG(&adapter->hw, TDT, k); +               msec_delay(200); +               time = jiffies; /* set the start time for the receive */ +               good_cnt = 0; +               do { /* receive the sent packets */ +                       pci_dma_sync_single_for_cpu(pdev, +                                       rxdr->buffer_info[l].dma, +                                       rxdr->buffer_info[l].length, +                                       PCI_DMA_FROMDEVICE); +       +                       ret_val = e1000_check_lbtest_frame( +                                       rxdr->buffer_info[l].skb, +                                       1024); +                       if(!ret_val) +                               good_cnt++; +                       if(unlikely(++l == rxdr->count)) l = 0; +                       /* time + 20 msecs (200 msecs on 2.4) is more than +                        * enough time to complete the receives, if it's +                        * exceeded, break and error off +                        */ +               } while (good_cnt < 64 && jiffies < (time + 20)); +               if(good_cnt != 64) { +                       ret_val = 13; /* ret_val is the same as mis-compare */ +                       break; +               } +               if(jiffies >= (time + 2)) { +                       ret_val = 14; /* error code for time out error */ +                       break; +               } +       } /* end loop count loop */         return ret_val;  }   @@ -1371,6 +1404,8 @@ e1000_link_test(struct e1000_adapter *ad                 *data = 1;         } else {                 e1000_check_for_link(&adapter->hw); +               if(adapter->hw.autoneg)  /* if auto_neg is set wait for it */ +                       msec_delay(4000);                   if(!(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU)) {                         *data = 1; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:20:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:20:51 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIKi1O020123 for ; Wed, 27 Apr 2005 11:20:44 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIKdMb017975; Wed, 27 Apr 2005 18:20:39 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIIlgW014044; Wed, 27 Apr 2005 18:20:35 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711202119489 ; Wed, 27 Apr 2005 11:20:25 -0700 Date: Wed, 27 Apr 2005 11:20:21 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 2/16] e1000: Fix msec-delay definition to use msleep (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIKi1O020123 X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1090 Lines: 28 Fix msec-delay definition in e1000_osdep.h to use msleep Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_osdep.h net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.6/drivers/net/e1000/e1000_osdep.h     2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h 2005-04-11 02:22:29.000000000 -0700 @@ -42,7 +42,12 @@  #include    #ifndef msec_delay -#define msec_delay(x) msleep(x) +#define msec_delay(x)  do { if(in_interrupt()) { \ +                               /* Don't mdelay in interrupt context! */ \ +                               BUG(); \ +                       } else { \ +                               msleep(x); \ +                       } } while(0)    /* Some workarounds require millisecond delays and are run during interrupt   * context.  Most notably, when establishing link, the phy may need tweaking From mallikarjuna.chilakala@intel.com Wed Apr 27 11:21:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:21:18 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RILB1O020407 for ; Wed, 27 Apr 2005 11:21:11 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIL8jI027422; Wed, 27 Apr 2005 18:21:08 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIKnkM011121; Wed, 27 Apr 2005 18:21:07 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711210713766 ; Wed, 27 Apr 2005 11:21:07 -0700 Date: Wed, 27 Apr 2005 11:21:07 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 3/16] e1000: MSI support for PCI-e adapters (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RILB1O020407 X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2131 Lines: 55 MSI support for PCI-e adapters Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h   2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h       2005-04-11 02:22:29.000000000 -0700 @@ -257,5 +257,8 @@ struct e1000_adapter {             int msg_enable; +#ifdef CONFIG_PCI_MSI +       boolean_t have_msi; +#endif  };  #endif /* _E1000_H_ */ diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -312,6 +312,16 @@ e1000_up(struct e1000_adapter *adapter)         e1000_configure_rx(adapter);         e1000_alloc_rx_buffers(adapter);   +#ifdef CONFIG_PCI_MSI +       if(adapter->hw.mac_type > e1000_82547_rev_2) { +               adapter->have_msi = TRUE; +               if((err = pci_enable_msi(adapter->pdev))) { +                       DPRINTK(PROBE, ERR, +                        "Unable to allocate MSI interrupt Error: %d\n", err); +                       adapter->have_msi = FALSE; +               } +       } +#endif         if((err = request_irq(adapter->pdev->irq, &e1000_intr,                               SA_SHIRQ | SA_SAMPLE_RANDOM,                               netdev->name, netdev))) @@ -333,6 +333,11 @@ e1000_down(struct e1000_adapter *adapter           e1000_irq_disable(adapter);         free_irq(adapter->pdev->irq, netdev); +#ifdef CONFIG_PCI_MSI +       if(adapter->hw.mac_type > e1000_82547_rev_2 && +          adapter->have_msi == TRUE) +               pci_disable_msi(adapter->pdev); +#endif         del_timer_sync(&adapter->tx_fifo_stall_timer);         del_timer_sync(&adapter->watchdog_timer);         del_timer_sync(&adapter->phy_info_timer); From mallikarjuna.chilakala@intel.com Wed Apr 27 11:21:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:21:57 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RILi1O020939 for ; Wed, 27 Apr 2005 11:21:44 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RILbCQ014988; Wed, 27 Apr 2005 18:21:37 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RILR2c007141; Wed, 27 Apr 2005 18:21:36 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711213603137 ; Wed, 27 Apr 2005 11:21:36 -0700 Date: Wed, 27 Apr 2005 11:21:36 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 4/16] e1000: Enable polling before enabling interrupts (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RILi1O020939 X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 977 Lines: 29 Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -328,11 +328,12 @@ e1000_up(struct e1000_adapter *adapter)                 return err;           mod_timer(&adapter->watchdog_timer, jiffies); -       e1000_irq_enable(adapter);    #ifdef CONFIG_E1000_NAPI         netif_poll_enable(netdev);  #endif +       e1000_irq_enable(adapter); +         return 0;  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:22:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:22:13 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIM61O021288 for ; Wed, 27 Apr 2005 11:22:06 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIM3Ld017362; Wed, 27 Apr 2005 18:22:03 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIM0kG012064; Wed, 27 Apr 2005 18:22:03 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711220210150 ; Wed, 27 Apr 2005 11:22:02 -0700 Date: Wed, 27 Apr 2005 11:22:02 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 5/16] e1000: Fix kernel panic with 82541 LOM (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIM61O021288 X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 834 Lines: 22 Fix kernel panic with 82541 LOM when using a 100M cable Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -372,6 +372,7 @@ e1000_down(struct e1000_adapter *adapter                 e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg);                 mii_reg |= MII_CR_POWER_DOWN;                 e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg); +               mdelay(1);         }  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:22:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:22:54 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIMo1O021935 for ; Wed, 27 Apr 2005 11:22:50 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIMlgx032413; Wed, 27 Apr 2005 18:22:47 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RILpl4011966; Wed, 27 Apr 2005 18:22:47 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711224631353 ; Wed, 27 Apr 2005 11:22:46 -0700 Date: Wed, 27 Apr 2005 11:22:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 6/16] e1000: Delay clean-up of last Tx packet (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from BASE64 to 8bit by oss.sgi.com id j3RIMo1O021935 X-archive-position: 262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3937 Lines: 81 Delay clean-up of last Tx packet to fix pre-mature writeback issue of Tx descriptors only when TSO is enabled Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -2384,11 +2384,10 @@ e1000_clean_tx_irq(struct e1000_adapter         eop_desc = E1000_TX_DESC(*tx_ring, eop);           while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { -               /* pre-mature writeback of Tx descriptors     */ -               /* clear (free buffers and unmap pci_mapping) */ -               /* previous_buffer_info                       */ +               /* Premature writeback of Tx descriptors clear (free buffers +                * and unmap pci_mapping) previous_buffer_info */                 if (likely(adapter->previous_buffer_info.skb != NULL)) { -                       e1000_unmap_and_free_tx_resource(adapter, +                       e1000_unmap_and_free_tx_resource(adapter,                                         &adapter->previous_buffer_info);                 }   @@ -2397,20 +2725,25 @@ e1000_clean_tx_irq(struct e1000_adapter                         buffer_info = &tx_ring->buffer_info[i];                         cleaned = (i == eop);   -                       /* pre-mature writeback of Tx descriptors */ -                       /* save the cleaning of the this for the  */ -                       /* next iteration                         */ -                       if (cleaned) { -                               memcpy(&adapter->previous_buffer_info, -                                       buffer_info, -                                       sizeof(struct e1000_buffer)); -                               memset(buffer_info, -                                       0, -                                       sizeof(struct e1000_buffer)); +#ifdef NETIF_F_TSO +                       if (!(netdev->features & NETIF_F_TSO)) { +#endif +                               e1000_unmap_and_free_tx_resource(adapter, +                                                                buffer_info); +#ifdef NETIF_F_TSO                         } else { -                               e1000_unmap_and_free_tx_resource(adapter, -                                                       buffer_info); +                               if (cleaned) { +                                       memcpy(&adapter->previous_buffer_info, +                                              buffer_info, +                                              sizeof(struct e1000_buffer)); +                                       memset(buffer_info, 0, +                                              sizeof(struct e1000_buffer)); +                               } else { +                                       e1000_unmap_and_free_tx_resource( +                                           adapter, buffer_info); +                               }                         } +#endif                           tx_desc->buffer_addr = 0;                         tx_desc->lower.data = 0; @@ -2443,7 +2760,14 @@ e1000_clean_tx_irq(struct e1000_adapter                    !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF))                         netif_stop_queue(netdev);         } +#ifdef NETIF_F_TSO + +       if( unlikely(!(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) && +           time_after(jiffies, adapter->previous_buffer_info.time_stamp + HZ))) +               e1000_unmap_and_free_tx_resource( +                   adapter, &adapter->previous_buffer_info);   +#endif         return cleaned;  }   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:23:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:23:29 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RINO1O022521 for ; Wed, 27 Apr 2005 11:23:24 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RINCgx032547; Wed, 27 Apr 2005 18:23:12 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIM1l0012095; Wed, 27 Apr 2005 18:23:12 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711231231397 ; Wed, 27 Apr 2005 11:23:12 -0700 Date: Wed, 27 Apr 2005 11:23:12 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 7/16] e1000: Dump information on Tx ring (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RINO1O022521 X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2914 Lines: 55 Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -2442,10 +2442,37 @@ e1000_clean_tx_irq(struct e1000_adapter                 /* detect a transmit hang in hardware, this serializes the                  * check with the clearing of time_stamp and movement of i */                 adapter->detect_tx_hung = FALSE; -               if(tx_ring->buffer_info[i].dma && -                  time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && -                  !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) +               if (tx_ring->buffer_info[i].dma && +                   time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) +                   && !(E1000_READ_REG(&adapter->hw, STATUS) & +                       E1000_STATUS_TXOFF)) { + +                       /* detected Tx unit hang */ +                       i = tx_ring->next_to_clean; +                       eop = tx_ring->buffer_info[i].next_to_watch; +                       eop_desc = E1000_TX_DESC(*tx_ring, eop); +                       DPRINTK(TX_ERR, ERR, "Detected Tx Unit Hang\n" +                                       "  TDH                  <%x>\n" +                                       "  TDT                  <%x>\n" +                                       "  next_to_use          <%x>\n" +                                       "  next_to_clean        <%x>\n" +                                       "buffer_info[next_to_clean]\n" +                                       "  dma                  <%llx>\n" +                                       "  time_stamp           <%lx>\n" +                                       "  next_to_watch        <%x>\n" +                                       "  jiffies              <%lx>\n" +                                       "  next_to_watch.status <%x>\n", +                               E1000_READ_REG(&adapter->hw, TDH), +                               E1000_READ_REG(&adapter->hw, TDT), +                               tx_ring->next_to_use, +                               i, +                               tx_ring->buffer_info[i].dma, +                               tx_ring->buffer_info[i].time_stamp, +                               eop, +                               jiffies, +                               eop_desc->upper.fields.status);                         netif_stop_queue(netdev); +               }         }  #ifdef NETIF_F_TSO   From mallikarjuna.chilakala@intel.com Wed Apr 27 11:23:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:24:05 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RINr1O022872 for ; Wed, 27 Apr 2005 11:23:54 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RINojI028930; Wed, 27 Apr 2005 18:23:50 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RILplo011966; Wed, 27 Apr 2005 18:23:50 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711234931474 ; Wed, 27 Apr 2005 11:23:49 -0700 Date: Wed, 27 Apr 2005 11:23:49 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 8/16] e1000:Fix computation of netdev stats from controller stats counters (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1314 Lines: 30 Fix computation of netdev stats from controller stats counters - from sfeldma@pobox.com Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -2230,9 +2230,9 @@ e1000_update_stats(struct e1000_adapter adapter->net_stats.rx_errors = adapter->stats.rxerrc + adapter->stats.crcerrs + adapter->stats.algnerrc + - adapter->stats.rlec + adapter->stats.rnbc + - adapter->stats.mpc + adapter->stats.cexterr; - adapter->net_stats.rx_dropped = adapter->stats.rnbc; + adapter->stats.rlec + adapter->stats.mpc + + adapter->stats.cexterr; + adapter->net_stats.rx_dropped = adapter->stats.mpc; adapter->net_stats.rx_length_errors = adapter->stats.rlec; adapter->net_stats.rx_crc_errors = adapter->stats.crcerrs; adapter->net_stats.rx_frame_errors = adapter->stats.algnerrc; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:24:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:24:25 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIOL1O023398 for ; Wed, 27 Apr 2005 11:24:21 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIOECQ016781; Wed, 27 Apr 2005 18:24:14 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RINn2q010454; Wed, 27 Apr 2005 18:24:13 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711241303506 ; Wed, 27 Apr 2005 11:24:13 -0700 Date: Wed, 27 Apr 2005 11:24:13 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 9/16] e1000: e1000 stops working after resume (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIOL1O023398 X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1006 Lines: 26 e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -3172,9 +3172,8 @@ e1000_resume(struct pci_dev *pdev)           pci_set_power_state(pdev, 0);         pci_restore_state(pdev); -       ret = pci_enable_device(pdev); -       if (pdev->is_busmaster) -               pci_set_master(pdev); +       ret = pci_enable_device(pdev); +       pci_set_master(pdev);           pci_enable_wake(pdev, 3, 0);         pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */ From mallikarjuna.chilakala@intel.com Wed Apr 27 11:27:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:27:23 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIRH1O025003 for ; Wed, 27 Apr 2005 11:27:17 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIRCgx001707; Wed, 27 Apr 2005 18:27:12 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIQKki016169; Wed, 27 Apr 2005 18:27:10 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711270931951 ; Wed, 27 Apr 2005 11:27:09 -0700 Date: Wed, 27 Apr 2005 11:27:09 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 10/16] e1000: Implement a workaround for 82546 errata 10 (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2030 Lines: 47 Implement a workaround for 82546 errata 10 -- first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -1777,6 +1777,15 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif + /* work-around for errata 10 and it applies + * to all controllers in PCI-X mode + * The fix is to make sure that the first descriptor of a + * packet is smaller than 2048 - 16 - 16 (or 2016) bytes + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (size > 2015) && count == 0)) + size = 2015; + /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ if(unlikely(adapter->pcix_82544 && @@ -1979,6 +1988,13 @@ e1000_xmit_frame(struct sk_buff *skb, st if(adapter->pcix_82544) count++; + /* work-around for errata 10 and it applies to all controllers + * in PCI-X mode, so add one more descriptor to the count + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (len > 2015))) + count++; + nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, From mallikarjuna.chilakala@intel.com Wed Apr 27 11:27:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:27:54 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIRk1O025029 for ; Wed, 27 Apr 2005 11:27:46 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIRdgx001850; Wed, 27 Apr 2005 18:27:39 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIRd2a016337; Wed, 27 Apr 2005 18:27:39 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711273903953 ; Wed, 27 Apr 2005 11:27:39 -0700 Date: Wed, 27 Apr 2005 11:27:39 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 11/16] e1000:Removed redundant statement in e1000_clean_tx_irq (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIRk1O025029 X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 848 Lines: 22 Removed redundant statement in e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -2436,7 +2436,6 @@ e1000_clean_tx_irq(struct e1000_adapter                         tx_desc->lower.data = 0;                         tx_desc->upper.data = 0;   -                       cleaned = (i == eop);                         if(unlikely(++i == tx_ring->count)) i = 0;                 }                 From mallikarjuna.chilakala@intel.com Wed Apr 27 11:28:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:28:22 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RISA1O025240 for ; Wed, 27 Apr 2005 11:28:10 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIS57S002287; Wed, 27 Apr 2005 18:28:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIRWg0021210; Wed, 27 Apr 2005 18:28:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711280522184 ; Wed, 27 Apr 2005 11:28:05 -0700 Date: Wed, 27 Apr 2005 11:28:05 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 12/16] e1000: Modified e1000_clean:: exit poll (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RISA1O025240 X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1128 Lines: 26 Modified e1000_clean:: exit poll if no Tx and work_done == 0 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -2368,9 +2368,8 @@ e1000_clean(struct net_device *netdev, i         *budget -= work_done;         netdev->quota -= work_done;         -       /* if no Tx and not enough Rx work done, exit the polling mode */ -       if((!tx_cleaned && (work_done < work_to_do)) || -                               !netif_running(netdev)) { +       /* If no Tx and no Rx work done, exit the polling mode */ +       if ((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) {                 netif_rx_complete(netdev);                 e1000_irq_enable(adapter);                 return 0; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:29:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:29:10 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIT51O025995 for ; Wed, 27 Apr 2005 11:29:05 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIT0Ld020916; Wed, 27 Apr 2005 18:29:01 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RISRka018531; Wed, 27 Apr 2005 18:29:00 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711290032174 ; Wed, 27 Apr 2005 11:29:00 -0700 Date: Wed, 27 Apr 2005 11:29:00 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 14/16] e1000:Fix Packet Buffer Allocation logic for 82547_rev_2 (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIT51O025995 X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 798 Lines: 22 Fix Packet Buffer Allocation logic for 82547_rev_2 controller Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -417,6 +417,7 @@ e1000_down(struct e1000_adapter *adapter           switch (adapter->hw.mac_type) {         case e1000_82547: +       case e1000_82547_rev_2:                 pba = E1000_PBA_30K;                 break;         case e1000_82573: From mallikarjuna.chilakala@intel.com Wed Apr 27 11:29:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:29:44 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RITd1O026413 for ; Wed, 27 Apr 2005 11:29:39 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RITZCQ020262; Wed, 27 Apr 2005 18:29:35 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RITI2q018963; Wed, 27 Apr 2005 18:29:34 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711293404209 ; Wed, 27 Apr 2005 11:29:34 -0700 Date: Wed, 27 Apr 2005 11:29:34 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 15/16] e1000:Adjust flow control watermarks for Jumbo Frames (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RITd1O026413 X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2141 Lines: 54 Adjust flow control watermarks for Jumbo Frames Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -409,7 +409,10 @@ e1000_down(struct e1000_adapter *adapter  void  e1000_reset(struct e1000_adapter *adapter)  { +       struct net_device *netdev = adapter->netdev;         uint32_t pba, manc; +       uint16_t fc_high_water_mark = E1000_FC_HIGH_DIFF; +       uint16_t fc_low_water_mark = E1000_FC_LOW_DIFF;           /* Repartition Pba for greater than 9k mtu          * To take effect CTRL.RST is required. @@ -428,6 +428,16 @@                 break;         }   +       if((adapter->hw.mac_type != e1000_82573) && +          (adapter->rx_buffer_len > E1000_RXBUFFER_8192)) { +               pba -= 8; /* allocate more FIFO for Tx */ +               /* send an XOFF when there is enough space in the +                * Rx FIFO to hold one extra full size Rx packet +               */ +               fc_high_water_mark = netdev->mtu + ENET_HEADER_SIZE + +                                       ETHERNET_FCS_SIZE + 1; +               fc_low_water_mark = fc_high_water_mark + 8; +       }             if(adapter->hw.mac_type == e1000_82547) { @@ -442,9 +442,9 @@           /* flow control settings */         adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - -                                   E1000_FC_HIGH_DIFF; +                                   fc_high_water_mark;         adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - -                                  E1000_FC_LOW_DIFF; +                                  fc_low_water_mark;         adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME;         adapter->hw.fc_send_xon = 1;         adapter->hw.fc = adapter->hw.original_fc; From mallikarjuna.chilakala@intel.com Wed Apr 27 11:30:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:30:22 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIUH1O027063 for ; Wed, 27 Apr 2005 11:30:17 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3RIU8jI032490; Wed, 27 Apr 2005 18:30:08 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3RIT43T018655; Wed, 27 Apr 2005 18:30:08 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042711300704280 ; Wed, 27 Apr 2005 11:30:07 -0700 Date: Wed, 27 Apr 2005 11:30:07 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [RESEND][PATCH net-drivers-2.6 16/16] e1000:Driver version,white space,comments,device id (fwd) Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j3RIUH1O027063 X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 30964 Lines: 685 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c   2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c       2005-04-11 02:22:28.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -69,6 +69,7 @@ static const struct e1000_stats e1000_gs         { "rx_crc_errors", E1000_STAT(net_stats.rx_crc_errors) },         { "rx_frame_errors", E1000_STAT(net_stats.rx_frame_errors) },         { "rx_fifo_errors", E1000_STAT(net_stats.rx_fifo_errors) }, +       { "rx_no_buffer_count", E1000_STAT(stats.rnbc) },         { "rx_missed_errors", E1000_STAT(net_stats.rx_missed_errors) },         { "tx_aborted_errors", E1000_STAT(net_stats.tx_aborted_errors) },         { "tx_carrier_errors", E1000_STAT(net_stats.tx_carrier_errors) }, @@ -593,7 +594,7 @@ e1000_set_ringparam(struct net_device *n         tx_old = adapter->tx_ring;         rx_old = adapter->rx_ring;   -       if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) +       if((ring->rx_mini_pending) || (ring->rx_jumbo_pending))                 return -EINVAL;           if(netif_running(adapter->netdev)) @@ -784,8 +785,8 @@ e1000_intr_test(struct e1000_adapter *ad         /* Hook up test interrupt handler just for this test */         if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {                 shared_int = FALSE; -       } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, -                       netdev->name, netdev)){ +       } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, +                             netdev->name, netdev)){                 *data = 1;                 return -1;         } @@ -842,10 +843,8 @@ e1000_intr_test(struct e1000_adapter *ad                          * test failed.                          */                         adapter->test_icr = 0; -                       E1000_WRITE_REG(&adapter->hw, IMC, -                                       (~mask & 0x00007FFF)); -                       E1000_WRITE_REG(&adapter->hw, ICS, -                                       (~mask & 0x00007FFF)); +                       E1000_WRITE_REG(&adapter->hw, IMC, ~mask & 0x00007FFF); +                       E1000_WRITE_REG(&adapter->hw, ICS, ~mask & 0x00007FFF);                         msec_delay(10);                           if(adapter->test_icr) { @@ -1010,7 +1009,7 @@ e1000_setup_desc_rings(struct e1000_adap                 struct e1000_rx_desc *rx_desc = E1000_RX_DESC(*rxdr, i);                 struct sk_buff *skb;   -               if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, +               if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN,                                 GFP_KERNEL))) {                         ret_val = 6;                         goto err_nomem; @@ -1387,13 +1386,12 @@ static int  e1000_link_test(struct e1000_adapter *adapter, uint64_t *data)  {         *data = 0; -         if (adapter->hw.media_type == e1000_media_type_internal_serdes) {                 int i = 0;                 adapter->hw.serdes_link_down = TRUE;   -               /* on some blade server designs link establishment */ -               /* could take as long as 2-3 minutes.              */ +               /* On some blade server designs, link establishment +                * could take as long as 2-3 minutes */                 do {                         e1000_check_for_link(&adapter->hw);                         if (adapter->hw.serdes_link_down == FALSE) @@ -1401,7 +1373,7 @@ e1000_link_test(struct e1000_adapter *ad                         msec_delay(20);                 } while (i++ < 3750);   -               *data = 1; +               *data = 1;         } else {                 e1000_check_for_link(&adapter->hw);                 if(adapter->hw.autoneg)  /* if auto_neg is set wait for it */ diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h   2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h       2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -139,9 +138,9 @@ struct e1000_adapter;  /* How many Rx Buffers do we bundle into one write to the hardware ? */  #define E1000_RX_BUFFER_WRITE  16      /* Must be power of 2 */   -#define AUTO_ALL_MODES       0 -#define E1000_EEPROM_82544_APM 0x0004 -#define E1000_EEPROM_APME    0x0400 +#define AUTO_ALL_MODES            0 +#define E1000_EEPROM_82544_APM    0x0400 +#define E1000_EEPROM_APME         0x0400    #ifndef E1000_MASTER_SLAVE  /* Switch to override PHY master/slave setting */ diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.c net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.6/drivers/net/e1000/e1000_hw.c        2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c    2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -144,7 +144,6 @@ e1000_phy_init_script(struct e1000_hw *h        DEBUGFUNC("e1000_phy_init_script");   -      if(hw->phy_init_script) {          msec_delay(20);   diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.h net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.6/drivers/net/e1000/e1000_hw.h        2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h    2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c      2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c  2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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,33 +29,9 @@  #include "e1000.h"    /* Change Log - * 5.3.12      6/7/04 - * - kcompat NETIF_MSG for older kernels (2.4.9) - * - if_mii support and associated kcompat for older kernels - * - More errlogging support from Jon Mason - * - Fix TSO issues on PPC64 machines -- Jon Mason - * - * 5.7.1       12/16/04 - * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This - *   fix was removed as it caused system instability. The suspected cause of - *   this is the called to e1000_irq_disable in e1000_intr. Inlined the - *   required piece of e1000_irq_disable into e1000_intr - Anton Blanchard - * 5.7.0       12/10/04 - * - include fix to the condition that determines when to quit NAPI - Robert Olsson - * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down - * 5.6.5       11/01/04 - * - Enabling NETIF_F_SG without checksum offload is illegal - -     John Mason - * 5.6.3        10/26/04 - * - Remove redundant initialization - Jamal Hadi - * - Reset buffer_info->dma in tx resource cleanup logic - * 5.6.2       10/12/04 - * - Avoid filling tx_ring completely - shemminger@osdl.org - * - Replace schedule_timeout() with msleep()/msleep_interruptible() - - *   nacc@us.ibm.com - * - Sparse cleanup - shemminger@osdl.org - * - Fix tx resource cleanup logic - * - LLTX support - ak@suse.de and hadi@cyberus.ca + * 6.0.44+     2/15/05 + *   o applied Anton's patch to resolve tx hang in hardware + *   o Applied Andrew Mortons patch - e1000 stops working after resume   */    char e1000_driver_name[] = "e1000"; @@ -65,8 +110,8 @@ char e1000_driver_string[] = "Intel(R) P  #else  #define DRIVERNAPI "-NAPI"  #endif -#define DRV_VERSION "5.7.6-k2"DRIVERNAPI -char e1000_driver_version[] = DRV_VERSION; +#define DRV_VERSION "6.0.54-k2"DRIVERNAPI +char e1000_driver_version[] = DRV_VERSION;  char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation.";    /* e1000_pci_tbl - PCI Device ID Table @@ -96,6 +72,7 @@ static struct pci_device_id e1000_pci_tb         INTEL_E1000_ETHERNET_DEVICE(0x1017),         INTEL_E1000_ETHERNET_DEVICE(0x1018),         INTEL_E1000_ETHERNET_DEVICE(0x1019), +       INTEL_E1000_ETHERNET_DEVICE(0x101A),         INTEL_E1000_ETHERNET_DEVICE(0x101D),         INTEL_E1000_ETHERNET_DEVICE(0x101E),         INTEL_E1000_ETHERNET_DEVICE(0x1026), @@ -110,6 +87,9 @@ static struct pci_device_id e1000_pci_tb         INTEL_E1000_ETHERNET_DEVICE(0x107B),         INTEL_E1000_ETHERNET_DEVICE(0x107C),         INTEL_E1000_ETHERNET_DEVICE(0x108A), +       INTEL_E1000_ETHERNET_DEVICE(0x108B), +       INTEL_E1000_ETHERNET_DEVICE(0x108C), +       INTEL_E1000_ETHERNET_DEVICE(0x1099),         /* required last entry */         {0,}  }; @@ -350,8 +351,11 @@ e1000_up(struct e1000_adapter *adapter)  #endif         if((err = request_irq(adapter->pdev->irq, &e1000_intr,                               SA_SHIRQ | SA_SAMPLE_RANDOM, -                             netdev->name, netdev))) +                             netdev->name, netdev))) { +               DPRINTK(PROBE, ERR, +                   "Unable to allocate interrupt Error: %d\n", err);                 return err; +       }           mod_timer(&adapter->watchdog_timer, jiffies);   @@ -636,7 +619,7 @@ e1000_probe(struct pci_dev *pdev,           /* copy the MAC address out of the EEPROM */   -       if (e1000_read_mac_addr(&adapter->hw)) +       if(e1000_read_mac_addr(&adapter->hw))                 DPRINTK(PROBE, ERR, "EEPROM Read Error\n");         memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len);   @@ -963,12 +946,10 @@ e1000_check_64k_bound(struct e1000_adapt         unsigned long begin = (unsigned long) start;         unsigned long end = begin + len;   -       /* first rev 82545 and 82546 need to not allow any memory -        * write location to cross a 64k boundary due to errata 23 */ +       /* First rev 82545 and 82546 need to not allow any memory +        * write location to cross 64k boundary due to errata 23 */         if (adapter->hw.mac_type == e1000_82545 || -           adapter->hw.mac_type == e1000_82546 ) { - -               /* check buffer doesn't cross 64kB */ +           adapter->hw.mac_type == e1000_82546) {                 return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE;         }   @@ -992,8 +973,8 @@ e1000_setup_tx_resources(struct e1000_ad         size = sizeof(struct e1000_buffer) * txdr->count;         txdr->buffer_info = vmalloc(size);         if(!txdr->buffer_info) { -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Transmit descriptor ring\n"); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the transmit descriptor ring\n");                 return -ENOMEM;         }         memset(txdr->buffer_info, 0, size); @@ -1006,22 +925,22 @@ e1000_setup_tx_resources(struct e1000_ad         txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma);         if(!txdr->desc) {  setup_tx_desc_die: -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Transmit descriptor ring\n");                 vfree(txdr->buffer_info); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the transmit descriptor ring\n");                 return -ENOMEM;         }   -       /* fix for errata 23, cant cross 64kB boundary */ +       /* Fix for errata 23, can't cross 64kB boundary */         if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) {                 void *olddesc = txdr->desc;                 dma_addr_t olddma = txdr->dma; -               DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", -                       txdr->size, txdr->desc); -               /* try again, without freeing the previous */ +               DPRINTK(TX_ERR, ERR, "txdr align check failed: %u bytes " +                                    "at %p\n", txdr->size, txdr->desc); +               /* Try again, without freeing the previous */                 txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); -               /* failed allocation, critial failure */                 if(!txdr->desc) { +               /* Failed allocation, critical failure */                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                         goto setup_tx_desc_die;                 } @@ -1028,16 +925,16 @@                   if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) {                         /* give up */ -                       pci_free_consistent(pdev, txdr->size, -                            txdr->desc, txdr->dma); +                       pci_free_consistent(pdev, txdr->size, txdr->desc, +                                           txdr->dma);                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                         DPRINTK(PROBE, ERR, -                        "Unable to Allocate aligned Memory for the Transmit" -                        " descriptor ring\n"); +                               "Unable to allocate aligned memory " +                               "for the transmit descriptor ring\n");                         vfree(txdr->buffer_info);                         return -ENOMEM;                 } else { -                       /* free old, move on with the new one since its okay */ +                       /* Free old allocation, new allocation was successful */                         pci_free_consistent(pdev, txdr->size, olddesc, olddma);                 }         } @@ -1144,8 +1058,8 @@ e1000_setup_rx_resources(struct e1000_ad         size = sizeof(struct e1000_buffer) * rxdr->count;         rxdr->buffer_info = vmalloc(size);         if(!rxdr->buffer_info) { -               DPRINTK(PROBE, ERR, -               "Unable to Allocate Memory for the Recieve descriptor ring\n"); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the receive descriptor ring\n");                 return -ENOMEM;         }         memset(rxdr->buffer_info, 0, size); @@ -1185,25 +1058,24 @@           if(!rxdr->desc) {  setup_rx_desc_die: -               DPRINTK(PROBE, ERR, -               "Unble to Allocate Memory for the Recieve descriptor ring\n");                 vfree(rxdr->buffer_info);                 kfree(rxdr->ps_page);                 kfree(rxdr->ps_page_dma); +               DPRINTK(PROBE, ERR, +               "Unable to allocate memory for the receive descriptor ring\n");                 return -ENOMEM;         }   -       /* fix for errata 23, cant cross 64kB boundary */ +       /* Fix for errata 23, can't cross 64kB boundary */         if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) {                 void *olddesc = rxdr->desc;                 dma_addr_t olddma = rxdr->dma; -               DPRINTK(RX_ERR,ERR, -                       "rxdr align check failed: %u bytes at %p\n", -                       rxdr->size, rxdr->desc); -               /* try again, without freeing the previous */ +               DPRINTK(RX_ERR, ERR, "rxdr align check failed: %u bytes " +                                    "at %p\n", rxdr->size, rxdr->desc); +               /* Try again, without freeing the previous */                 rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); -               /* failed allocation, critial failure */                 if(!rxdr->desc) { +               /* Failed allocation, critical failure */                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma);                         goto setup_rx_desc_die;                 } @@ -1210,18 +1058,18 @@                   if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) {                         /* give up */ -                       pci_free_consistent(pdev, rxdr->size, -                            rxdr->desc, rxdr->dma); +                       pci_free_consistent(pdev, rxdr->size, rxdr->desc, +                                           rxdr->dma);                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma); -                       DPRINTK(PROBE, ERR, -                               "Unable to Allocate aligned Memory for the" -                               " Receive descriptor ring\n"); +                       DPRINTK(PROBE, ERR, +                               "Unable to allocate aligned memory " +                               "for the receive descriptor ring\n");                         vfree(rxdr->buffer_info);                         kfree(rxdr->ps_page);                         kfree(rxdr->ps_page_dma);                         return -ENOMEM;                 } else { -                       /* free old, move on with the new one since its okay */ +                       /* Free old allocation, new allocation was successful */                         pci_free_consistent(pdev, rxdr->size, olddesc, olddma);                 }         } @@ -1234,7 +1123,7 @@ setup_rx_desc_die:  }    /** - * e1000_setup_rctl - configure the receive control register + * e1000_setup_rctl - configure the receive control registers   * @adapter: Board private structure   **/   @@ -1426,13 +1406,11 @@ static inline void  e1000_unmap_and_free_tx_resource(struct e1000_adapter *adapter,                         struct e1000_buffer *buffer_info)  { -       struct pci_dev *pdev = adapter->pdev; -         if(buffer_info->dma) { -               pci_unmap_page(pdev, -                              buffer_info->dma, -                              buffer_info->length, -                              PCI_DMA_TODEVICE); +               pci_unmap_page(adapter->pdev, +                               buffer_info->dma, +                               buffer_info->length, +                               PCI_DMA_TODEVICE);                 buffer_info->dma = 0;         }         if(buffer_info->skb) { @@ -1457,7 +1435,7 @@ e1000_clean_tx_ring(struct e1000_adapter         /* Free all the Tx ring sk_buffs */           if (likely(adapter->previous_buffer_info.skb != NULL)) { -               e1000_unmap_and_free_tx_resource(adapter, +               e1000_unmap_and_free_tx_resource(adapter,                                 &adapter->previous_buffer_info);         }   @@ -1659,15 +1637,15 @@ e1000_set_multi(struct net_device *netde         struct e1000_adapter *adapter = netdev->priv;         struct e1000_hw *hw = &adapter->hw;         struct dev_mc_list *mc_ptr; +       unsigned long flags;         uint32_t rctl;         uint32_t hash_value;         int i; -       unsigned long flags; - -       /* Check for Promiscuous and All Multicast modes */           spin_lock_irqsave(&adapter->tx_lock, flags);   +       /* Check for Promiscuous and All Multicast modes */ +         rctl = E1000_READ_REG(hw, RCTL);           if(netdev->flags & IFF_PROMISC) { @@ -1874,7 +1852,7 @@ e1000_watchdog_task(struct e1000_adapter         /* Cause software interrupt to ensure rx ring is cleaned */         E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0);   -       /* Force detection of hung controller every watchdog period*/ +       /* Force detection of hung controller every watchdog period */         adapter->detect_tx_hung = TRUE;           /* Reset the timer */ @@ -2255,7 +2233,7 @@ e1000_xmit_frame(struct sk_buff *skb, st    #ifdef NETIF_F_TSO         mss = skb_shinfo(skb)->tso_size; -       /* The controller does a simple calculation to +       /* The controller does a simple calculation to          * make sure there is enough room in the FIFO before          * initiating the DMA for each buffer.  The calc is:          * 4 = ceil(buffer len/mss).  To make sure we don't @@ -2268,7 +2246,7 @@ e1000_xmit_frame(struct sk_buff *skb, st           if((mss) || (skb->ip_summed == CHECKSUM_HW))                 count++; -       count++;        /* for sentinel desc */ +       count++;  #else         if(skb->ip_summed == CHECKSUM_HW)                 count++; @@ -2658,7 +2315,7 @@ e1000_intr(int irq, void *data, struct p         */         if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){                 atomic_inc(&adapter->irq_sem); -               E1000_WRITE_REG(&adapter->hw, IMC, ~0); +               E1000_WRITE_REG(hw, IMC, ~0);         }           for(i = 0; i < E1000_MAX_INTR; i++) @@ -2686,7 +2355,7 @@ e1000_clean(struct net_device *netdev, i         int work_to_do = min(*budget, netdev->quota);         int tx_cleaned;         int work_done = 0; -       +         tx_cleaned = e1000_clean_tx_irq(adapter);         adapter->clean_rx(adapter, &work_done, work_to_do);   @@ -2776,9 +2443,9 @@ e1000_clean_tx_irq(struct e1000_adapter                 netif_wake_queue(netdev);           spin_unlock(&adapter->tx_lock); -         if(adapter->detect_tx_hung) { -               /* detect a transmit hang in hardware, this serializes the + +               /* Detect a transmit hang in hardware, this serializes the                  * check with the clearing of time_stamp and movement of i */                 adapter->detect_tx_hung = FALSE;                 if (tx_ring->buffer_info[i].dma && @@ -2923,7 +2901,7 @@ e1000_clean_rx_irq(struct e1000_adapter                 if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) {                         /* All receives must fit into a single buffer */                         E1000_DBG("%s: Receive packet consumed multiple" -                                       " buffers\n", netdev->name); +                                 " buffers\n", netdev->name);                         dev_kfree_skb_irq(skb);                         goto next_desc;                 } @@ -3130,32 +2619,33 @@ e1000_alloc_rx_buffers(struct e1000_adap         struct e1000_rx_desc *rx_desc;         struct e1000_buffer *buffer_info;         struct sk_buff *skb; -       unsigned int i, bufsz; +       unsigned int i; +       unsigned int bufsz = adapter->rx_buffer_len + NET_IP_ALIGN;           i = rx_ring->next_to_use;         buffer_info = &rx_ring->buffer_info[i];           while(!buffer_info->skb) { -               bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; -                 skb = dev_alloc_skb(bufsz); +                 if(unlikely(!skb)) {                         /* Better luck next round */                         break;                 }   -               /* fix for errata 23, cant cross 64kB boundary */ +               /* Fix for errata 23, can't cross 64kB boundary */                 if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {                         struct sk_buff *oldskb = skb; -                       DPRINTK(RX_ERR,ERR, -                               "skb align check failed: %u bytes at %p\n", -                               bufsz, skb->data); -                       /* try again, without freeing the previous */ +                       DPRINTK(RX_ERR, ERR, "skb align check failed: %u bytes " +                                            "at %p\n", bufsz, skb->data); +                       /* Try again, without freeing the previous */                         skb = dev_alloc_skb(bufsz); +                       /* Failed allocation, critical failure */                         if (!skb) {                                 dev_kfree_skb(oldskb);                                 break;                         } +                         if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) {                                 /* give up */                                 dev_kfree_skb(skb); @@ -3162,11 +2619,10 @@                                 dev_kfree_skb(oldskb);                                 break; /* while !buffer_info->skb */                         } else { -                               /* move on with the new one */ +                               /* Use new allocation */                                 dev_kfree_skb(oldskb);                         }                 } -                 /* Make buffer alignment 2 beyond a 16 byte boundary                  * this will result in a 16 byte aligned IP header after                  * the 14 byte MAC header is removed @@ -3182,25 +3160,23 @@ e1000_alloc_rx_buffers(struct e1000_adap                                                   adapter->rx_buffer_len,                                                   PCI_DMA_FROMDEVICE);   -               /* fix for errata 23, cant cross 64kB boundary */ -               if(!e1000_check_64k_bound(adapter, -                                              (void *)(unsigned long)buffer_info->dma, -                                              adapter->rx_buffer_len)) { -                       DPRINTK(RX_ERR,ERR, -                               "dma align check failed: %u bytes at %ld\n", -                               adapter->rx_buffer_len, (unsigned long)buffer_info->dma); - +               /* Fix for errata 23, can't cross 64kB boundary */ +               if (!e1000_check_64k_bound(adapter, +                                       (void *)(unsigned long)buffer_info->dma, +                                       adapter->rx_buffer_len)) { +                       DPRINTK(RX_ERR, ERR, +                               "dma align check failed: %u bytes at %p\n", +                               adapter->rx_buffer_len, +                               (void *)(unsigned long)buffer_info->dma);                         dev_kfree_skb(skb);                         buffer_info->skb = NULL;   -                       pci_unmap_single(pdev, -                                        buffer_info->dma, +                       pci_unmap_single(pdev, buffer_info->dma,                                          adapter->rx_buffer_len,                                          PCI_DMA_FROMDEVICE);                           break; /* while !buffer_info->skb */                 } -                 rx_desc = E1000_RX_DESC(*rx_ring, i);                 rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);   @@ -3210,7 +3186,6 @@ e1000_alloc_rx_buffers(struct e1000_adap                          * applicable for weak-ordered memory model archs,                          * such as IA-64). */                         wmb(); -                         E1000_WRITE_REG(&adapter->hw, RDT, i);                 }   @@ -3483,9 +3458,10 @@ void  e1000_pci_set_mwi(struct e1000_hw *hw)  {         struct e1000_adapter *adapter = hw->back; +       int ret_val = pci_set_mwi(adapter->pdev);   -       int ret; -       ret = pci_set_mwi(adapter->pdev); +       if(ret_val) +               DPRINTK(PROBE, ERR, "Error in setting MWI\n");  }    void @@ -3643,8 +3619,7 @@ e1000_set_spd_dplx(struct e1000_adapter                 break;         case SPEED_1000 + DUPLEX_HALF: /* not supported */         default: -               DPRINTK(PROBE, ERR, -                       "Unsupported Speed/Duplexity configuration\n"); +               DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n");                 return -EINVAL;         }         return 0; @@ -3810,7 +3785,7 @@ e1000_resume(struct pci_dev *pdev)   * the interrupt routine is executing.   */  static void -e1000_netpoll (struct net_device *netdev) +e1000_netpoll(struct net_device *netdev)  {         struct e1000_adapter *adapter = netdev->priv;         disable_irq(adapter->pdev->irq); diff -up net-drivers-2.6/drivers/net/e1000/e1000_osdep.h net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.6/drivers/net/e1000/e1000_osdep.h     2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.6/drivers/net/e1000/e1000_param.c net-drivers-2.6/drivers/net/e1000.new/e1000_param.c --- net-drivers-2.6/drivers/net/e1000/e1000_param.c     2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_param.c 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@  /*******************************************************************************      -  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. +  Copyright(c) 1999 - 2005 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 @@ -478,7 +532,6 @@ e1000_check_options(struct e1000_adapter                                 DPRINTK(PROBE, INFO, "%s set to dynamic mode\n",                                         opt.name);                                 break; -                       case -1:                         default:                                 e1000_validate_option(&adapter->itr, &opt,                                         adapter); From mcmanus@ducksong.com Wed Apr 27 11:32:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 11:32:50 -0700 (PDT) Received: from datapower.ducksong.com ([66.238.194.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RIWb1O028327 for ; Wed, 27 Apr 2005 11:32:38 -0700 Received: from [127.0.0.1] (mcmanus.datapower.com [127.0.0.1]) by datapower.ducksong.com (8.12.10/8.12.10) with ESMTP id j3RIXqZL012905 for ; Wed, 27 Apr 2005 14:33:56 -0400 Subject: how to suppress link local addresses From: patrick mcmanus To: "netdev@oss.sgi.com" Content-Type: text/plain Message-Id: <1114626832.12304.97.camel@mcmanus.datapower.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 27 Apr 2005 14:33:52 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcmanus@ducksong.com Precedence: bulk X-list: netdev Content-Length: 7205 Lines: 130 Hi All, I've got a 2.6.12-rc2 kernel with IPv6 compiled in monolithically. I'm using it on several different boxes and would like them all to run the same kernel. Most of the boxes have IPv6 connectivity and are working fine.. however one of them is on an IPv4 only net. When I bring up an IPv4 interface on that box it also gets an automagic ipv6 link-local address as a bonus. I would like to prevent that from happening if possible.. I had thought that the conf/*/autoconf sysctl should do that for me, but I couldn't get it to work (see my illustration below). I'm not certain if that's a bug or I just don't understand what that is supposed to do. The link-local address isn't a problem most of the time. But every once in a while a program decides I have IPv6 connectivity because of the link-local addresses and it will try and use that, and then it just gets timeouts.. an easy example for you to try is "dig ns example.com @b.gtld-servers.net." .. that will fail because b.gtld-servers.net has a AAAA record that dig gives priority to using if I have any ipv6 addresses configured - even though I'm not on a real ipv6 network. (c.gtld-servers.net passes because it doesn't have any AAAA records). If I manually delete the link-locals from each address dig works fine.. and I can do this, but I'd rather not have them appear at all. I want this to be an ipv4-only configured box with an ipv6 capable kernel. My efforts at using autoconf are illustrated below.. Any thoughts? Hopefully this is simple. Thanks. /home/mcmanus>cat /proc/sys/net/ipv6/conf/default/autoconf 0 /home/mcmanus>cat /proc/sys/net/ipv6/conf/all/autoconf 0 /home/mcmanus>cat /proc/sys/net/ipv6/conf/eth1/autoconf cat: /proc/sys/net/ipv6/conf/eth1/autoconf: No such file or directory /home/mcmanus>cat /proc/sys/net/ipv6/conf/default/accept_ra 0 /home/mcmanus>cat /proc/sys/net/ipv6/conf/all/accept_ra 0 /home/mcmanus>cat /proc/sys/net/ipv6/conf/eth1/accept_ra cat: /proc/sys/net/ipv6/conf/eth1/accept_ra: No such file or directory /home/mcmanus>su Password: root@book:/home/mcmanus # strace ifconfig eth1 192.168.16.49 broadcast 192.168.16.255 netmask 255.255.255.0 execve("/sbin/ifconfig", ["ifconfig", "eth1", "192.168.16.49", "broadcast", "192.168.16.255", "netmask", "255.255.255.0"], [/* 32 vars */]) = 0 uname({sys="Linux", node="book", ...}) = 0 brk(0) = 0x8057000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fa6000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=60457, ...}) = 0 old_mmap(NULL, 60457, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f97000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\215Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1222116, ...}) = 0 old_mmap(NULL, 1232428, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7e6a000 old_mmap(0xb7f8c000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x121000) = 0xb7f8c000 old_mmap(0xb7f95000, 7724, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f95000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e69000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e69080, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f97000, 60457) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1384816, ...}) = 0 mmap2(NULL, 1384816, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d16000 close(3) = 0 brk(0) = 0x8057000 brk(0x8078000) = 0x8078000 brk(0) = 0x8078000 uname({sys="Linux", node="book", ...}) = 0 access("/proc/net", R_OK) = 0 access("/proc/net/unix", R_OK) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 3 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 access("/proc/net/if_inet6", R_OK) = 0 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5 access("/proc/net/ax25", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/nr", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/rose", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/ipx", R_OK) = 0 socket(PF_IPX, SOCK_DGRAM, [PF_UNSPEC]) = 6 access("/proc/net/appletalk", R_OK) = -1 ENOENT (No such file or directory) access("/proc/sys/net/econet", R_OK) = -1 ENOENT (No such file or directory) access("/proc/sys/net/ash", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/x25", R_OK) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=2539, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cf6000 read(7, "# Locale name alias data base.\n#"..., 131072) = 2539 read(7, "", 131072) = 0 close(7) = 0 munmap(0xb7cf6000, 131072) = 0 open("/usr/share/locale/en_GB/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_GB/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US/LC_MESSAGES/net-tools.mo", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(4, SIOCSIFADDR, 0xbfdba7e0) = 0 ioctl(4, SIOCGIFFLAGS, 0xbfdba700) = 0 ioctl(4, SIOCSIFFLAGS, 0xbfdba700) = 0 ioctl(4, SIOCSIFBRDADDR, 0xbfdba7e0) = 0 ioctl(4, SIOCGIFFLAGS, 0xbfdba700) = 0 ioctl(4, SIOCSIFFLAGS, 0xbfdba700) = 0 ioctl(4, SIOCSIFNETMASK, 0xbfdba7e0) = 0 exit_group(0) = ? root@book:/home/mcmanus # exit /home/mcmanus>ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0F:EA:18:AD:7D inet addr:192.168.16.49 Bcast:192.168.16.255 Mask:255.255.255.0 inet6 addr: fe80::20f:eaff:fe18:ad7d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:378 (378.0 b) Interrupt:177 Base address:0xe800 /home/mcmanus>uname -a Linux book 2.6.12-rc2ducksong #2 Sat Apr 9 17:07:02 EDT 2005 i686 GNU/Linux -Patrick From davem@davemloft.net Wed Apr 27 12:01:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 12:01:59 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RJ1t1O000371 for ; Wed, 27 Apr 2005 12:01:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DQrVL-0001X3-00; Wed, 27 Apr 2005 11:43:23 -0700 Date: Wed, 27 Apr 2005 11:43:23 -0700 From: "David S. Miller" To: Andi Kleen Cc: glen.turner@aarnet.edu.au, netdev@oss.sgi.com Subject: Re: network manpages was Re: is UDP_CORK "real" Message-Id: <20050427114323.53e43e32.davem@davemloft.net> In-Reply-To: <20050427122648.GA12597@muc.de> References: <426833F0.9010803@hp.com> <426F2A1D.10001@aarnet.edu.au> <20050427122648.GA12597@muc.de> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 523 Lines: 13 On 27 Apr 2005 14:26:48 +0200 Andi Kleen wrote: > It would be nice of course if David could enforce a policy > to require a manpage patch for new ioctls/socket options etc. > in the future, then such documentation lag would not happen. I could easily do this if the files were in the kernel tree itself, but since it's external it's not so easy to do. Why don't we put them into the kernel tree? They are just small documents and I bet they will stay in sync better if they were moved into the kernel tree. From garzik@havoc.gtf.org Wed Apr 27 14:18:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 14:18:19 -0700 (PDT) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RLIE1O010526 for ; Wed, 27 Apr 2005 14:18:16 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id A6CB0A879F; Wed, 27 Apr 2005 17:05:45 -0400 (EDT) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20272-09; Wed, 27 Apr 2005 17:05:39 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 48D93A8791; Wed, 27 Apr 2005 17:05:35 -0400 (EDT) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 383531C0DF0D; Wed, 27 Apr 2005 17:17:54 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j3RLHofc027540; Wed, 27 Apr 2005 17:17:50 -0400 Date: Wed, 27 Apr 2005 17:17:50 -0400 From: Jeff Garzik To: Marcelo Tosatti Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [BK PATCHES] 2.4.x net driver updates Message-ID: <20050427211750.GA27516@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 278 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: 3070 Lines: 93 Ditto for net drivers... this is my last 'bk pull' request for you, before we both (presumably) switch to git. Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: drivers/net/bonding/bond_main.c | 15 +++++++++++---- drivers/net/pcnet32.c | 3 ++- 2 files changed, 13 insertions(+), 5 deletions(-) through these ChangeSets: (05/03/30 1.1448.129.2) [PATCH] bonding fix It fixes a stack dump when unloading the bonding module in 802.3ad mode if spinlock debugging is turned on, and it was already merged in 2.6. Signed-off-by: Jeff Garzik (05/03/30 1.1448.129.1) [PATCH] pcnet32: 79C975 fiber fix From: "HARDY, Steven" I have found a bug in the pcnet32 driver (drivers/net/pcnet32.c) affecting all ethernet cards based on the AMD79C975 chip, using the fiber interface. It's a one line fix, where some config registers get corrupted during initialisation (which stops the Fiber interface working with this chip) This bug was introduced somewhere betweeen 2.4.17 and 2.6.x (noticed whilst upgrading to 2.6), and it may affect other chips too. I have checked all versions up to 2.6.11-bk6 and they are all broken. Signed-off-by: Andrew Morton Signed-off-by: Don Fry Signed-off-by: Jeff Garzik diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c 2005-04-27 17:16:28 -04:00 +++ b/drivers/net/bonding/bond_main.c 2005-04-27 17:16:28 -04:00 @@ -469,6 +469,13 @@ * * Add support for VLAN hardware acceleration capable slaves. * * Add capability to tag self generated packets in ALB/TLB modes. * Set version to 2.6.0. + * 2004/10/29 - Mitch Williams + * - Fixed bug when unloading module while using 802.3ad. If + * spinlock debugging is turned on, this causes a stack dump. + * Solution is to move call to dev_remove_pack outside of the + * spinlock. + * Set version to 2.6.1. + * */ //#define BONDING_DEBUG 1 @@ -3565,14 +3572,14 @@ { struct bonding *bond = bond_dev->priv; - write_lock_bh(&bond->lock); - - bond_mc_list_destroy(bond); - if (bond->params.mode == BOND_MODE_8023AD) { /* Unregister the receive of LACPDUs */ bond_unregister_lacpdu(bond); } + + write_lock_bh(&bond->lock); + + bond_mc_list_destroy(bond); /* signal timers not to re-arm */ bond->kill_timers = 1; diff -Nru a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c --- a/drivers/net/pcnet32.c 2005-04-27 17:16:28 -04:00 +++ b/drivers/net/pcnet32.c 2005-04-27 17:16:28 -04:00 @@ -1348,7 +1348,8 @@ printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; - a->write_bcr(ioaddr, 2, 0x1002); /* enable LED writes */ + /* enable LED writes */ + a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1000); return 0; From herbert@gondor.apana.org.au Wed Apr 27 14:42:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 14:42:50 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RLgc1O011406 for ; Wed, 27 Apr 2005 14:42:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQuIe-0002OA-00; Thu, 28 Apr 2005 07:42:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQuIa-0005f8-00; Thu, 28 Apr 2005 07:42:24 +1000 Date: Thu, 28 Apr 2005 07:42:24 +1000 To: Tommy Christensen Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost Message-ID: <20050427214224.GA25325@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426FDF8B.1030808@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2000 Lines: 43 On Wed, Apr 27, 2005 at 08:52:59PM +0200, Tommy Christensen wrote: > > My theory was this: Almost all drivers should be able to use the generic > watchdog (and I believe most of them do). If the "TX stalled" supervision > isn't appropriate for some particular driver, e.g. due to unorthodox use > of netif_stop_queue, then I didn't want to force my addition on this > driver either. Not having a TX timeout handler doesn't mean that the driver is doing something weird. If you do a grep in drivers/net you'll find loads of drivers that don't have TX timeout handlers but their handling of stop_queue/start_queue is exactly the same as anybody else. There's also another problem. The thing that triggered the original discussion is the fact that the socket send buffer was filled up. Theoretically, it is possible to exhaust someone's socket buffer without filling up a NIC's TX ring. Assuming that the NIC does not transmit at all when the carrier is off, the watchdog would not trigger and your application will block anyway. > Hooking into dev_watchdog() has the additional benefit of adding some > latency, so that a short-break doesn't necessarily trigger the flushing. I don't think this is too important. If your link is flapping constantly then you've got a serious problem. If it's just an isolated event then whether we do the flush or not isn't going to have a significant impact on the system. Besides, someone might be watching from user-space and could have taken much more drastic actions as a result of the carrier off message which is certainly not delayed. > ... unless the HW already takes care of this by draining the packets > from the ring buffer, disregarding the link status. Although this may be true for a lot of NICs, you can't bank on that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mrmacman_g4@mac.com Wed Apr 27 15:57:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 15:57:34 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RMvR1O013408 for ; Wed, 27 Apr 2005 15:57:27 -0700 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id j3RMv93C002361; Wed, 27 Apr 2005 15:57:11 -0700 (PDT) Received: from [10.0.0.2] (ip70-187-212-71.dc.dc.cox.net [70.187.212.71]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j3RMv6Ea010026 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Apr 2005 15:57:08 -0700 (PDT) In-Reply-To: <20050426061011.GA8527@codeblau.de> References: <20050311202122.GA13205@fefe.de> <20050311173308.7a076e8f.akpm@osdl.org> <20050324.205902.119922975.yoshfuji@linux-ipv6.org> <20050425195736.GB3123@codeblau.de> <20050426061011.GA8527@codeblau.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Pekka Savola , netdev@oss.sgi.com, "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , linux-kernel@vger.kernel.org From: Kyle Moffett Subject: Re: IPv6 has trouble assigning an interface Date: Wed, 27 Apr 2005 18:57:05 -0400 To: Felix von Leitner X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mrmacman_g4@mac.com Precedence: bulk X-list: netdev Content-Length: 890 Lines: 23 On Apr 26, 2005, at 02:10, Felix von Leitner wrote: > OK for unicast. But multicast? I expected link-local multicast > to send on _all_ interfaces if I don't specify one. This statement makes no sense. "link-local ... on all interfaces". Isn't "link-local" supposed to mean that the address is unique and available only on that interface (ethernet segment)? It's possible to get the _same_ link-local address on multiple ethernet segments, so in that case, where would you send the packet??? When you send link-local packets, you must specify the link to which it is local. Cheers, Kyle Moffett -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-) ------END GEEK CODE BLOCK------ From tommy.christensen@tpack.net Wed Apr 27 16:26:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 16:26:22 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RNQI1O019982 for ; Wed, 27 Apr 2005 16:26:19 -0700 Received: (qmail 18056 invoked from network); 27 Apr 2005 23:26:14 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.9) by 0 with SMTP; 27 Apr 2005 23:26:14 -0000 Message-ID: <42701FFD.5000505@tpack.net> Date: Thu, 28 Apr 2005 01:27:57 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> In-Reply-To: <20050427214224.GA25325@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 2644 Lines: 60 Herbert Xu wrote: > On Wed, Apr 27, 2005 at 08:52:59PM +0200, Tommy Christensen wrote: > >>My theory was this: Almost all drivers should be able to use the generic >>watchdog (and I believe most of them do). If the "TX stalled" supervision >>isn't appropriate for some particular driver, e.g. due to unorthodox use >>of netif_stop_queue, then I didn't want to force my addition on this >>driver either. > > > Not having a TX timeout handler doesn't mean that the driver is doing > something weird. If you do a grep in drivers/net you'll find loads > of drivers that don't have TX timeout handlers but their handling of > stop_queue/start_queue is exactly the same as anybody else. Hmm, maybe this is more common than I thought. But do any of these really have a problem? I.e. do they call netif_stop_queue on link down? That's the case I'm trying to address with the patch. > There's also another problem. The thing that triggered the original > discussion is the fact that the socket send buffer was filled up. > Theoretically, it is possible to exhaust someone's socket buffer > without filling up a NIC's TX ring. Assuming that the NIC does not > transmit at all when the carrier is off, the watchdog would not trigger > and your application will block anyway. This is indeed possible, but hopefully you can agree that this would be a driver bug. As stated above, I'm not trying to solve everything. We have to assume some level of sanity of the drivers. E.g. for a NIC that stalls the TX engine on carrier off, the driver would have to flush the TX ring and either call netif_stop_queue or discard packets in their hard_start_xmit function. At present, even such well-behaving drivers would hit the problem, because packets were piling up in the qdisc. >>Hooking into dev_watchdog() has the additional benefit of adding some >>latency, so that a short-break doesn't necessarily trigger the flushing. > > > I don't think this is too important. If your link is flapping constantly > then you've got a serious problem. If it's just an isolated event then > whether we do the flush or not isn't going to have a significant impact > on the system. > > Besides, someone might be watching from user-space and could have taken > much more drastic actions as a result of the carrier off message which is > certainly not delayed. Good point. So I shouldn't be too carefull. >>... unless the HW already takes care of this by draining the packets >>from the ring buffer, disregarding the link status. > > > Although this may be true for a lot of NICs, you can't bank on that. > > Cheers, Thanks for your comments, Herbert. Tommy From dlstevens@us.ibm.com Wed Apr 27 16:31:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 16:31:28 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNVO1O020659 for ; Wed, 27 Apr 2005 16:31:25 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3RNVLua484196 for ; Wed, 27 Apr 2005 19:31:21 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3RNVLYg250542 for ; Wed, 27 Apr 2005 17:31:21 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3RNVKKP031556 for ; Wed, 27 Apr 2005 17:31:21 -0600 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3RNVKVI031550; Wed, 27 Apr 2005 17:31:20 -0600 In-Reply-To: To: Kyle Moffett Cc: Felix von Leitner , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Pekka Savola , "YOSHIFUJI Hideaki / ?$B5HF#1QL@" MIME-Version: 1.0 Subject: Re: IPv6 has trouble assigning an interface X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 27 Apr 2005 16:31:18 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/27/2005 17:31:19, Serialize complete at 04/27/2005 17:31:19 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 283 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: 1367 Lines: 26 netdev-bounce@oss.sgi.com wrote on 04/27/2005 03:57:05 PM: > On Apr 26, 2005, at 02:10, Felix von Leitner wrote: > > OK for unicast. But multicast? I expected link-local multicast > > to send on _all_ interfaces if I don't specify one. (I didn't see the article this is quoting-- apparently wasn't CC-ed to "netdev" as the original was). Multicasting doesn't work that way. Multicast group memberships are per-device (whether or not they are link-local). If you join the same group address on two different devices, they'll only be the same group if there are multicast routers on the two links connecting them in the same multicast routing hierarchy. With a scope broader than link-local, and a multicast router on that link, the packets can be forwarded to other links, but they won't be forwarded to every host on the internet in that group (!), and there are sometimes good reasons for having different partitions of the same group within a single organization. So, the same group number on two different links is not necessarily the same group. It depends entirely on whether the two groups have common multicast routers with no policy restricting forwarding for that group between them. This is how IPv4 multicasting works, too. You join a group on a particular device. +-DLS From herbert@gondor.apana.org.au Wed Apr 27 16:39:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 16:39:45 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNdd1O021692 for ; Wed, 27 Apr 2005 16:39:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQw7r-0003Jh-00; Thu, 28 Apr 2005 09:39:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQw7o-0005ow-00; Thu, 28 Apr 2005 09:39:24 +1000 Date: Thu, 28 Apr 2005 09:39:24 +1000 To: Jamal Hadi Salim Cc: netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050427233924.GA22238@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114604826.7670.24.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1298 Lines: 34 On Wed, Apr 27, 2005 at 08:27:06AM -0400, Jamal Hadi Salim wrote: > > --- /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 > +++ /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 12:25:24 > @@ -345,7 +345,9 @@ > > write_lock_bh(&xfrm_policy_lock); > for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { > - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { > + if (!delpol && > + ((!excl && policy->index && (policy->index == pol->index)) || > + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { I have no problems with the idea itself. However, I have a couple of minor issues with this patch :) First of all please align the continued lines to the if expression, e.g., if (!delpol && (policy->index && (policy->index == pol->index)) || Also the excl check doesn't make sense. You should let the following excl check take place after you've found out that the indices is identical. > if (excl) { > write_unlock_bh(&xfrm_policy_lock); > return -EEXIST; Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed Apr 27 16:44:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 16:44:14 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNiA1O022363 for ; Wed, 27 Apr 2005 16:44:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQwCH-0003Lr-00; Thu, 28 Apr 2005 09:44:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQwCF-0005pb-00; Thu, 28 Apr 2005 09:43:59 +1000 Date: Thu, 28 Apr 2005 09:43:59 +1000 To: Tommy Christensen Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost Message-ID: <20050427234359.GB22238@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42701FFD.5000505@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1640 Lines: 36 On Thu, Apr 28, 2005 at 01:27:57AM +0200, Tommy Christensen wrote: > > Hmm, maybe this is more common than I thought. But do any of these really > have a problem? I.e. do they call netif_stop_queue on link down? > That's the case I'm trying to address with the patch. You're still assuming that the hardware will continue to drain packets when the carrier goes off. This may be true for a lot of NICs, but it is certainly not universal. > This is indeed possible, but hopefully you can agree that this would be > a driver bug. As stated above, I'm not trying to solve everything. We > have to assume some level of sanity of the drivers. E.g. for a NIC that > stalls the TX engine on carrier off, the driver would have to flush the > TX ring and either call netif_stop_queue or discard packets in their > hard_start_xmit function. At present, even such well-behaving drivers > would hit the problem, because packets were piling up in the qdisc. I am not saying that there is nothing to fix. I'm simply stating that doing it in the watchdog is not ideal for two reasons: 1) The watchdog is not always there. 2) The delay introduced by the watchdog is driver-dependent and varies wildly. For the purpose of shutting down the qdisc after a carrier off we want everything to use the same delay (if we're going to delay at all). So instead of doing it in the watchdog, just do both actions in the link_watch worker. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bernd-schubert@gmx.de Wed Apr 27 16:50:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 16:50:12 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RNo71O023413 for ; Wed, 27 Apr 2005 16:50:08 -0700 Received: (qmail invoked by alias); 27 Apr 2005 23:50:02 -0000 Received: from p54ABA02D.dip0.t-ipconnect.de (EHLO [192.168.6.2]) [84.171.160.45] by mail.gmx.net (mp009) with SMTP; 28 Apr 2005 01:50:02 +0200 X-Authenticated: #19095397 From: Bernd Schubert To: Ralf Baechle Subject: Re: list admin? unsubscribing from the list? Date: Thu, 28 Apr 2005 01:50:52 +0200 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <200504271647.28759.bernd.schubert@pci.uni-heidelberg.de> <20050427170850.GA30431@linux-mips.org> In-Reply-To: <20050427170850.GA30431@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504280150.52991.bernd-schubert@gmx.de> X-Y-GMX-Trusted: 0 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd-schubert@gmx.de Precedence: bulk X-list: netdev Content-Length: 664 Lines: 16 On Wednesday 27 April 2005 19:08, Ralf Baechle wrote: > On Wed, Apr 27, 2005 at 04:47:25PM +0200, Bernd Schubert wrote: > > several month ago I subscribed to this list and about two moth ago I > > unsubscribed again. > > About two weeks ago I receiced mail from the list, after unsubscribing > > again this stopped. Today I'm again receiving mail from the list, but > > unsubscribing fails: > > A funny little accident due to oss recently having changed hardware twice > after the old machine died - with some chaos following. I fixed up the > subscriber lists, so you should no longer receive email. Things should > to run smoothly now. Thanks a lot! Bernd From hadi@cyberus.ca Wed Apr 27 18:13:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:13:45 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1Df1O026248 for ; Wed, 27 Apr 2005 18:13:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQxb6-0006TM-6d for netdev@oss.sgi.com; Wed, 27 Apr 2005 21:13:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQxb1-0000aA-QZ; Wed, 27 Apr 2005 21:13:40 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <20050427233924.GA22238@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 21:13:36 -0400 Message-Id: <1114650816.7663.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 287 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: 1293 Lines: 35 On Thu, 2005-28-04 at 09:39 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 08:27:06AM -0400, Jamal Hadi Salim wrote: > > > > --- /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 > > +++ /usr/src/26117-mod/net/xfrm/xfrm_policy.c 2005/04/27 12:25:24 > > @@ -345,7 +345,9 @@ > > > > write_lock_bh(&xfrm_policy_lock); > > for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { > > - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { > > + if (!delpol && > > + ((!excl && policy->index && (policy->index == pol->index)) || > > + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { > > I have no problems with the idea itself. However, I have a couple of > minor issues with this patch :) > > First of all please align the continued lines to the if expression, e.g., > if (!delpol && > (policy->index && (policy->index == pol->index)) || > np. sorry, i was rushing out - testing as we speak. > Also the excl check doesn't make sense. You should let the > following excl check take place after you've found out that > the indices is identical. > the policy->index is only relevant for the update not the add; the update could also be done by selector. So i didnt follow. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 18:21:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:21:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1Lj1O027445 for ; Wed, 27 Apr 2005 18:21:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQxij-0003r7-00; Thu, 28 Apr 2005 11:21:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQxih-0005z0-00; Thu, 28 Apr 2005 11:21:35 +1000 Date: Thu, 28 Apr 2005 11:21:35 +1000 To: jamal Cc: netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428012135.GA22950@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114650816.7663.13.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1166 Lines: 28 On Wed, Apr 27, 2005 at 09:13:36PM -0400, jamal wrote: > > > > + if (!delpol && > > > + ((!excl && policy->index && (policy->index == pol->index)) || > > > + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { > > > Also the excl check doesn't make sense. You should let the > > following excl check take place after you've found out that > > the indices is identical. > > the policy->index is only relevant for the update not the add; > the update could also be done by selector. So i didnt follow. I see. In that case you want to change your expression above so that the memcmp is never done if excl is off and the index is non-zero. Otherwise this will result in non-deterministic behaviour as the result will change depending on whether the first hit is an index match or a selector match. Actually, would it be so bad to check the policy->index for the add case? It does have a well-defined meaning there. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed Apr 27 18:30:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:30:31 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1UO1O028258 for ; Wed, 27 Apr 2005 18:30:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQxr8-0003tQ-00; Thu, 28 Apr 2005 11:30:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQxr4-000601-00; Thu, 28 Apr 2005 11:30:14 +1000 Date: Thu, 28 Apr 2005 11:30:14 +1000 To: jamal Cc: netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428013014.GA23043@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428012135.GA22950@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 996 Lines: 26 On Thu, Apr 28, 2005 at 11:21:35AM +1000, herbert wrote: > > I see. In that case you want to change your expression above > so that the memcmp is never done if excl is off and the index > is non-zero. Otherwise this will result in non-deterministic > behaviour as the result will change depending on whether the > first hit is an index match or a selector match. Sorry, the index match needs more work. We need to maintain these invariants: 1) There is only one policy with a given selector. 2) There is only one policy with a given index. So to allow matching by index when updating, we need to deal with the possibility of having to delete two existing policies. The current code simply can't deal with that. So if we're going to do this we'll need a bigger patch :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 18:44:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:44:57 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1ir1O029117 for ; Wed, 27 Apr 2005 18:44:55 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DQy5A-0006X7-CJ for netdev@oss.sgi.com; Wed, 27 Apr 2005 19:44:48 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQy5B-00049g-4h; Wed, 27 Apr 2005 21:44:49 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <20050428012135.GA22950@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-vLEVTr45h8CK2KiIrX87" Organization: unknown Date: Wed, 27 Apr 2005 21:44:40 -0400 Message-Id: <1114652680.7663.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 290 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: 2554 Lines: 75 --=-vLEVTr45h8CK2KiIrX87 Content-Type: text/plain Content-Transfer-Encoding: 7bit I found a bug in the kernel that i initially thought was in "ip x p". If you specify an index when creating a new rule, the kernel overrides it regardless. So i can now update by index with attached patch. On Thu, 2005-28-04 at 11:21 +1000, Herbert Xu wrote: > I see. In that case you want to change your expression above > so that the memcmp is never done if excl is off and the index > is non-zero. Hrm. Thinking... So you want to exclude the selector check if someone updating ever specified the index? That may change things a little, no? Give me a clever expression. > Otherwise this will result in non-deterministic > behaviour as the result will change depending on whether the > first hit is an index match or a selector match. > I was trying to emulate the get/del. There if p->index is specified it trumps the selector as a search key. > Actually, would it be so bad to check the policy->index for the > add case? It does have a well-defined meaning there. That may not be totally unreasonable depending on what you mean by "well defined meaning" ;-> If we want to ensure that theres a uniqueness of indices, then it makes sense. i.e noone should be able to add either a selector or index which match what already is in the SPD (per direction and probably ifindex). Is that what you mean? cheers, jamal --=-vLEVTr45h8CK2KiIrX87 Content-Disposition: attachment; filename=polid_p2 Content-Type: text/plain; name=polid_p2; charset=utf-8 Content-Transfer-Encoding: 7bit --- a/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ b/net/xfrm/xfrm_policy.c 2005/04/28 01:22:42 @@ -345,7 +345,10 @@ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { + if (!delpol && + ((!excl && policy->index && + (policy->index == pol->index)) || + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { if (excl) { write_unlock_bh(&xfrm_policy_lock); return -EEXIST; @@ -370,7 +373,9 @@ policy->next = *p; *p = policy; atomic_inc(&flow_cache_genid); - policy->index = delpol ? delpol->index : xfrm_gen_index(dir); + if (!policy->index) + policy->index = delpol ? delpol->index : xfrm_gen_index(dir); + policy->curlft.add_time = (unsigned long)xtime.tv_sec; policy->curlft.use_time = 0; if (!mod_timer(&policy->timer, jiffies + HZ)) --=-vLEVTr45h8CK2KiIrX87-- From herbert@gondor.apana.org.au Wed Apr 27 18:48:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:48:35 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1mP1O029756 for ; Wed, 27 Apr 2005 18:48:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQy8Z-0003zX-00; Thu, 28 Apr 2005 11:48:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQy8Y-00061e-00; Thu, 28 Apr 2005 11:48:18 +1000 Date: Thu, 28 Apr 2005 11:48:18 +1000 To: jamal Cc: netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428014818.GA23148@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <1114652680.7663.31.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114652680.7663.31.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 852 Lines: 21 On Wed, Apr 27, 2005 at 09:44:40PM -0400, jamal wrote: > > > I see. In that case you want to change your expression above > > so that the memcmp is never done if excl is off and the index > > is non-zero. > > Hrm. Thinking... So you want to exclude the selector check if someone > updating ever specified the index? That may change things a little, no? > Give me a clever expression. Please see my last email. To do index updates correctly we'll need to modify the current code so that it is able to delete two existing policies. We may have two existing policies if one matches the index while the other matches the selector. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 18:52:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 18:52:28 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1qO1O030402 for ; Wed, 27 Apr 2005 18:52:26 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQyCZ-0007of-5v for netdev@oss.sgi.com; Wed, 27 Apr 2005 21:52:27 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQyCW-0005Mf-3P; Wed, 27 Apr 2005 21:52:24 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <20050428013014.GA23043@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 21:52:20 -0400 Message-Id: <1114653140.7663.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 292 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: 1970 Lines: 52 On Thu, 2005-28-04 at 11:30 +1000, Herbert Xu wrote: > On Thu, Apr 28, 2005 at 11:21:35AM +1000, herbert wrote: > > > > I see. In that case you want to change your expression above > > so that the memcmp is never done if excl is off and the index > > is non-zero. Otherwise this will result in non-deterministic > > behaviour as the result will change depending on whether the > > first hit is an index match or a selector match. > > Sorry, the index match needs more work. We need to maintain > these invariants: > > 1) There is only one policy with a given selector. > 2) There is only one policy with a given index. > > So to allow matching by index when updating, we need to deal > with the possibility of having to delete two existing policies. > The current code simply can't deal with that. > Well, while snooping i was bothered as well. I am not sure i agree with your #1 above ;-> 1) It would seem to me that the priority field is to be used as a ambiguity resolver (thats what a gazillion other classification schemes do). Lets take an example of an add: If i specify a priority and a selector matches when doing an add, then the priority being different should allow me to add the rule even if the selectors match. Current behavior: We dont allow entering multiple selectors with the same value even if i specify a different prio. 2) index really oughta be unique across the SPD. Current behavior: I can add several new rules with the same index. I realize what i am asking in #2 is the opposite of what i ask for in #1 - the big unresolved question is: if both selector and index are going to be keys to manipulating the SPD, then their behavior needs to be consistent with each other. I really like to see the index being unique, but the selector being priority disambiguated. > So if we're going to do this we'll need a bigger patch :) Lets agree on the principles first ;-> The patch i sent maintains the status quo. cheers, jamal From hadi@cyberus.ca Wed Apr 27 19:00:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:00:01 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S1xx1O031085 for ; Wed, 27 Apr 2005 18:59:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DQyJm-0007N4-6b for netdev@oss.sgi.com; Wed, 27 Apr 2005 19:59:54 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQyJq-0006Zf-Mr; Wed, 27 Apr 2005 21:59:58 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com In-Reply-To: <20050428014818.GA23148@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <1114652680.7663.31.camel@localhost.localdomain> <20050428014818.GA23148@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 21:59:54 -0400 Message-Id: <1114653595.7663.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 293 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: 1241 Lines: 35 On Thu, 2005-28-04 at 11:48 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 09:44:40PM -0400, jamal wrote: > > > > > I see. In that case you want to change your expression above > > > so that the memcmp is never done if excl is off and the index > > > is non-zero. > > > > Hrm. Thinking... So you want to exclude the selector check if someone > > updating ever specified the index? That may change things a little, no? > > Give me a clever expression. > > Please see my last email. And you my other email ;-> > To do index updates correctly we'll need > to modify the current code so that it is able to delete two existing > policies. We may have two existing policies if one matches the index > while the other matches the selector. > i think if we say index is unique per direction then lets settle in rejecting adds which try to reinsert the same index. So theres no ambiguity in deleting by index. Not specifying the index means one which is unique is generated by the kernel. Specifying x rules with exact same selector in absence of a index i believe should be allowed. There the disambiguation in add is via the priority. Deleting of such entries should be per first seen i.e highest priority. Thoughts? cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 19:08:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:08:12 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2841O031738 for ; Wed, 27 Apr 2005 19:08:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQyRZ-00045o-00; Thu, 28 Apr 2005 12:07:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQyRW-00064U-00; Thu, 28 Apr 2005 12:07:54 +1000 Date: Thu, 28 Apr 2005 12:07:54 +1000 To: jamal Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: patch: policy update by id Message-ID: <20050428020754.GA23326@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114653140.7663.36.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1055 Lines: 32 On Wed, Apr 27, 2005 at 09:52:20PM -0400, jamal wrote: > > > 1) There is only one policy with a given selector. > > 2) There is only one policy with a given index. > > Well, while snooping i was bothered as well. I am not sure i agree with > your #1 above ;-> > > 1) It would seem to me that the priority field is to be used > as a ambiguity resolver (thats what a gazillion other classification > schemes do). You know what, I actually agree with you :) But you'll need to convince Dave: http://www.uwsg.iu.edu/hypermail/linux/net/0305.3/0018.html However, this doesn't change the fact that you may need to delete two policies. > 2) index really oughta be unique across the SPD. > Current behavior: I can add several new rules with the same index. Not really. The kernel ignores the index supplied when you're adding them. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 19:11:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:11:35 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2BT1O032496 for ; Wed, 27 Apr 2005 19:11:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DQyV4-0001nH-3U for netdev@oss.sgi.com; Wed, 27 Apr 2005 22:11:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQyUy-0008EA-Ob; Wed, 27 Apr 2005 22:11:29 -0400 Subject: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-yb9JkUB3JzVPV1nxlh3i" Organization: unknown Date: Wed, 27 Apr 2005 22:11:24 -0400 Message-Id: <1114654284.7663.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 295 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: 827 Lines: 31 --=-yb9JkUB3JzVPV1nxlh3i Content-Type: text/plain Content-Transfer-Encoding: 7bit This is definetely a bug. It doesnt seem like get/del by index worked. For some reason i thought i tested this before and it worked. cheers, jamal --=-yb9JkUB3JzVPV1nxlh3i Content-Disposition: attachment; filename=polid_p3 Content-Type: text/plain; name=polid_p3; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/net/xfrm/xfrm_policy.c 2005/04/27 15:35:50 1.2 +++ b/net/xfrm/xfrm_policy.c 2005/04/27 20:23:07 @@ -417,7 +417,7 @@ struct xfrm_policy *pol, **p; write_lock_bh(&xfrm_policy_lock); - for (p = &xfrm_policy_list[id & 7]; (pol=*p)!=NULL; p = &pol->next) { + for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL; p = &pol->next) { if (pol->index == id) { xfrm_pol_hold(pol); if (delete) --=-yb9JkUB3JzVPV1nxlh3i-- From herbert@gondor.apana.org.au Wed Apr 27 19:14:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:14:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2Ec1O000804 for ; Wed, 27 Apr 2005 19:14:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQyXr-000497-00; Thu, 28 Apr 2005 12:14:27 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQyXq-00065t-00; Thu, 28 Apr 2005 12:14:26 +1000 Date: Thu, 28 Apr 2005 12:14:26 +1000 To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch2: del/get byid Message-ID: <20050428021426.GA23415@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114654284.7663.50.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 467 Lines: 13 On Wed, Apr 27, 2005 at 10:11:24PM -0400, jamal wrote: > > This is definetely a bug. It doesnt seem like get/del by index worked. > For some reason i thought i tested this before and it worked. Why is this a bug? Have you checked xfrm_gen_index? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 19:20:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:20:41 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2Kb1O001763 for ; Wed, 27 Apr 2005 19:20:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DQydk-0002kL-B8 for netdev@oss.sgi.com; Wed, 27 Apr 2005 20:20:32 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQydo-0001JK-8j; Wed, 27 Apr 2005 22:20:36 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050428020754.GA23326@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 22:20:32 -0400 Message-Id: <1114654832.7663.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 297 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: 747 Lines: 27 On Thu, 2005-28-04 at 12:07 +1000, Herbert Xu wrote: > You know what, I actually agree with you :) But you'll need to convince > Dave: > > http://www.uwsg.iu.edu/hypermail/linux/net/0305.3/0018.html > > However, this doesn't change the fact that you may need to delete > two policies. > It certainly may be simpler to just allow no more than selector. It reduces the value of priorities to be resolving ambiguities between matches perhaps with overlapping areas by prefix lengths. > > 2) index really oughta be unique across the SPD. > > Current behavior: I can add several new rules with the same index. > > Not really. The kernel ignores the index supplied when you're > adding them. > Whats the point of index then? cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 19:22:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:22:35 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2MT1O002288 for ; Wed, 27 Apr 2005 19:22:29 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQyfT-0004CN-00; Thu, 28 Apr 2005 12:22:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQyfQ-00067V-00; Thu, 28 Apr 2005 12:22:16 +1000 Date: Thu, 28 Apr 2005 12:22:16 +1000 To: jamal Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: patch: policy update by id Message-ID: <20050428022215.GA23517@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <1114654832.7663.56.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114654832.7663.56.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 603 Lines: 18 On Wed, Apr 27, 2005 at 10:20:32PM -0400, jamal wrote: > > > > 2) index really oughta be unique across the SPD. > > > Current behavior: I can add several new rules with the same index. > > > > Not really. The kernel ignores the index supplied when you're > > adding them. > > Whats the point of index then? So that you can delete policies without specifying the whole selector. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 19:23:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:23:40 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2Nc1O002529 for ; Wed, 27 Apr 2005 19:23:38 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DQygf-0007dH-BF for netdev@oss.sgi.com; Wed, 27 Apr 2005 20:23:33 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQygk-0001t5-5N; Wed, 27 Apr 2005 22:23:38 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050428021426.GA23415@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 22:23:34 -0400 Message-Id: <1114655014.7663.61.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 299 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: 555 Lines: 20 On Thu, 2005-28-04 at 12:14 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 10:11:24PM -0400, jamal wrote: > > > > This is definetely a bug. It doesnt seem like get/del by index worked. > > For some reason i thought i tested this before and it worked. > > Why is this a bug? well, i think it is a bug that indices are being ignored by the kernel. To demonstrate: Add a rule with index 100; now try to delete or get by index. > Have you checked xfrm_gen_index? I think that should be fine to use if the kernel specifies the index. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 19:26:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:26:04 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2Px1O003423 for ; Wed, 27 Apr 2005 19:26:00 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQyis-0004Ex-00; Thu, 28 Apr 2005 12:25:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQyir-00068G-00; Thu, 28 Apr 2005 12:25:49 +1000 Date: Thu, 28 Apr 2005 12:25:49 +1000 To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch2: del/get byid Message-ID: <20050428022549.GA23556@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114655014.7663.61.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 591 Lines: 17 On Wed, Apr 27, 2005 at 10:23:34PM -0400, jamal wrote: > > well, i think it is a bug that indices are being ignored by the kernel. > To demonstrate: > Add a rule with index 100; > now try to delete or get by index. But your patch has nothing to do with this. You were changing id & 7 to dir. Because the lower bits of index is set from the direction, this is a no-op. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 19:30:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:30:06 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2U41O004109 for ; Wed, 27 Apr 2005 19:30:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DQymt-0006VH-4G for netdev@oss.sgi.com; Wed, 27 Apr 2005 20:29:59 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQymx-0002pu-V9; Wed, 27 Apr 2005 22:30:04 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050428022215.GA23517@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <1114654832.7663.56.camel@localhost.localdomain> <20050428022215.GA23517@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 22:29:59 -0400 Message-Id: <1114655399.7663.67.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 301 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: 548 Lines: 18 On Thu, 2005-28-04 at 12:22 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 10:20:32PM -0400, jamal wrote: > > Whats the point of index then? > > So that you can delete policies without specifying the whole selector. > Thats fine - same with get by index. But if i am managing the policies I should be able to specify the indices of choice. The kernel should assign me one when i dont define an index. It should also reject what i pass if it the index is already in use. This is a very standard scheme for managing tables. cheers, jamal From hadi@cyberus.ca Wed Apr 27 19:39:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:39:47 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2dj1O004800 for ; Wed, 27 Apr 2005 19:39:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQywN-0003tu-Ta for netdev@oss.sgi.com; Wed, 27 Apr 2005 22:39:47 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQywK-0004Jl-5h; Wed, 27 Apr 2005 22:39:44 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050428022549.GA23556@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 22:39:40 -0400 Message-Id: <1114655980.7663.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 302 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: 1402 Lines: 44 On Thu, 2005-28-04 at 12:25 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 10:23:34PM -0400, jamal wrote: > > > > well, i think it is a bug that indices are being ignored by the kernel. > > To demonstrate: > > Add a rule with index 100; > > now try to delete or get by index. > > But your patch has nothing to do with this. You were changing > id & 7 to dir. Because the lower bits of index is set from the > direction, this is a no-op. The patch allows to walk all policies in the direction until a match to the index is found. It removes the assumption that theres a formula to compute indices (which is fine if used by the kernel when I specify no index). ------------ jdev10:~# ip x policy add dir in index 102 priority 10 src 11.0.0.10 dst 11.0.0.2 jdev10:~# ip x p get dir in index 102 src 11.0.0.10/32 dst 11.0.0.2/32 dir in priority 10 jdev10:~# ip -s x p ls src 11.0.0.10/32 dst 11.0.0.2/32 uid 0 dir in action allow index 102 priority 10 share any flag 0x00000000 lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2005-04-28 02:45:10 use - ----- That would never work without those two patches. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 19:43:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:43:11 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2h51O005400 for ; Wed, 27 Apr 2005 19:43:06 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQyzP-0004KE-00; Thu, 28 Apr 2005 12:42:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQyzN-0006AS-00; Thu, 28 Apr 2005 12:42:53 +1000 Date: Thu, 28 Apr 2005 12:42:53 +1000 To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch2: del/get byid Message-ID: <20050428024253.GA23695@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114655980.7663.76.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 491 Lines: 12 On Wed, Apr 27, 2005 at 10:39:40PM -0400, jamal wrote: > > That would never work without those two patches. Sorry, but you've just broken the policy timer. This is the other use of index. It's a sneaky way of carrying around dir in the policy without actually specifying it :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Wed Apr 27 19:53:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:53:11 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2r91O006182 for ; Wed, 27 Apr 2005 19:53:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DQz0O-0004iW-00; Wed, 27 Apr 2005 19:43:56 -0700 Date: Wed, 27 Apr 2005 19:43:56 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-Id: <20050427194356.58a3e618.davem@davemloft.net> In-Reply-To: <20050428020754.GA23326@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 468 Lines: 12 On Thu, 28 Apr 2005 12:07:54 +1000 Herbert Xu wrote: > You know what, I actually agree with you :) But you'll need to convince > Dave: > > http://www.uwsg.iu.edu/hypermail/linux/net/0305.3/0018.html I'm willing to reneg on that position if you can convince me that security minded folks won't be surprised by this pseudo- aliasing. For example, do firewall systems tend to support such priority schemes? If so, I guess we can do it. From hadi@cyberus.ca Wed Apr 27 19:55:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:55:41 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2tb1O006709 for ; Wed, 27 Apr 2005 19:55:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQzBk-0004vz-Jt for netdev@oss.sgi.com; Wed, 27 Apr 2005 22:55:40 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQzBg-0006u1-CD; Wed, 27 Apr 2005 22:55:36 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050428024253.GA23695@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 22:55:32 -0400 Message-Id: <1114656932.7663.88.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 305 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: 510 Lines: 17 On Thu, 2005-28-04 at 12:42 +1000, Herbert Xu wrote: > On Wed, Apr 27, 2005 at 10:39:40PM -0400, jamal wrote: > > > > That would never work without those two patches. > > Sorry, but you've just broken the policy timer. This is the > other use of index. It's a sneaky way of carrying around dir > in the policy without actually specifying it :) Dang ;-> Thats some abuse ;-> It would probably be easy to steal 2 bits off the flags instead, no? Its not like they are being highly utilized. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 19:56:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 19:57:03 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S2uv1O007111 for ; Wed, 27 Apr 2005 19:56:57 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQzCn-0004RJ-00; Thu, 28 Apr 2005 12:56:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQzCm-0006Co-00; Thu, 28 Apr 2005 12:56:44 +1000 Date: Thu, 28 Apr 2005 12:56:44 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428025644.GA23823@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427194356.58a3e618.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 999 Lines: 23 On Wed, Apr 27, 2005 at 07:43:56PM -0700, David S. Miller wrote: > > I'm willing to reneg on that position if you can convince me > that security minded folks won't be surprised by this pseudo- > aliasing. For example, do firewall systems tend to support > such priority schemes? If so, I guess we can do it. Well netfilter certainly follows this scheme: $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT $ iptables -v -L INPUT -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Wed Apr 27 20:03:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:04:23 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S33v1O008309 for ; Wed, 27 Apr 2005 20:03:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQzJb-0004T9-00; Thu, 28 Apr 2005 13:03:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQzJF-0006DR-00; Thu, 28 Apr 2005 13:03:25 +1000 Date: Thu, 28 Apr 2005 13:03:25 +1000 To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com, Alexey Kuznetsov Subject: Re: patch2: del/get byid Message-ID: <20050428030325.GB23823@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> <1114656932.7663.88.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114656932.7663.88.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 732 Lines: 22 On Wed, Apr 27, 2005 at 10:55:32PM -0400, jamal wrote: > > Dang ;-> Thats some abuse ;-> Indeed, looks like it was my code too :) > It would probably be easy to steal 2 bits off the flags instead, no? Or we can simply put it in a field called dir and start using it instead of passing it around :) With respect to the user specifying the index when adding policies, I think we should check with Alexey. He added the original code to do this so maybe there was a problem with KAME that makes this necessary. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Wed Apr 27 20:09:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:09:40 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S39c1O008907 for ; Wed, 27 Apr 2005 20:09:38 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DQzPL-0002ib-VZ for netdev@oss.sgi.com; Wed, 27 Apr 2005 23:09:43 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQzPG-0001Uw-7X; Wed, 27 Apr 2005 23:09:38 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <20050427194356.58a3e618.davem@davemloft.net> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 23:09:34 -0400 Message-Id: <1114657774.7663.100.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 308 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: 1057 Lines: 31 On Wed, 2005-27-04 at 19:43 -0700, David S. Miller wrote: > On Thu, 28 Apr 2005 12:07:54 +1000 > Herbert Xu wrote: > > > You know what, I actually agree with you :) But you'll need to convince > > Dave: > > > > http://www.uwsg.iu.edu/hypermail/linux/net/0305.3/0018.html > > I'm willing to reneg on that position if you can convince me > that security minded folks won't be surprised by this pseudo- > aliasing. For example, do firewall systems tend to support > such priority schemes? If so, I guess we can do it. Well, the tc classifiers are a good example. Priorities are used as ambiguity resolvers. After reading that URL though i think either way would be fine .. rule1: reject ipsrc A/32 ipdst B/32 with different priorities if entered more than once; ** but we allow the second rule ipsrc A/24 ipdst B/24 - only thing would probably be useful to add is ensure a different priority is used. This may be a little involved. BTW, a weird ambiguity resolver is iptables - it just prepends rules. cheers, jamal From hadi@cyberus.ca Wed Apr 27 20:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:16:11 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S3G51O009785 for ; Wed, 27 Apr 2005 20:16:05 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DQzVX-0002xo-Mv for netdev@oss.sgi.com; Wed, 27 Apr 2005 23:16:07 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQzVU-0002Bi-TM; Wed, 27 Apr 2005 23:16:05 -0400 Subject: Re: patch: policy update by id From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050428025644.GA23823@gondor.apana.org.au> References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> <20050428025644.GA23823@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 23:16:00 -0400 Message-Id: <1114658160.7663.102.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 309 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: 642 Lines: 20 On Thu, 2005-28-04 at 12:56 +1000, Herbert Xu wrote: > Well netfilter certainly follows this scheme: > > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > $ iptables -v -L INPUT -n > Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source destination > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > Which is bizare to say the least. If you delete, only the first one gets deleted. cheers, jamal From herbert@gondor.apana.org.au Wed Apr 27 20:20:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:21:03 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S3Kw1O014042 for ; Wed, 27 Apr 2005 20:20:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DQza4-0004YQ-00; Thu, 28 Apr 2005 13:20:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DQza1-0006GU-00; Thu, 28 Apr 2005 13:20:45 +1000 Date: Thu, 28 Apr 2005 13:20:45 +1000 To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428032045.GA24041@gondor.apana.org.au> References: <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> <20050428025644.GA23823@gondor.apana.org.au> <1114658160.7663.102.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114658160.7663.102.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1069 Lines: 25 On Wed, Apr 27, 2005 at 11:16:00PM -0400, jamal wrote: > On Thu, 2005-28-04 at 12:56 +1000, Herbert Xu wrote: > > > Well netfilter certainly follows this scheme: > > > > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > > $ iptables -v -L INPUT -n > > Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > > pkts bytes target prot opt in out source destination > > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > > Which is bizare to say the least. If you delete, only the first one gets > deleted. It isn't that strange. It's also done using indices except that the indices aren't fixed. Do delete the second rule you would say iptables -D INPUT 2 -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mcmanus@ducksong.com Wed Apr 27 20:22:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:22:53 -0700 (PDT) Received: from adsl.ducksong.com (pool-70-19-141-94.bos.east.verizon.net [70.19.141.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S3Mn1O014764 for ; Wed, 27 Apr 2005 20:22:50 -0700 Received: from [192.168.100.2] (book.gruel.limey.net [192.168.100.2]) by adsl.ducksong.com (8.12.10/8.12.9) with ESMTP id j3S3MkA6015832 for ; Wed, 27 Apr 2005 23:22:47 -0400 Subject: Re: how to suppress link local addresses From: Patrick McManus To: "netdev@oss.sgi.com" In-Reply-To: <1114626832.12304.97.camel@mcmanus.datapower.com> References: <1114626832.12304.97.camel@mcmanus.datapower.com> Content-Type: text/plain Date: Wed, 27 Apr 2005 23:22:46 -0400 Message-Id: <1114658566.4833.9.camel@book.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcmanus@ducksong.com Precedence: bulk X-list: netdev Content-Length: 2328 Lines: 58 On Wed, 2005-04-27 at 14:33 -0400, patrick mcmanus wrote: > I've got a 2.6.12-rc2 kernel with IPv6 compiled in monolithically. > using it on several different boxes and would like them all to run the > same kernel. Most of the boxes have IPv6 connectivity and are working > fine.. however one of them is on an IPv4 only net. > > When I bring up an IPv4 interface on that box it also gets an automagic > ipv6 link-local address as a bonus. I would like to prevent that from > happening if possible.. I had thought that the conf/*/autoconf sysctl > should do that for me, but I couldn't get it to work (see my > illustration below). I'm not certain if that's a bug or I just don't > understand what that is supposed to do. It turns out other folks have been here before (isn't that always the way?): http://marc.theaimsgroup.com/?l=linux-kernel&m=108725654111368&w=2 http://www.uwsg.iu.edu/hypermail/linux/net/0406.1/0065.html The conventional wisdom then seemed to be "don't load IPv6" or "fix the userspace app". That strikes me as kind of unsatisfying, it feels like this should be the sort of thing that is doable by runtime config. But who am I to argue? I was just fooled by some bad documentation floating around out there in an (old?) IPv6 on Linux faq on the what the autoconf sysctl was supposed to do - the state of external documentation certainly isn't a kernel issue. For the sake of future googlers I'll include the primitive patch I am now using locally. Index: net/ipv6/addrconf.c =================================================================== --- 3608de2fc88b062070a9d197eda9cac1fb9635d3/net/ipv6/addrconf.c (mode:100644 sha1:7196ac2f2d1688d410e2f51973f90c0118549c63) +++ uncommitted/net/ipv6/addrconf.c (mode:100664) @@ -1855,6 +1855,9 @@ printk(KERN_DEBUG "init loopback: add_dev failed\n"); return; } + + if (idev->cnf.autoconf == 0) + return; ifp = ipv6_add_addr(idev, &in6addr_loopback, 128, IFA_HOST, IFA_F_PERMANENT); if (!IS_ERR(ifp)) { @@ -1894,9 +1897,10 @@ } idev = addrconf_add_dev(dev); - if (idev == NULL) + if ((idev == NULL) || (idev->cnf.autoconf == 0)) return; + memset(&addr, 0, sizeof(struct in6_addr)); addr.s6_addr32[0] = htonl(0xFE800000); From hadi@cyberus.ca Wed Apr 27 20:25:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Apr 2005 20:25:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3S3P31O015420 for ; Wed, 27 Apr 2005 20:25:03 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DQzeE-0004C5-5R for netdev@oss.sgi.com; Wed, 27 Apr 2005 23:25:06 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DQzdV-00030h-M4; Wed, 27 Apr 2005 23:24:21 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com, Alexey Kuznetsov In-Reply-To: <20050428030325.GB23823@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> <1114656932.7663.88.camel@localhost.localdomain> <20050428030325.GB23823@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Wed, 27 Apr 2005 23:24:17 -0400 Message-Id: <1114658657.7663.110.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 312 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: 544 Lines: 20 On Thu, 2005-28-04 at 13:03 +1000, Herbert Xu wrote: > Or we can simply put it in a field called dir and start using it > instead of passing it around :) > that would be the best option. > With respect to the user specifying the index when adding policies, > I think we should check with Alexey. He added the original code to > do this so maybe there was a problem with KAME that makes this > necessary. > Agreed. Alexey, thread of interest on netdev, this one as well as other with subject "patch: policy update by id" cheers, jamal From b@blackham.com.au Thu Apr 28 03:35:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 03:35:05 -0700 (PDT) Received: from oracle.bridgewayconsulting.com.au (oracle.bridgewayconsulting.com.au [203.56.14.38]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SAYx1O001216 for ; Thu, 28 Apr 2005 03:35:00 -0700 Received: from amidala (blackb02.student.dialup.uwa.edu.au [130.95.115.75]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by oracle.bridgewayconsulting.com.au (Postfix) with ESMTP id C55601F8002; Thu, 28 Apr 2005 18:34:51 +0800 (WST) Received: by amidala (Postfix, from userid 1000) id 495B8B04F6; Thu, 28 Apr 2005 18:34:51 +0800 (WST) Date: Thu, 28 Apr 2005 18:34:51 +0800 From: Bernard Blackham To: netdev@oss.sgi.com Cc: Werner Almesberger Subject: Non-blocking sockets, connect(), and socket states Message-ID: <20050428103451.GG4798@blackham.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Dagobah Systems User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernard@blackham.com.au Precedence: bulk X-list: netdev Content-Length: 1334 Lines: 34 Hi, Through playing with tcpcp[1], I've found out about a quirk in the kernel's handling of non-blocking connection-based sockets. The sk_socket->state value can take on one of SS_FREE, SS_UNCONNECTED, SS_CONNECTING, SS_CONNECTED or SS_DISCONNECTING. On a standard *blocking*, connection-oriented socket (eg, TCP), after connect() returns, sk_socket->state will be SS_CONNECTED. However, if the socket is placed into non-blocking mode before the connect() call, connect() returns immediately with EINPROGRESS, and the sk_socket->state is set to SS_CONNECTING. When the socket finally does connect, the application is notified via poll(), but the state remains as SS_CONNECTING (which causes issues for tcpcp, though doesn't appear to have any other externally visible implications). Werner, the author of tcpcp, suggests that the application should call connect() on the socket a second time, after the successful connection, to force the sk_socket->state value to SS_CONNECTED. Should it be the kernel's responsibility to set SS_CONNECTED when the connection is established? Or should I go file bugs and submit patches on all the applications that use non-blocking sockets and don't call connect() a second time? Thanks in advance, Bernard. [1] http://tcpcp.sf.net/ -- Bernard Blackham From tgraf@suug.ch Thu Apr 28 04:42:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 04:43:03 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SBgw1O009806 for ; Thu, 28 Apr 2005 04:42:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id DE9CA1C0ED; Thu, 28 Apr 2005 13:43:08 +0200 (CEST) Date: Thu, 28 Apr 2005 13:43:08 +0200 From: Thomas Graf To: Herbert Xu Cc: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428114308.GX577@postel.suug.ch> References: <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> <20050428025644.GA23823@gondor.apana.org.au> <1114658160.7663.102.camel@localhost.localdomain> <20050428032045.GA24041@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428032045.GA24041@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1166 Lines: 25 * Herbert Xu <20050428032045.GA24041@gondor.apana.org.au> 2005-04-28 13:20 > On Wed, Apr 27, 2005 at 11:16:00PM -0400, jamal wrote: > > On Thu, 2005-28-04 at 12:56 +1000, Herbert Xu wrote: > > > > > Well netfilter certainly follows this scheme: > > > > > > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > > > $ iptables -I INPUT -s 3.3.3.3 -d 4.4.4.4 -j ACCEPT > > > $ iptables -v -L INPUT -n > > > Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > > > pkts bytes target prot opt in out source destination > > > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > > > 0 0 ACCEPT all -- * * 3.3.3.3 4.4.4.4 > > > > Which is bizare to say the least. If you delete, only the first one gets > > deleted. > > It isn't that strange. It's also done using indices except that the > indices aren't fixed. Do delete the second rule you would say > > iptables -D INPUT 2 Except for when another iptables instance has modified the ordering of the rules by inserting or deleting a rule in the meantime. Please do not adopt this scheme, it's completely unreliable. From kaber@trash.net Thu Apr 28 05:10:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 05:10:42 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SCAc1O011035 for ; Thu, 28 Apr 2005 05:10:39 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DR7pu-00075S-ID; Thu, 28 Apr 2005 14:09:42 +0200 Message-ID: <4270D286.7060301@trash.net> Date: Thu, 28 Apr 2005 14:09:42 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Herbert Xu , jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: policy update by id References: <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> <20050428025644.GA23823@gondor.apana.org.au> <1114658160.7663.102.camel@localhost.localdomain> <20050428032045.GA24041@gondor.apana.org.au> <20050428114308.GX577@postel.suug.ch> In-Reply-To: <20050428114308.GX577@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 411 Lines: 13 Thomas Graf wrote: > * Herbert Xu <20050428032045.GA24041@gondor.apana.org.au> 2005-04-28 13:20 > >>iptables -D INPUT 2 > > Except for when another iptables instance has modified the ordering of > the rules by inserting or deleting a rule in the meantime. Please do > not adopt this scheme, it's completely unreliable. Yes, if you don't know the ordering of your ruleset it is unreliable :) Regards Patrick From tgraf@suug.ch Thu Apr 28 05:32:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 05:32:57 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SCWq1O012525 for ; Thu, 28 Apr 2005 05:32:53 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D0D041C0ED; Thu, 28 Apr 2005 14:33:10 +0200 (CEST) Date: Thu, 28 Apr 2005 14:33:10 +0200 From: Thomas Graf To: Patrick McHardy Cc: Herbert Xu , jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: policy update by id Message-ID: <20050428123310.GY577@postel.suug.ch> References: <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au> <1114653140.7663.36.camel@localhost.localdomain> <20050428020754.GA23326@gondor.apana.org.au> <20050427194356.58a3e618.davem@davemloft.net> <20050428025644.GA23823@gondor.apana.org.au> <1114658160.7663.102.camel@localhost.localdomain> <20050428032045.GA24041@gondor.apana.org.au> <20050428114308.GX577@postel.suug.ch> <4270D286.7060301@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4270D286.7060301@trash.net> X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1163 Lines: 22 * Patrick McHardy <4270D286.7060301@trash.net> 2005-04-28 14:09 > Thomas Graf wrote: > >* Herbert Xu <20050428032045.GA24041@gondor.apana.org.au> 2005-04-28 13:20 > > > >>iptables -D INPUT 2 > > > >Except for when another iptables instance has modified the ordering of > >the rules by inserting or deleting a rule in the meantime. Please do > >not adopt this scheme, it's completely unreliable. > > Yes, if you don't know the ordering of your ruleset it is unreliable :) Even if you know the ordering, the knowledge may expire very fast. It's getting more and more common to automate the insertion and deletion of rules via scripts triggered by events. I'm more or less fine with this choice but it's nowhere near an index but rather just a line based offset. I've seen user interfaces relying on -D, guess what happens if more than one person uses the interface. It wouldn't cost much to introduce a 64bit generated identifier and return that it userspace but it would give higher level applications a chance to reidentify rules, safely delete a certain rule, and would probably speed up the deletion of a single rule out of a rather big ruleset considerably. From steven_elias@ml.com Thu Apr 28 05:52:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 05:52:28 -0700 (PDT) Received: from mlnya405er.ml.com (mlnya405er.ml.com [199.43.38.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SCqP1O013711 for ; Thu, 28 Apr 2005 05:52:25 -0700 Received: from MLNYA354BH.amrs.win.ml.com (unknown [146.125.98.4]) by mlnya405er.ml.com (Postfix) with ESMTP id 79B54120006EB; Thu, 28 Apr 2005 08:52:19 -0400 (EDT) Received: from mlnya301bh.amrs.win.ml.com ([146.125.109.51]) by MLNYA354BH.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Apr 2005 08:52:01 -0400 Received: from mlnyb705mb.amrs.win.ml.com ([146.125.92.5]) by mlnya301bh.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Apr 2005 08:52:01 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: list admin? unsubscribing from the list? Date: Thu, 28 Apr 2005 08:52:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: list admin? unsubscribing from the list? thread-index: AcVLhCCy8l06m465Q72VFjGv3M3/RgAbNQVg X-Priority: 1 Priority: Urgent Importance: high From: "Elias, Steven (TD&DS, Applications Infrastructure Svcs.)" To: "Bernd Schubert" Cc: X-OriginalArrivalTime: 28 Apr 2005 12:52:01.0463 (UTC) FILETIME=[12359470:01C54BF1] X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3SCqP1O013711 X-archive-position: 323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steven_elias@ml.com Precedence: bulk X-list: netdev Content-Length: 1437 Lines: 44 Please remove me from the list as well - the same issue is occurring Thanks - and confirm Stephen Elias AOL IM: SELIAS5431 -----Original Message----- From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Bernd Schubert Sent: Wednesday, April 27, 2005 7:51 PM To: Ralf Baechle Cc: netdev@oss.sgi.com Subject: Re: list admin? unsubscribing from the list? On Wednesday 27 April 2005 19:08, Ralf Baechle wrote: > On Wed, Apr 27, 2005 at 04:47:25PM +0200, Bernd Schubert wrote: > > several month ago I subscribed to this list and about two moth ago I > > unsubscribed again. > > About two weeks ago I receiced mail from the list, after unsubscribing > > again this stopped. Today I'm again receiving mail from the list, but > > unsubscribing fails: > > A funny little accident due to oss recently having changed hardware twice > after the old machine died - with some chaos following. I fixed up the > subscriber lists, so you should no longer receive email. Things should > to run smoothly now. Thanks a lot! Bernd -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- From hadi@cyberus.ca Thu Apr 28 07:20:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 07:20:56 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SEKj1O007624 for ; Thu, 28 Apr 2005 07:20:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DR9si-0002XM-Bv for netdev@oss.sgi.com; Thu, 28 Apr 2005 10:20:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DR9sb-0005OS-8i; Thu, 28 Apr 2005 10:20:37 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Alexey Kuznetsov , netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <1114658657.7663.110.camel@localhost.localdomain> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> <1114656932.7663.88.camel@localhost.localdomain> <20050428030325.GB23823@gondor.apana.org.au> <1114658657.7663.110.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-DDdKt4BejgU2c4VMw0+4" Organization: unknown Date: Thu, 28 Apr 2005 10:20:33 -0400 Message-Id: <1114698033.7663.197.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 325 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: 2787 Lines: 93 --=-DDdKt4BejgU2c4VMw0+4 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-27-04 at 23:24 -0400, jamal wrote: > On Thu, 2005-28-04 at 13:03 +1000, Herbert Xu wrote: > > > Or we can simply put it in a field called dir and start using it > > instead of passing it around :) > > > > that would be the best option. Well, heres some minimalist patch i havent tested. i.e doesnt change any of the functions; but at least it doesnt break the timers. This includes both patches i posted earlier and introduces dir in xfrm_policy. cheers, jamal --=-DDdKt4BejgU2c4VMw0+4 Content-Disposition: attachment; filename=polid_p4 Content-Type: text/plain; name=polid_p4; charset=utf-8 Content-Transfer-Encoding: 7bit --- a/include/net/xfrm.h 2005/04/28 14:05:00 1.1 +++ b/include/net/xfrm.h 2005/04/28 14:05:48 @@ -302,6 +302,7 @@ struct dst_entry *bundles; __u16 family; __u8 action; + __u8 dir; __u8 flags; __u8 dead; __u8 xfrm_nr; --- a/net/xfrm/xfrm_user.c 2005/04/28 13:59:27 1.1 +++ b/net/xfrm/xfrm_user.c 2005/04/28 14:01:58 @@ -653,6 +653,7 @@ memcpy(&xp->selector, &p->sel, sizeof(xp->selector)); memcpy(&xp->lft, &p->lft, sizeof(xp->lft)); xp->action = p->action; + xp->dir = p->dir; xp->flags = p->flags; xp->family = p->sel.family; /* XXX xp->share = p->share; */ --- a/net/xfrm/xfrm_policy.c 2005/04/27 11:32:13 1.1 +++ b/net/xfrm/xfrm_policy.c 2005/04/28 14:02:18 @@ -163,7 +163,7 @@ if (xp->dead) goto out; - dir = xp->index & 7; + dir = xp->dir; if (xp->lft.hard_add_expires_seconds) { long tmo = xp->lft.hard_add_expires_seconds + @@ -345,7 +345,10 @@ write_lock_bh(&xfrm_policy_lock); for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { + if (!delpol && + ((!excl && policy->index && + (policy->index == pol->index)) || + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { if (excl) { write_unlock_bh(&xfrm_policy_lock); return -EEXIST; @@ -370,7 +373,9 @@ policy->next = *p; *p = policy; atomic_inc(&flow_cache_genid); - policy->index = delpol ? delpol->index : xfrm_gen_index(dir); + if (!policy->index) + policy->index = delpol ? delpol->index : xfrm_gen_index(dir); + policy->curlft.add_time = (unsigned long)xtime.tv_sec; policy->curlft.use_time = 0; if (!mod_timer(&policy->timer, jiffies + HZ)) @@ -413,7 +418,7 @@ struct xfrm_policy *pol, **p; write_lock_bh(&xfrm_policy_lock); - for (p = &xfrm_policy_list[id & 7]; (pol=*p)!=NULL; p = &pol->next) { + for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL; p = &pol->next) { if (pol->index == id) { xfrm_pol_hold(pol); if (delete) --=-DDdKt4BejgU2c4VMw0+4-- From lxie@us.ibm.com Thu Apr 28 09:54:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 09:54:58 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SGsn1O004893; Thu, 28 Apr 2005 09:54:55 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3SGsiAa157176; Thu, 28 Apr 2005 12:54:44 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3SGsiGU235758; Thu, 28 Apr 2005 10:54:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3SGsieK004434; Thu, 28 Apr 2005 10:54:44 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.60]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3SGsiQ6004428; Thu, 28 Apr 2005 10:54:44 -0600 In-Reply-To: Subject: RE: list admin? unsubscribing from the list? To: "Bernd Schubert" , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Linda Xie Date: Thu, 28 Apr 2005 10:54:43 -0600 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 6.53HF383 | March 4, 2005) at 04/28/2005 10:54:44 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912" X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lxie@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10711 Lines: 283 --0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: multipart/alternative; Boundary="1__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912" --1__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Please remove me from netdev mailing list as well. Thank you very much. Linda Xie LTC IBM Austin, TX = "Elias, Steven = (TD&DS, To: "Bernd Schuber= t" Applications cc: Infrastructure Subject: RE: list admin= ? unsubscribing from the list? Svcs.)" = = Sent by: = netdev-bounce@oss = .sgi.com = = = 04/28/2005 07:52 = AM = = Please remove me from the list as well - the same issue is occurring Thanks - and confirm Stephen Elias AOL IM: SELIAS5431 -----Original Message----- From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Bernd Schubert Sent: Wednesday, April 27, 2005 7:51 PM To: Ralf Baechle Cc: netdev@oss.sgi.com Subject: Re: list admin? unsubscribing from the list? On Wednesday 27 April 2005 19:08, Ralf Baechle wrote: > On Wed, Apr 27, 2005 at 04:47:25PM +0200, Bernd Schubert wrote: > > several month ago I subscribed to this list and about two moth ago = I > > unsubscribed again. > > About two weeks ago I receiced mail from the list, after unsubscribing > > again this stopped. Today I'm again receiving mail from the list, but > > unsubscribing fails: > > A funny little accident due to oss recently having changed hardware twice > after the old machine died - with some chaos following. I fixed up the > subscriber lists, so you should no longer receive email. Things should > to run smoothly now. Thanks a lot! Bernd -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, ret= ain or redistribute it. Click here for important additional terms relating = to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- = --1__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Please remove me from netdev mailing list as well.

Thank you very much.

Linda Xie
LTC IBM Austin, TX


3D"Inactive"Elias, Steven (TD&DS, Applications Infrastructure= Svcs.)" <steven_elias@ml.com>




          "Elias, Steven (TD&DS, Applications In= frastructure Svcs.)" <steven_elias@ml.com>
          Sent by: netdev-bounce@oss.sgi.com

          04/28/2005 07:52 AM

3D""

To: "Bernd Schubert"= ; <bernd-schubert@gmx.de>
cc: <netdev@oss.sgi.com>= ;
Subject: RE: list admin? unsu= bscribing from the list?


Please remove me from the list as well - the same issue is occurrin= g

Thanks - and confirm

Stephen Elias
AOL IM: SELIAS5431




-----Original Message-----
From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On
Behalf Of Bernd Schubert
Sent: Wednesday, April 27, 2005 7:51 PM
To: Ralf Baechle
Cc: netdev@oss.sgi.com
Subject: Re: list admin? unsubscribing from the list?

On Wednesday 27 April 2005 19:08, Ralf Baechle wrote:
> On Wed, Apr 27, 2005 at 04:47:25PM +0200, Bernd Schubert wrote: > > several month ago I subscribed to this list and about two mot= h ago I
> > unsubscribed again.
> > About two weeks ago I receiced mail from the list, after
unsubscribing
> > again this stopped. Today I'm again receiving mail from the l= ist,
but
> > unsubscribing fails:
>
> A funny little accident due to oss recently having changed hardwar= e
twice
> after the old machine died - with some chaos following.  I fi= xed up
the
> subscriber lists, so you should no longer receive email.  Thi= ngs
should
> to run smoothly now.

Thanks a lot!

 Bernd
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, ret= ain or redistribute it. Click here for important additional terms relat= ing to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------


 = --1__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912-- --0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=08BBE562DFCF39128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=08BBE562DFCF39128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912 Content-type: image/gif; name="pic02243.gif" Content-Disposition: inline; filename="pic02243.gif" Content-ID: <30__=08BBE562DFCF39128f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=08BBE562DFCF39128f9e8a93df938690918c08BBE562DFCF3912-- From andy.grover@gmail.com Thu Apr 28 11:49:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 11:49:40 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SInZ7J017214 for ; Thu, 28 Apr 2005 11:49:36 -0700 Received: by rproxy.gmail.com with SMTP id f1so758086rne for ; Thu, 28 Apr 2005 11:49:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dSl3cXLo1fx2D4587po1/36mXfRBiSTxEs1Bw5arFYbG9BgfEWz+eONHtU9q4SWqryLr3pp8843jBYFu9KleEWXKtfanGX/aZ/76ZcnplnXqBzBvmwd8shYWms2GZsvUjmUA8pmkMnJhpSRjDpRS9hls6moWU6KDNcynkq8IeRo= Received: by 10.11.122.6 with SMTP id u6mr93467cwc; Thu, 28 Apr 2005 11:49:32 -0700 (PDT) Received: by 10.11.122.42 with HTTP; Thu, 28 Apr 2005 11:49:32 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2005 11:49:32 -0700 From: Andrew Grover Reply-To: Andrew Grover To: netdev@oss.sgi.com Subject: prequeue still a good idea? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3SInZ7J017214 X-archive-position: 327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.grover@gmail.com Precedence: bulk X-list: netdev Content-Length: 694 Lines: 18 I came across this comment from include/net/tcp.h tcp_prequeue: /* Packet is added to VJ-style prequeue for processing in process * context, if a reader task is waiting. Apparently, this exciting * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93) * failed somewhere. Latency? Burstiness? Well, at least now we will * see, why it failed. 8)8) --ANK */ I'm trying to understand -- is the prequeue really not a win, and if so, why do we still have it? Especially with modern tcp csumming HW, its benefit is not clear to me. The whole point of the prequeue, and calling tcp_v4_do_rcv from user context, was to speed up *sw* csum, right? Thanks -- Regards -- Andy From davem@davemloft.net Thu Apr 28 12:01:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:01:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJ1R7J019802 for ; Thu, 28 Apr 2005 12:01:27 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DRE7E-0002gS-00; Thu, 28 Apr 2005 11:52:00 -0700 Date: Thu, 28 Apr 2005 11:52:00 -0700 From: "David S. Miller" To: Andrew Grover Cc: netdev@oss.sgi.com Subject: Re: prequeue still a good idea? Message-Id: <20050428115200.353db06c.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1450 Lines: 33 On Thu, 28 Apr 2005 11:49:32 -0700 Andrew Grover wrote: > /* Packet is added to VJ-style prequeue for processing in process > * context, if a reader task is waiting. Apparently, this exciting > * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93) > * failed somewhere. Latency? Burstiness? Well, at least now we will > * see, why it failed. 8)8) --ANK > */ > > I'm trying to understand -- is the prequeue really not a win, and if > so, why do we still have it? > > Especially with modern tcp csumming HW, its benefit is not clear to > me. The whole point of the prequeue, and calling tcp_v4_do_rcv from > user context, was to speed up *sw* csum, right? It's not about the checksum only, it's about _scheduling_. Let's say that we can get a process to wake up every quantum X, which means that with prequeue the processes arrival rate of X onto the cpu will determine the pacing of the data sinking and thus the ACKs on the TCP connection. That is, the TCP data rate becomes paced to the rate at which the system can handle the current load. It creates a very stable system. Without prequeue, we ACK immediately. This artificially makes the sender believe that it can pump data out at that rate to the receiver. People who want ultra-low latency hate this, which is why we have a way to shut it off via sysctl so the cluster and distributed computing folks can get the behavior they want. From davem@davemloft.net Thu Apr 28 12:11:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:12:05 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJBm7J021547 for ; Thu, 28 Apr 2005 12:11:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREHN-0002ne-00; Thu, 28 Apr 2005 12:02:29 -0700 Date: Thu, 28 Apr 2005 12:02:29 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 6/6][SCTP] Fix SCTP sendbuffer accouting. Message-Id: <20050428120229.76c43c44.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 213 Lines: 8 All 6 patches applied, with the one modification that I've made per-socket accounting be the default as discussed with you in private email. Please do the same when you submit your 2.4.x patches. Thanks a lot. From davem@davemloft.net Thu Apr 28 12:13:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:13:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJDO7J022001 for ; Thu, 28 Apr 2005 12:13:24 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREIu-0002oW-00; Thu, 28 Apr 2005 12:04:04 -0700 Date: Thu, 28 Apr 2005 12:04:04 -0700 From: "David S. Miller" To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11.7] sch_htb: Drop packet when direct queue is full Message-Id: <20050428120404.190d7344.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 518 Lines: 12 On Mon, 25 Apr 2005 14:15:05 -0500 (CDT) Asim Shankar wrote: > htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is destined > for the direct_queue but the direct_queue is full. (Before patch: > Erroneously returned NET_XMIT_SUCCESS even though packet was not enqueued) > > Signed-off-by: Asim Shankar Your patch is mangled by your email client. The non-changing lines in the patch have two leading spaces, which is wrong. So the patch will not apply. From davem@davemloft.net Thu Apr 28 12:17:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:17:47 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJHi7J022905 for ; Thu, 28 Apr 2005 12:17:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREN6-0002qD-00; Thu, 28 Apr 2005 12:08:24 -0700 Date: Thu, 28 Apr 2005 12:08:24 -0700 From: "David S. Miller" To: folkert@vanheusden.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-Id: <20050428120824.6cc9b345.davem@davemloft.net> In-Reply-To: <20050425061210.GB15167@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 391 Lines: 13 On Mon, 25 Apr 2005 08:12:13 +0200 folkert@vanheusden.com wrote: > I'll resend it as an attachment (see attachment). It still has spaces where there should be tabs, even though you compressed the patch and used attachment. The diff itself must already be corrupt before you attach it. Please double check that the patch you submit actually apply, this will save me a lot of wasted time. From davem@davemloft.net Thu Apr 28 12:19:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:19:35 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJJL7J026880 for ; Thu, 28 Apr 2005 12:19:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREOd-0002qU-00; Thu, 28 Apr 2005 12:09:59 -0700 Date: Thu, 28 Apr 2005 12:09:58 -0700 From: "David S. Miller" To: Russell King Cc: netdev@oss.sgi.com Subject: Re: Badness in cache_free_debugcheck at linux/mm/slab.c:1909 Message-Id: <20050428120958.2f0ad8fd.davem@davemloft.net> In-Reply-To: <20050427150518.A15989@flint.arm.linux.org.uk> References: <20050427150518.A15989@flint.arm.linux.org.uk> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 159 Lines: 6 On Wed, 27 Apr 2005 15:05:18 +0100 Russell King wrote: > This pretty much sums up the problem: Yes, Arnaldo is looking into this bug. From davem@davemloft.net Thu Apr 28 12:21:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:21:08 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJL47J027534 for ; Thu, 28 Apr 2005 12:21:04 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREQM-0002t8-00; Thu, 28 Apr 2005 12:11:46 -0700 Date: Thu, 28 Apr 2005 12:11:46 -0700 From: "David S. Miller" To: Dave Jones Cc: netdev@oss.sgi.com Subject: Re: Incorrect permissions on route flush sysctl Message-Id: <20050428121146.7b35770b.davem@davemloft.net> In-Reply-To: <20050425161646.GA13778@redhat.com> References: <20050425160113.GA22919@redhat.com> <20050425161646.GA13778@redhat.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 440 Lines: 13 On Mon, 25 Apr 2005 12:16:46 -0400 Dave Jones wrote: > On Mon, Apr 25, 2005 at 12:01:13PM -0400, Dave Jones wrote: > > This has been brought up before.. http://lkml.org/lkml/2000/1/21/116 > > but didnt seem to get resolved. This morning I got someone > > file a bugzilla about it breaking sysctl(8). > > And here's its ipv6 counterpart. > > Signed-off-by: Dave Jones Both applied, thanks Dave. From davem@davemloft.net Thu Apr 28 12:24:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:24:17 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJO97J028407 for ; Thu, 28 Apr 2005 12:24:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DRETE-0002vP-00; Thu, 28 Apr 2005 12:14:44 -0700 Date: Thu, 28 Apr 2005 12:14:44 -0700 From: "David S. Miller" To: Thomas Graf Cc: nicolas.dichtel@6wind.com, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS Message-Id: <20050428121444.3d42fcfa.davem@davemloft.net> In-Reply-To: <20050427114216.GV577@postel.suug.ch> References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> <426F42F0.9020609@6wind.com> <20050427114216.GV577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 852 Lines: 22 On Wed, 27 Apr 2005 13:42:16 +0200 Thomas Graf wrote: > * Nicolas DICHTEL <426F42F0.9020609@6wind.com> 2005-04-27 09:44 > > > > >Yes I agree, it doesn't really matter what value we return and `bound' > > >is most likely to be correct. I think we should also fix the unlikely > > >but still possible case when tv1.tv_usec is slightly smaller than > > >tv2.tv_usec. I know it is very unlikely but do_gettimeofday really > > >is not that reliable and we have users which rely on a positive > > >delta. Can you extend your patch to return abs(delta) for case 0 > > >in PSCHED_TDIFF_SAFE? > > > > > You're right. Here is the new patch. > > > > [SCHED] Fix range in PSCHED_TDIFF_SAFE to 0..bound > > > > Signed-off-by: Nicolas Dichtel > > Signed-off-by: Thomas Graf Applied, thanks everyone. From davem@davemloft.net Thu Apr 28 12:25:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 12:25:54 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJPo7J028927 for ; Thu, 28 Apr 2005 12:25:50 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DREUx-0002wK-00; Thu, 28 Apr 2005 12:16:31 -0700 Date: Thu, 28 Apr 2005 12:16:30 -0700 From: "David S. Miller" To: Olaf Rempel Cc: netdev@oss.sgi.com Subject: Re: [2.6.11 PATCH] /proc/net/stat/* cleanup Message-Id: <20050428121630.46da5ea3.davem@davemloft.net> In-Reply-To: <20050425190048.370dfd15@coruscant.lan> References: <20050304203751.379dc6a6@coruscant> <20050424193007.0a687ef4.davem@davemloft.net> <20050425190048.370dfd15@coruscant.lan> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 538 Lines: 20 On Mon, 25 Apr 2005 19:00:48 +0200 Olaf Rempel wrote: > On Sun, 24 Apr 2005 19:30:07 -0700 > "David S. Miller" wrote: > > > Your patch is mangled by your email client, the tabs have been turned > > into spaces, so the patch will not apply. > > > > Also, please supply a proper "Signed-off-by:" line with your changes. > > Whoops. OK > > Patch against 2.6.11 vanilla > > /proc/net/stat/* header cleanup > > Signed-off-by: Olaf Rempel Patch applied, thanks a lot. From jketreno@linux.intel.com Thu Apr 28 13:04:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 13:04:24 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SK4L7J031124 for ; Thu, 28 Apr 2005 13:04:22 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3SK4H2w016325; Thu, 28 Apr 2005 20:04:17 GMT Received: from [127.0.0.1] (hdlrvguser-62.hd.intel.com [10.127.52.81]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j3SK4DJQ006799; Thu, 28 Apr 2005 20:04:15 GMT Message-ID: <427141F8.7040407@linux.intel.com> Date: Thu, 28 Apr 2005 15:05:12 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: yi.zhu@intel.com, netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6 1/1] ipw2200 1.0.0 References: <42445919.7040003@linux.intel.com> <42445B4A.108@pobox.com> In-Reply-To: <42445B4A.108@pobox.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 239 Lines: 11 Jeff Garzik wrote: > > Thanks a lot for your submissions. I'm about to disappear for an > extended weekend, and will merge this stuff when I get back. Are the ipw2100 1.1.0 and ipw2200 1.0.0 still queued up for merging? Thanks, James From jgarzik@pobox.com Thu Apr 28 13:12:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 13:12:17 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SKCC7J032172 for ; Thu, 28 Apr 2005 13:12:12 -0700 Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.50 #1 (Red Hat Linux)) id 1DRFMg-00041V-5R; Thu, 28 Apr 2005 20:12:03 +0000 Message-ID: <4271438E.9010905@pobox.com> Date: Thu, 28 Apr 2005 16:11:58 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: yi.zhu@intel.com, netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6 1/1] ipw2200 1.0.0 References: <42445919.7040003@linux.intel.com> <42445B4A.108@pobox.com> <427141F8.7040407@linux.intel.com> In-Reply-To: <427141F8.7040407@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 337 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: 380 Lines: 19 James Ketrenos wrote: > Jeff Garzik wrote: > > >>Thanks a lot for your submissions. I'm about to disappear for an >>extended weekend, and will merge this stuff when I get back. > > > Are the ipw2100 1.1.0 and ipw2200 1.0.0 still queued up for merging? Yes, I've just been going really slow converting my 50+ internal BK repositories to git. Sorry for the delay. Jeff From mark@wetlettuce.com Thu Apr 28 13:43:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 13:43:20 -0700 (PDT) Received: from piglet.wetlettuce.com (piglet.wetlettuce.com [82.68.149.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SKhE7J001622 for ; Thu, 28 Apr 2005 13:43:15 -0700 Received: from tigger.wetlettuce.com ([82.68.149.65] helo=tigger ident=Debian-exim) by piglet.wetlettuce.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 1DRFqC-0000kx-00; Thu, 28 Apr 2005 21:42:32 +0100 Received: from mark by tigger with local (Exim 4.50) id 1DRFqC-00028H-Qi; Thu, 28 Apr 2005 21:42:32 +0100 From: "Mark Broadbent" To: linux-kernel@vger.kernel.org To: jgarzik@pobox.com To: netdev@oss.sgi.com Subject: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-Id: Date: Thu, 28 Apr 2005 21:42:32 +0100 X-Wetlettuce-MailScanner: Mail is clear of Viree X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markb@wetlettuce.com Precedence: bulk X-list: netdev Content-Length: 1010 Lines: 30 The interrupt handling code in the tulip network driver appears to use a non IRQ safe spinlock in an interrupt context. The following patch should correct this. Signed-off-by: Mark Broadbent Index: linux-2.6.11/drivers/net/tulip/interrupt.c =================================================================== --- linux-2.6.11.orig/drivers/net/tulip/interrupt.c 2005-03-07 18:11:23.000000000 +0000 +++ linux-2.6.11/drivers/net/tulip/interrupt.c 2005-04-28 16:16:23.000000000 +0100 @@ -567,8 +567,9 @@ if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) { unsigned int dirty_tx; + unsigned long flags; - spin_lock(&tp->lock); + spin_lock_irqsave(&tp->lock, flags); for (dirty_tx = tp->dirty_tx; tp->cur_tx - dirty_tx > 0; dirty_tx++) { @@ -640,7 +641,7 @@ dev->name, csr5, ioread32(ioaddr + CSR6), tp->csr6); tulip_restart_rxtx(tp); } - spin_unlock(&tp->lock); + spin_unlock_irqrestore(&tp->lock, flags); } /* Log errors. */ From andy.grover@gmail.com Thu Apr 28 14:14:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 14:14:20 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SLEH7J003018 for ; Thu, 28 Apr 2005 14:14:17 -0700 Received: by rproxy.gmail.com with SMTP id b11so431709rne for ; Thu, 28 Apr 2005 14:14:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=eeIltKSrW01nuwdnnoXPWjBKFtxH2XS/Yldizyr9awEynzYNk7AeWIItu659yJMVqgh8r2x9TnqVPpFxeOcuSNdwv7joTBT6CPaGqWYna9/fivy+gGhQb9Dt005R0tMpDQSw/3lpYQgekMIF8KS6WK9Ei4K7Si7zMUpw7IaT+VQ= Received: by 10.11.122.24 with SMTP id u24mr103811cwc; Thu, 28 Apr 2005 14:14:13 -0700 (PDT) Received: by 10.11.122.42 with HTTP; Thu, 28 Apr 2005 14:14:13 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2005 14:14:13 -0700 From: Andrew Grover Reply-To: Andrew Grover To: netdev@oss.sgi.com Subject: [PATCH] Add more explanation to tcp_prequeue comment Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3SLEH7J003018 X-archive-position: 340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.grover@gmail.com Precedence: bulk X-list: netdev Content-Length: 930 Lines: 22 Here's a patch to make that prequeue comment a little clearer. Look ok? Signed-off-by: Andy Grover ===== include/net/tcp.h 1.105 vs edited ===== --- 1.105/include/net/tcp.h 2005-02-22 10:45:31 -08:00 +++ edited/include/net/tcp.h 2005-04-28 14:02:43 -07:00 @@ -1560,6 +1560,13 @@ * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93) * failed somewhere. Latency? Burstiness? Well, at least now we will * see, why it failed. 8)8) --ANK + * + * Actually, even though the prequeue is not as important for fast + * csum anymore, it is important for scheduling, to generate ACKs + * when the data is received by the process, not the stack. + * davem says, "Without prequeue, we ACK immediately. This artificially + * makes the sender believe it can pump data out at that rate to the + * receiver." * * NOTE: is this not too big to inline? */ From folkert@vanheusden.com Thu Apr 28 14:25:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 14:25:04 -0700 (PDT) Received: from keetweej.vanheusden.com (keetweej.xs4all.nl [213.84.46.114]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SLOx7J004325 for ; Thu, 28 Apr 2005 14:25:00 -0700 Received: from keetweej.intranet.vanheusden.com (keetweej.intranet.vanheusden.com [192.168.64.99]) by keetweej.vanheusden.com (Postfix) with ESMTP id F00041CA379; Thu, 28 Apr 2005 23:24:53 +0200 (CEST) Date: Thu, 28 Apr 2005 23:24:53 +0200 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-ID: <20050428212449.GC8774@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> <20050428120824.6cc9b345.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RUqJLqMNe5u4kDWT" Content-Disposition: inline In-Reply-To: <20050428120824.6cc9b345.davem@davemloft.net> Organization: www.unixexpert.nl X-Chameleon-Return-To: folkert@vanheusden.com X-Xfmail-Return-To: folkert@vanheusden.com X-Phonenumber: +31-6-41278122 X-URL: http://www.vanheusden.com/ X-PGP-KeyID: 1F28D8AE X-GPG-fingerprint: AC89 09CE 41F2 00B4 FCF2 B174 3019 0E8C 1F28 D8AE X-Key: http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x1F28D8AE Read-Receipt-To: Reply-By: Thu Apr 28 19:51:31 CEST 2005 X-MSMail-Priority: High User-Agent: Mutt/1.5.9i From: folkert@vanheusden.com X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: folkert@vanheusden.com Precedence: bulk X-list: netdev Content-Length: 3813 Lines: 113 --RUqJLqMNe5u4kDWT Content-Type: multipart/mixed; boundary="3eH4Qcq5fItR5cpy" Content-Disposition: inline --3eH4Qcq5fItR5cpy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > I'll resend it as an attachment (see attachment). > It still has spaces where there should be tabs, even though > you compressed the patch and used attachment. > The diff itself must already be corrupt before you attach > it. > Please double check that the patch you submit actually apply, > this will save me a lot of wasted time. Ok, I've redone them and tested if they patch cleanly, they now do. See them attached. While looking at the code I also saw something else: --- tcp_ipv4.c.org 2005-04-28 23:13:32.000000000 +0200 +++ tcp_ipv4.c 2005-04-28 23:19:18.000000000 +0200 @@ -222,11 +222,11 @@ int rover; =20 spin_lock(&tcp_portalloc_lock); - rover =3D tcp_port_rover; + if (tcp_port_rover < low) + rover =3D low; + else + rover =3D tcp_port_rover; do { - rover++; - if (rover < low || rover > high) - rover =3D low; head =3D &tcp_bhash[tcp_bhashfn(rover)]; spin_lock(&head->lock); tb_for_each(tb, node, &head->chain) @@ -235,6 +235,10 @@ break; next: spin_unlock(&head->lock); + + rover++; + if (rover > high) + rover =3D low; } while (--remaining > 0); tcp_port_rover =3D rover; spin_unlock(&tcp_portalloc_lock); as you can see I moved (here! not in the included patches as I wanted to discuss this first!) the 'rover++' and its check to the end of the while loop. I did this because if they are at the top of the wile-loop the 'low' port number is never used as the first statement was a rover++! Folkert van Heusden --=20 Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)=20 a try, it brings monitoring logfiles to a different level! See =20 http://vanheusden.com/multitail/features.html for a feature-list. =20 -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! --3eH4Qcq5fItR5cpy Content-Type: application/octet-stream Content-Disposition: attachment; filename="tcp_ipv4.c.diff.gz" Content-Transfer-Encoding: base64 H4sICJFScUICA3RjcF9pcHY0LmMuZGlmZgBlUNuOgjAUfC5fMU9G0i2prSYbVMJ/mA1hES2R UAKEfVg/3l7EBbcvp2fOzJwLYwxD0WZVO26jItLdlQjOd4xvmfiEkPFGxlJEfHqg3NQDSulM 9i7ZxVL+k6QpmBDiY2MAFyXSNAAhVTOg02PZ7QPYvG+rJqt1cVuvbItWd0Nem9xh4T5ghDg6 jpjq2VNPjdsF6yWMA2r9E9riS2gAxy7rvlwU3h3NPGeNXxs9h1I3geszs8f97pdAAlVdlW/3 R5pQ67OcwiKqzM8md/t+q7xXp9fv0niH8MtTZ9exKpY8r/IAs1MhM8kBAAA= --3eH4Qcq5fItR5cpy Content-Type: application/octet-stream Content-Disposition: attachment; filename="tcp_ipv6.c.diff.gz" Content-Transfer-Encoding: base64 H4sICB5TcUICA3RjcF9pcHY2LmMuZGlmZgBlUMtugzAQPJuvmFMEcoyMU9KEPMR/VBWiQGJU hBGg5JB8fG1DIqC+2DuzM7Nexhj6rEnK5rb1M1+1VyI4Dxn/YGIHsYmCbRQKn78OKNe8Qymd yJaSzygM/kniGCzY7Nd7UHMFAnHsgJCy7tGqW9EeHJi6a8o6qVT2665MQqPaPq10bTHv4DBC bDtOePHJqKfa7QJ3DuOISt09Q76FGrDdRdUVM2LpqOfJFR4DT6lNtxnu1BvPJ0bgDFlepTfE mcYZbPwWUxhEFmmua/vfH5l28uv9utSDg/c9tE62Y1TsPG7lDy7ZsfvIAQAA --3eH4Qcq5fItR5cpy-- --RUqJLqMNe5u4kDWT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iIMEARECAEMFAkJxVKE8Gmh0dHA6Ly93d3cudmFuaGV1c2Rlbi5jb20vZGF0YS1z aWduaW5nLXdpdGgtcGdwLXBvbGljeS5odG1sAAoJEDAZDowfKNiu0Y4AnR02cQST QQKl/ovWjAIPNZb2BiTMAJ0fh3NZaSG4+BbpkHyWM4Tekg5IxA== =01+F -----END PGP SIGNATURE----- --RUqJLqMNe5u4kDWT-- From herbert@gondor.apana.org.au Thu Apr 28 14:27:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 14:27:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SLQx7J004836 for ; Thu, 28 Apr 2005 14:27:00 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DRGWz-000456-00; Fri, 29 Apr 2005 07:26:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DRGWv-0003aa-00; Fri, 29 Apr 2005 07:26:41 +1000 From: Herbert Xu To: markb@wetlettuce.com (Mark Broadbent) Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 29 Apr 2005 07:26:41 +1000 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 521 Lines: 14 Mark Broadbent wrote: > The interrupt handling code in the tulip network driver appears to use a non > IRQ safe spinlock in an interrupt context. The following patch should correct > this. This is bogus. Interrupts are already disabled when you're in the interrupt handler. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From arnaldo.melo@gmail.com Thu Apr 28 14:53:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 14:54:03 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SLrn7J006713 for ; Thu, 28 Apr 2005 14:53:49 -0700 Received: by zproxy.gmail.com with SMTP id 8so604672nzo for ; Thu, 28 Apr 2005 14:53:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qfk5jDkCZBille8xxUh5oXP+URxm+Eb4zlgdHUKioTMHHuaQarSNwA5LVLqNKXE3l5oKhXTLSry8FrsWvc4QFGxJd/Ck9rg4CeihalW8gVX9DFMkRwnb54WVWO/3XT/tO646KIswbzZvBXzbupmzgZZIOlj8lUer3LR1pNbx7hk= Received: by 10.36.10.18 with SMTP id 18mr122299nzj; Thu, 28 Apr 2005 14:53:45 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Thu, 28 Apr 2005 14:53:45 -0700 (PDT) Message-ID: <39e6f6c70504281453a903d92@mail.gmail.com> Date: Thu, 28 Apr 2005 18:53:45 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Andrew Grover Subject: Re: [PATCH] Add more explanation to tcp_prequeue comment Cc: netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3SLrn7J006713 X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1923 Lines: 42 On 4/28/05, Andrew Grover wrote: > Here's a patch to make that prequeue comment a little clearer. Look ok? > > Signed-off-by: Andy Grover > > ===== include/net/tcp.h 1.105 vs edited ===== > --- 1.105/include/net/tcp.h 2005-02-22 10:45:31 -08:00 > +++ edited/include/net/tcp.h 2005-04-28 14:02:43 -07:00 > @@ -1560,6 +1560,13 @@ > * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93) > * failed somewhere. Latency? Burstiness? Well, at least now we will > * see, why it failed. 8)8) --ANK > + * > + * Actually, even though the prequeue is not as important for fast > + * csum anymore, it is important for scheduling, to generate ACKs > + * when the data is received by the process, not the stack. > + * davem says, "Without prequeue, we ACK immediately. This artificially > + * makes the sender believe it can pump data out at that rate to the > + * receiver." Cool, great comment, for me the funny thing is that this is one of the differences of DCCP x TCP, i.e. in DCCP we must ack it _before_ it gets to sk_receive_queue, if later on we drop the packet for any reason we send DATA_DROPPED options to the sender. from draft-ietf-dccp-spec-11.txt: 1. Packets reported as State 0 or State 1 MUST be acknowledgeable: their options have been processed by the receiving DCCP stack. Any data on the packet need not have been delivered to the receiving application; in fact, the data may have been dropped. Packets dropped in the application's receive buffer MUST be reported as Received or Received ECN Marked (States 0 and 1), depending on their ECN state; such packets' ECN Nonces MUST be included in the Nonce Echo. The Data Dropped option informs the sender that some packets reported as received actually had their application data dropped. - Arnaldo From juhl-lkml@dif.dk Thu Apr 28 15:19:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 15:19:19 -0700 (PDT) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SMJ97J007945 for ; Thu, 28 Apr 2005 15:19:10 -0700 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 998D4FF41C for ; Fri, 29 Apr 2005 00:30:25 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15072-02 for ; Fri, 29 Apr 2005 00:30:21 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id A050AFFC61 for ; Fri, 29 Apr 2005 00:30:21 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Fri, 29 Apr 2005 00:17:34 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JVVD08C8; Fri, 29 Apr 2005 00:18:55 +0200 Date: Fri, 29 Apr 2005 00:22:22 +0200 (CEST) From: Jesper Juhl To: netdev@oss.sgi.com Cc: "David S. Miller" , Arnaldo Carvalho de Melo , Regina Kodato , pc300@cyclades.com, Nenad Corbic , Henner Eisen , linux-net@vger.kernel.org, linux-kernel Subject: [PATCH] cleanups in drivers/net/wan/ - kfree of NULL pointer is valid Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 6289 Lines: 203 kfree(0) is perfectly valid, checking pointers for NULL before calling kfree() on them is redundant. The patch below cleans away a few such redundant checks (and while I was around some of those bits I couldn't stop myself from making a few tiny whitespace changes as well). Signed-off-by: Jesper Juhl --- drivers/net/wan/cycx_x25.c | 8 ++------ drivers/net/wan/pc300_tty.c | 27 +++++++++++---------------- drivers/net/wan/sdla_chdlc.c | 13 ++++--------- drivers/net/wan/x25_asy.c | 20 ++++++-------------- 4 files changed, 23 insertions(+), 45 deletions(-) diff -uprN linux-2.6.12-rc2-mm3-orig/drivers/net/wan/cycx_x25.c linux-2.6.12-rc2-mm3/drivers/net/wan/cycx_x25.c --- linux-2.6.12-rc2-mm3-orig/drivers/net/wan/cycx_x25.c 2005-03-02 08:37:49.000000000 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/wan/cycx_x25.c 2005-04-28 23:51:12.000000000 +0200 @@ -436,9 +436,7 @@ static int cycx_wan_new_if(struct wan_de } if (err) { - if (chan->local_addr) - kfree(chan->local_addr); - + kfree(chan->local_addr); kfree(chan); return err; } @@ -458,9 +456,7 @@ static int cycx_wan_del_if(struct wan_de struct cycx_x25_channel *chan = dev->priv; if (chan->svc) { - if (chan->local_addr) - kfree(chan->local_addr); - + kfree(chan->local_addr); if (chan->state == WAN_CONNECTED) del_timer(&chan->timer); } diff -uprN linux-2.6.12-rc2-mm3-orig/drivers/net/wan/pc300_tty.c linux-2.6.12-rc2-mm3/drivers/net/wan/pc300_tty.c --- linux-2.6.12-rc2-mm3-orig/drivers/net/wan/pc300_tty.c 2005-03-02 08:38:08.000000000 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/wan/pc300_tty.c 2005-04-28 23:59:54.000000000 +0200 @@ -400,10 +400,8 @@ static void cpc_tty_close(struct tty_str cpc_tty->buf_rx.last = NULL; } - if (cpc_tty->buf_tx) { - kfree(cpc_tty->buf_tx); - cpc_tty->buf_tx = NULL; - } + kfree(cpc_tty->buf_tx); + cpc_tty->buf_tx = NULL; CPC_TTY_DBG("%s: TTY closed\n",cpc_tty->name); @@ -666,7 +664,7 @@ static void cpc_tty_rx_work(void * data) unsigned long port; int i, j; st_cpc_tty_area *cpc_tty; - volatile st_cpc_rx_buf * buf; + volatile st_cpc_rx_buf *buf; char flags=0,flg_rx=1; struct tty_ldisc *ld; @@ -680,9 +678,9 @@ static void cpc_tty_rx_work(void * data) cpc_tty = &cpc_tty_area[port]; if ((buf=cpc_tty->buf_rx.first) != 0) { - if(cpc_tty->tty) { + if (cpc_tty->tty) { ld = tty_ldisc_ref(cpc_tty->tty); - if(ld) { + if (ld) { if (ld->receive_buf) { CPC_TTY_DBG("%s: call line disc. receive_buf\n",cpc_tty->name); ld->receive_buf(cpc_tty->tty, (char *)(buf->data), &flags, buf->size); @@ -691,7 +689,7 @@ static void cpc_tty_rx_work(void * data) } } cpc_tty->buf_rx.first = cpc_tty->buf_rx.first->next; - kfree((unsigned char *)buf); + kfree(buf); buf = cpc_tty->buf_rx.first; flg_rx = 1; } @@ -733,7 +731,7 @@ static void cpc_tty_rx_disc_frame(pc300c void cpc_tty_receive(pc300dev_t *pc300dev) { - st_cpc_tty_area *cpc_tty; + st_cpc_tty_area *cpc_tty; pc300ch_t *pc300chan = (pc300ch_t *)pc300dev->chan; pc300_t *card = (pc300_t *)pc300chan->card; int ch = pc300chan->channel; @@ -742,7 +740,7 @@ void cpc_tty_receive(pc300dev_t *pc300de int rx_len, rx_aux; volatile unsigned char status; unsigned short first_bd = pc300chan->rx_first_bd; - st_cpc_rx_buf *new=NULL; + st_cpc_rx_buf *new = NULL; unsigned char dsr_rx; if (pc300dev->cpc_tty == NULL) { @@ -762,7 +760,7 @@ void cpc_tty_receive(pc300dev_t *pc300de if (status & DST_EOM) { break; } - ptdescr=(pcsca_bd_t __iomem *)(card->hw.rambase+cpc_readl(&ptdescr->next)); + ptdescr = (pcsca_bd_t __iomem *)(card->hw.rambase+cpc_readl(&ptdescr->next)); } if (!rx_len) { @@ -771,10 +769,7 @@ void cpc_tty_receive(pc300dev_t *pc300de cpc_writel(card->hw.scabase + DRX_REG(EDAL, ch), RX_BD_ADDR(ch, pc300chan->rx_last_bd)); } - if (new) { - kfree(new); - new = NULL; - } + kfree(new); return; } @@ -787,7 +782,7 @@ void cpc_tty_receive(pc300dev_t *pc300de continue; } - new = (st_cpc_rx_buf *) kmalloc(rx_len + sizeof(st_cpc_rx_buf), GFP_ATOMIC); + new = (st_cpc_rx_buf *)kmalloc(rx_len + sizeof(st_cpc_rx_buf), GFP_ATOMIC); if (new == 0) { cpc_tty_rx_disc_frame(pc300chan); continue; diff -uprN linux-2.6.12-rc2-mm3-orig/drivers/net/wan/sdla_chdlc.c linux-2.6.12-rc2-mm3/drivers/net/wan/sdla_chdlc.c --- linux-2.6.12-rc2-mm3-orig/drivers/net/wan/sdla_chdlc.c 2005-03-02 08:38:09.000000000 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/wan/sdla_chdlc.c 2005-04-29 00:03:30.000000000 +0200 @@ -3664,15 +3664,10 @@ static void wanpipe_tty_close(struct tty chdlc_disable_comm_shutdown(card); unlock_adapter_irq(&card->wandev.lock,&smp_flags); - if (card->tty_buf){ - kfree(card->tty_buf); - card->tty_buf=NULL; - } - - if (card->tty_rx){ - kfree(card->tty_rx); - card->tty_rx=NULL; - } + kfree(card->tty_buf); + card->tty_buf = NULL; + kfree(card->tty_rx); + card->tty_rx = NULL; } return; } diff -uprN linux-2.6.12-rc2-mm3-orig/drivers/net/wan/x25_asy.c linux-2.6.12-rc2-mm3/drivers/net/wan/x25_asy.c --- linux-2.6.12-rc2-mm3-orig/drivers/net/wan/x25_asy.c 2005-03-02 08:37:50.000000000 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/wan/x25_asy.c 2005-04-29 00:08:16.000000000 +0200 @@ -107,13 +107,9 @@ static struct x25_asy *x25_asy_alloc(voi static void x25_asy_free(struct x25_asy *sl) { /* Free all X.25 frame buffers. */ - if (sl->rbuff) { - kfree(sl->rbuff); - } + kfree(sl->rbuff); sl->rbuff = NULL; - if (sl->xbuff) { - kfree(sl->xbuff); - } + kfree(sl->xbuff); sl->xbuff = NULL; if (!test_and_clear_bit(SLF_INUSE, &sl->flags)) { @@ -134,10 +130,8 @@ static int x25_asy_change_mtu(struct net { printk("%s: unable to grow X.25 buffers, MTU change cancelled.\n", dev->name); - if (xbuff != NULL) - kfree(xbuff); - if (rbuff != NULL) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); return -ENOMEM; } @@ -169,10 +163,8 @@ static int x25_asy_change_mtu(struct net spin_unlock_bh(&sl->lock); - if (xbuff != NULL) - kfree(xbuff); - if (rbuff != NULL) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); return 0; } From acme@conectiva.com.br Thu Apr 28 15:23:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 15:24:04 -0700 (PDT) Received: from orion.netbank.com.br ([200.203.199.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SMNv7J008467 for ; Thu, 28 Apr 2005 15:23:58 -0700 Received: from [201.11.58.172] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DRHSS-0008HS-00; Thu, 28 Apr 2005 19:26:08 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id BF8701462D; Thu, 28 Apr 2005 19:23:30 -0300 (BRT) Date: Thu, 28 Apr 2005 19:23:30 -0300 From: Arnaldo Carvalho de Melo To: Jesper Juhl Cc: netdev@oss.sgi.com, "David S. Miller" , Regina Kodato , pc300@cyclades.com, Nenad Corbic , Henner Eisen , linux-net@vger.kernel.org, linux-kernel Subject: Re: [PATCH] cleanups in drivers/net/wan/ - kfree of NULL pointer is valid Message-ID: <20050428222330.GI26945@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , Jesper Juhl , netdev@oss.sgi.com, "David S. Miller" , Regina Kodato , pc300@cyclades.com, Nenad Corbic , Henner Eisen , linux-net@vger.kernel.org, linux-kernel References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 345 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: 413 Lines: 8 Em Fri, Apr 29, 2005 at 12:22:22AM +0200, Jesper Juhl escreveu: > kfree(0) is perfectly valid, checking pointers for NULL before calling > kfree() on them is redundant. The patch below cleans away a few such > redundant checks (and while I was around some of those bits I couldn't > stop myself from making a few tiny whitespace changes as well). Acked-by: Arnaldo Carvalho de MElo From pbadari@us.ibm.com Thu Apr 28 15:36:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 15:36:56 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SMal7J009329 for ; Thu, 28 Apr 2005 15:36:54 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3SMahAa128038 for ; Thu, 28 Apr 2005 18:36:43 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3SMahYQ370314 for ; Thu, 28 Apr 2005 16:36:43 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3SMagK1017745 for ; Thu, 28 Apr 2005 16:36:42 -0600 Received: from dyn9047017072.beaverton.ibm.com (dyn9047017072.beaverton.ibm.com [9.47.17.72]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3SMagaa017725 for ; Thu, 28 Apr 2005 16:36:42 -0600 Subject: Panic in sk_stream_wait_memory() while doing iSCSI testing From: Badari Pulavarty To: netdev Content-Type: text/plain Organization: Message-Id: <1114726972.26913.711.camel@dyn318077bld.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 28 Apr 2005 15:22:54 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pbadari@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2872 Lines: 70 Hi, I ran into panic in sk_stream_wait_memory() while doing iSCSI testing on 2.6.12-rc2. The problem seems to be while doing set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); sk->sk_socket seems to be NULL. Can this happen ? Do we need to check for sk_error or sk_shutdown before de-ref sk->sk_socket ? Is this a known and/or fixed problem ? Please let me know. Thanks, Badari Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP: {sk_stream_wait_memory+199} Oops: 0002 [1] SMP CPU 0 Modules linked in: joydev sg st floppy usbserial parport_pc lp parport ipv6 ohcvPid: 26987, comm: kjournald Not tainted 2.6.12-rc2n 0:06.47 pdflush RIP: 0010:[] {sk_stream_wait_memory+199} RSP: 0018:ffff810154261978 EFLAGS: 000102469 0.0 0:06.40 dd RAX: 0000000000000000 RBX: ffff81017f3eac00 RCX: 0000000000000296 RDX: ffff81000c005ba8 RSI: 0000000000000296 RDI: ffff81017f3eac38 RBP: 0000000000003a8d R08: 0000000000000000 R09: 000000000000000c R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000000 R13: ffff810154261a68 R14: ffff8101542619a8 R15: 0000000000000000 FS: 00002aaaaade3700(0000) GS:ffffffff806533c0(0000) knlGS:0000000055975080 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b0 0:05.89 dd CR2: 0000000000000008 CR3: 00000001ba0e3000 CR4: 00000000000006e0 Process kjournald (pid: 26987, threadinfo ffff810154260000, task ffff8101d9a595)Stack: 0000000000000000 ffff8101d9a59520 ffffffff8014c6e0 ffff8101542619c0 ffff8101542619c0 ffff8101d62d7900 0000000000000000 ffff8101d9a59520 ffffffff8014c6e0 ffff8101542619c0 Call Trace:{autoremove_wake_function+0} {tcp_sendpage+2260} {mempool_alloc+164} {scsi_dispatch_cmd+566} {__generic_unplug_device+45} {generic_make_request+546} {autoremove_wake_function+0} {submit_bio+223} {submit_bh+283} {ll_rw_block+105} {journal_commit_transaction+1523} {thread_return+0} {thread_return+89} {__wake_up+67} {kjournald+394} {autoremove_wake_function+0} {autore {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} Code: f0 0f ba 68 08 00 48 8b 7b 60 ba 01 00 00 00 4c 89 f6 e8 62 RIP {sk_stream_wait_memory+199} RSP CR2: 0000000000000008 From juhl-lkml@dif.dk Thu Apr 28 15:51:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 15:51:38 -0700 (PDT) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SMpX7J010109 for ; Thu, 28 Apr 2005 15:51:34 -0700 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 1318FFFCA9 for ; Fri, 29 Apr 2005 01:02:46 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15651-06 for ; Fri, 29 Apr 2005 01:02:45 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id 22EA1FFCAE for ; Fri, 29 Apr 2005 01:02:44 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Fri, 29 Apr 2005 00:49:56 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JVVD08FD; Fri, 29 Apr 2005 00:51:17 +0200 Date: Fri, 29 Apr 2005 00:54:44 +0200 (CEST) From: Jesper Juhl To: Paul Mackerras Cc: linux-ppp@vger.kernel.org, "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] ppp: remove redundant NULL pointer checks before kfree & vfree Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 1673 Lines: 62 kfree() and vfree() can both deal with NULL pointers. This patch removes redundant NULL pointer checks from the ppp code in drivers/net/ Signed-off-by: Jesper Juhl --- drivers/net/ppp_deflate.c | 6 ++---- drivers/net/ppp_generic.c | 12 ++++-------- 2 files changed, 6 insertions(+), 12 deletions(-) --- linux-2.6.12-rc2-mm3-orig/drivers/net/ppp_deflate.c 2005-04-05 21:21:33.000000000 +0200 +++ linux-2.6.12-rc2-mm3/drivers/net/ppp_deflate.c 2005-04-29 00:44:26.000000000 +0200 @@ -87,8 +87,7 @@ static void z_comp_free(void *arg) if (state) { zlib_deflateEnd(&state->strm); - if (state->strm.workspace) - vfree(state->strm.workspace); + vfree(state->strm.workspace); kfree(state); } } @@ -308,8 +307,7 @@ static void z_decomp_free(void *arg) if (state) { zlib_inflateEnd(&state->strm); - if (state->strm.workspace) - kfree(state->strm.workspace); + kfree(state->strm.workspace); kfree(state); } } --- linux-2.6.12-rc2-mm3-orig/drivers/net/ppp_generic.c 2005-04-11 21:20:47.000000000 +0200 +++ linux-2.6.12-rc2-mm3/drivers/net/ppp_generic.c 2005-04-29 00:46:00.000000000 +0200 @@ -2510,14 +2510,10 @@ static void ppp_destroy_interface(struct skb_queue_purge(&ppp->mrq); #endif /* CONFIG_PPP_MULTILINK */ #ifdef CONFIG_PPP_FILTER - if (ppp->pass_filter) { - kfree(ppp->pass_filter); - ppp->pass_filter = NULL; - } - if (ppp->active_filter) { - kfree(ppp->active_filter); - ppp->active_filter = NULL; - } + kfree(ppp->pass_filter); + ppp->pass_filter = NULL; + kfree(ppp->active_filter); + ppp->active_filter = NULL; #endif /* CONFIG_PPP_FILTER */ kfree(ppp); PS. Please CC me on replies. From herbert@gondor.apana.org.au Thu Apr 28 16:12:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 16:12:27 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SNCJ7J011189 for ; Thu, 28 Apr 2005 16:12:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DRIAp-0004yC-00; Fri, 29 Apr 2005 09:11:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DRIAk-0003hc-00; Fri, 29 Apr 2005 09:11:54 +1000 Date: Fri, 29 Apr 2005 09:11:54 +1000 To: jamal Cc: Alexey Kuznetsov , netdev@oss.sgi.com, "David S. Miller" Subject: Re: patch2: del/get byid Message-ID: <20050428231154.GA14215@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> <1114656932.7663.88.camel@localhost.localdomain> <20050428030325.GB23823@gondor.apana.org.au> <1114658657.7663.110.camel@localhost.localdomain> <1114698033.7663.197.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114698033.7663.197.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1279 Lines: 33 On Thu, Apr 28, 2005 at 10:20:33AM -0400, jamal wrote: > > Well, heres some minimalist patch i havent tested. i.e doesnt change any > of the functions; but at least it doesnt break the timers. > This includes both patches i posted earlier and introduces dir in > xfrm_policy. Thanks, the dir stuff looks good. > @@ -345,7 +345,10 @@ > > write_lock_bh(&xfrm_policy_lock); > for (p = &xfrm_policy_list[dir]; (pol=*p)!=NULL;) { > - if (!delpol && memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0) { > + if (!delpol && > + ((!excl && policy->index && > + (policy->index == pol->index)) || > + (memcmp(&policy->selector, &pol->selector, sizeof(pol->selector)) == 0))) { Now that you are allowing the user to set the index, this excl check really needs to go. Otherwise the user can add two policies with the same index. You also still need to solve the problem that you may need to delete two policies if one matches the index while the other matches the selector (or selector plus priority if you do that). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mallikarjuna.chilakala@intel.com Thu Apr 28 18:42:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:42:41 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1gc7J020370 for ; Thu, 28 Apr 2005 18:42:38 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1gWTs017577; Fri, 29 Apr 2005 01:42:32 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1gWP3014034; Fri, 29 Apr 2005 01:42:32 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818423208886 ; Thu, 28 Apr 2005 18:42:32 -0700 Date: Thu, 28 Apr 2005 18:42:29 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 0/11] ixgb: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 700 Lines: 17 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Fix multi-cast packet count in statistics 2. Do not set the RS bit on context descriptors 3. Change RDT write bump size back to 4 4. Mask RXO interrupt 5. Reset status in the Rx descriptor prior to handing it to the controller 6. Fix EEPROM functions to be endian-aware 7. Support for ethtool -d 8. Remove hook for suspend. No power management in 10GbE Controllers 9. Code optimization 10. Fixed msec_delay in osdep to use msleep 11. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Thu Apr 28 18:45:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:46:02 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1jw7J020835 for ; Thu, 28 Apr 2005 18:45:59 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1jr5P000720; Fri, 29 Apr 2005 01:45:53 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1joP5015726; Fri, 29 Apr 2005 01:45:51 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818455009108 ; Thu, 28 Apr 2005 18:45:50 -0700 Date: Thu, 28 Apr 2005 18:45:50 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 1/11] ixgb: Fix multi-cast packet count in statistics Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2274 Lines: 48 Fix multi-cast packet count in statistics Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1526,14 +1526,33 @@ ixgb_change_mtu(struct net_device *netde void ixgb_update_stats(struct ixgb_adapter *adapter) { + struct net_device *netdev = adapter->netdev; + + if((netdev->flags & IFF_PROMISC) || (netdev->flags & IFF_ALLMULTI) || + (netdev->mc_count > IXGB_MAX_NUM_MULTICAST_ADDRESSES)) { + u64 multi = IXGB_READ_REG(&adapter->hw, MPRCL); + u32 bcast_l = IXGB_READ_REG(&adapter->hw, BPRCL); + u32 bcast_h = IXGB_READ_REG(&adapter->hw, BPRCH); + u64 bcast = ((u64)bcast_h << 32) | bcast_l; + + multi |= ((u64)IXGB_READ_REG(&adapter->hw, MPRCH) << 32); + /* fix up multicast stats by removing broadcasts */ + multi -= bcast; + + adapter->stats.mprcl += (multi & 0xFFFFFFFF); + adapter->stats.mprch += (multi >> 32); + adapter->stats.bprcl += bcast_l; + adapter->stats.bprch += bcast_h; + } else { + adapter->stats.mprcl += IXGB_READ_REG(&adapter->hw, MPRCL); + adapter->stats.mprch += IXGB_READ_REG(&adapter->hw, MPRCH); + adapter->stats.bprcl += IXGB_READ_REG(&adapter->hw, BPRCL); + adapter->stats.bprch += IXGB_READ_REG(&adapter->hw, BPRCH); + } adapter->stats.tprl += IXGB_READ_REG(&adapter->hw, TPRL); adapter->stats.tprh += IXGB_READ_REG(&adapter->hw, TPRH); adapter->stats.gprcl += IXGB_READ_REG(&adapter->hw, GPRCL); adapter->stats.gprch += IXGB_READ_REG(&adapter->hw, GPRCH); - adapter->stats.bprcl += IXGB_READ_REG(&adapter->hw, BPRCL); - adapter->stats.bprch += IXGB_READ_REG(&adapter->hw, BPRCH); - adapter->stats.mprcl += IXGB_READ_REG(&adapter->hw, MPRCL); - adapter->stats.mprch += IXGB_READ_REG(&adapter->hw, MPRCH); adapter->stats.uprcl += IXGB_READ_REG(&adapter->hw, UPRCL); adapter->stats.uprch += IXGB_READ_REG(&adapter->hw, UPRCH); adapter->stats.vprcl += IXGB_READ_REG(&adapter->hw, VPRCL); From mallikarjuna.chilakala@intel.com Thu Apr 28 18:47:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:47:19 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1ku7J021122 for ; Thu, 28 Apr 2005 18:47:17 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1kp5P001092; Fri, 29 Apr 2005 01:46:51 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1kpP3016261; Fri, 29 Apr 2005 01:46:51 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818465109160 ; Thu, 28 Apr 2005 18:46:51 -0700 Date: Thu, 28 Apr 2005 18:46:51 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 2/11] ixgb: Do not set the RS bit on context descriptors Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1310 Lines: 32 Don't set the RS bit on context descriptors, causes un-necessary bus activity Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1209,9 +1209,9 @@ ixgb_tso(struct ixgb_adapter *adapter, s | IXGB_CONTEXT_DESC_CMD_TSE | IXGB_CONTEXT_DESC_CMD_IP | IXGB_CONTEXT_DESC_CMD_TCP - | IXGB_CONTEXT_DESC_CMD_RS | IXGB_CONTEXT_DESC_CMD_IDE | (skb->len - (hdr_len))); + if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; @@ -1246,9 +1246,8 @@ ixgb_tx_csum(struct ixgb_adapter *adapte context_desc->hdr_len = 0; context_desc->mss = 0; context_desc->cmd_type_len = - cpu_to_le32(IXGB_CONTEXT_DESC_TYPE - | IXGB_TX_DESC_CMD_RS - | IXGB_TX_DESC_CMD_IDE); + cpu_to_le32(IXGB_CONTEXT_DESC_TYPE + | IXGB_TX_DESC_CMD_IDE); if(++i == adapter->tx_ring.count) i = 0; adapter->tx_ring.next_to_use = i; From mallikarjuna.chilakala@intel.com Thu Apr 28 18:48:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:48:16 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1mE7J021743 for ; Thu, 28 Apr 2005 18:48:14 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1m65P001607; Fri, 29 Apr 2005 01:48:06 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1loPL016779; Fri, 29 Apr 2005 01:48:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818480520268 ; Thu, 28 Apr 2005 18:48:06 -0700 Date: Thu, 28 Apr 2005 18:48:06 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 3/11] ixgb: Change RDT write bump size to 4 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 877 Lines: 19 Change RDT write bump size back to 4 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb.h net-drivers-2.6/drivers/net/ixgb.new/ixgb.h --- net-drivers-2.6/drivers/net/ixgb/ixgb.h 2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb.h 2005-04-05 23:06:38.056967256 -0700 @@ -110,7 +110,7 @@ struct ixgb_adapter; #define IXGB_TX_QUEUE_WAKE 16 /* How many Rx Buffers do we bundle into one write to the hardware ? */ -#define IXGB_RX_BUFFER_WRITE 16 /* Must be power of 2 */ +#define IXGB_RX_BUFFER_WRITE 4 /* Must be power of 2 */ /* only works for sizes that are powers of 2 */ #define IXGB_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) & ~((size) - 1))) From mallikarjuna.chilakala@intel.com Thu Apr 28 18:49:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:49:37 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1nY7J022415 for ; Thu, 28 Apr 2005 18:49:34 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1nTmZ032632; Fri, 29 Apr 2005 01:49:29 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1nOoY027464; Fri, 29 Apr 2005 01:49:29 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818492804012 ; Thu, 28 Apr 2005 18:49:28 -0700 Date: Thu, 28 Apr 2005 18:49:28 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 3/11] ixgb: Change RDT write bump size to 4 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 926 Lines: 21 Disable RXO interrupt to decrease recovery time when system is overloaded with data Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -224,8 +224,8 @@ ixgb_irq_enable(struct ixgb_adapter *ada { if(atomic_dec_and_test(&adapter->irq_sem)) { IXGB_WRITE_REG(&adapter->hw, IMS, - IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | - IXGB_INT_RXO | IXGB_INT_LSC); + IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | + IXGB_INT_LSC); IXGB_WRITE_FLUSH(&adapter->hw); } } From mallikarjuna.chilakala@intel.com Thu Apr 28 18:52:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:52:05 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1q07J023121 for ; Thu, 28 Apr 2005 18:52:00 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1psmZ001006; Fri, 29 Apr 2005 01:51:54 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1psP3019127; Fri, 29 Apr 2005 01:51:54 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818515309461 ; Thu, 28 Apr 2005 18:51:54 -0700 Date: Thu, 28 Apr 2005 18:51:54 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 5/11] ixgb: Reset status in the Rx Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1350 Lines: 33 Reset status in the Rx descriptor prior to handing it to the controller. Leave three Rx descriptors unused Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1977,8 +1977,8 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte num_group_tail_writes = IXGB_RX_BUFFER_WRITE; - /* leave one descriptor unused */ - while(--cleancount > 0) { + /* leave three descriptors unused */ + while(--cleancount > 2) { rx_desc = IXGB_RX_DESC(*rx_ring, i); skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); @@ -2005,6 +1933,10 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte PCI_DMA_FROMDEVICE); rx_desc->buff_addr = cpu_to_le64(buffer_info->dma); + /* guarantee DD bit not set now before h/w gets descriptor + * this is the rest of the workaround for h/w double + * writeback. */ + rx_desc->status = 0; if((i & ~(num_group_tail_writes- 1)) == i) { /* Force memory writes to complete before letting h/w From mallikarjuna.chilakala@intel.com Thu Apr 28 18:56:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 18:56:53 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T1ul7J023692 for ; Thu, 28 Apr 2005 18:56:51 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T1ufEf021178; Fri, 29 Apr 2005 01:56:41 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T1ueP3021794; Fri, 29 Apr 2005 01:56:40 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042818564009752 ; Thu, 28 Apr 2005 18:56:40 -0700 Date: Thu, 28 Apr 2005 18:56:40 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 4/11] ixgb: Mask RXO interrupt Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 926 Lines: 21 Disable RXO interrupt to decrease recovery time when system is overloaded with data Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -224,8 +224,8 @@ ixgb_irq_enable(struct ixgb_adapter *ada { if(atomic_dec_and_test(&adapter->irq_sem)) { IXGB_WRITE_REG(&adapter->hw, IMS, - IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | - IXGB_INT_RXO | IXGB_INT_LSC); + IXGB_INT_RXT0 | IXGB_INT_RXDMT0 | IXGB_INT_TXDW | + IXGB_INT_LSC); IXGB_WRITE_FLUSH(&adapter->hw); } } From mallikarjuna.chilakala@intel.com Thu Apr 28 19:03:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:03:43 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T23d7J024444 for ; Thu, 28 Apr 2005 19:03:40 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T23XTs028352; Fri, 29 Apr 2005 02:03:33 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T23WoS006602; Fri, 29 Apr 2005 02:03:32 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819033204912 ; Thu, 28 Apr 2005 19:03:32 -0700 Date: Thu, 28 Apr 2005 19:03:32 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 6/11] ixgb: Fix EEPROM functions to be endian-aware Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3989 Lines: 119 Fix EEPROM functions to be endian-aware Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ee.c 2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ee.c 2005-04-05 23:06:37.998976072 -0700 @@ -411,7 +411,7 @@ ixgb_write_eeprom(struct ixgb_hw *hw, ui ixgb_cleanup_eeprom(hw); /* clear the init_ctrl_reg_1 to signify that the cache is invalidated */ - ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; + ee_map->init_ctrl_reg_1 = le16_to_cpu(EEPROM_ICW1_SIGNATURE_CLEAR); return; } @@ -483,7 +461,7 @@ ixgb_get_eeprom_data(struct ixgb_hw *hw) DEBUGOUT("ixgb_ee: Checksum invalid.\n"); /* clear the init_ctrl_reg_1 to signify that the cache is * invalidated */ - ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; + ee_map->init_ctrl_reg_1 = le16_to_cpu(EEPROM_ICW1_SIGNATURE_CLEAR); return (FALSE); } @@ -579,7 +568,7 @@ ixgb_get_ee_compatibility(struct ixgb_hw struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->compatibility); + return (le16_to_cpu(ee_map->compatibility)); return(0); } @@ -616,7 +605,7 @@ ixgb_get_ee_init_ctrl_reg_1(struct ixgb_ struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->init_ctrl_reg_1); + return (le16_to_cpu(ee_map->init_ctrl_reg_1)); return(0); } @@ -635,7 +624,7 @@ ixgb_get_ee_init_ctrl_reg_2(struct ixgb_ struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->init_ctrl_reg_2); + return (le16_to_cpu(ee_map->init_ctrl_reg_2)); return(0); } @@ -654,7 +643,7 @@ ixgb_get_ee_subsystem_id(struct ixgb_hw struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->subsystem_id); + return (le16_to_cpu(ee_map->subsystem_id)); return(0); } @@ -673,7 +662,7 @@ ixgb_get_ee_subvendor_id(struct ixgb_hw struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->subvendor_id); + return (le16_to_cpu(ee_map->subvendor_id)); return(0); } @@ -692,7 +681,7 @@ ixgb_get_ee_device_id(struct ixgb_hw *hw struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->device_id); + return (le16_to_cpu(ee_map->device_id)); return(0); } @@ -711,7 +700,7 @@ ixgb_get_ee_vendor_id(struct ixgb_hw *hw struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->vendor_id); + return (le16_to_cpu(ee_map->vendor_id)); return(0); } @@ -730,7 +719,7 @@ ixgb_get_ee_swdpins_reg(struct ixgb_hw * struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->swdpins_reg); + return (le16_to_cpu(ee_map->swdpins_reg)); return(0); } @@ -749,7 +738,7 @@ ixgb_get_ee_d3_power(struct ixgb_hw *hw) struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->d3_power); + return (le16_to_cpu(ee_map->d3_power)); return(0); } @@ -768,7 +757,7 @@ ixgb_get_ee_d0_power(struct ixgb_hw *hw) struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; if(ixgb_check_and_get_eeprom_data(hw) == TRUE) - return(ee_map->d0_power); + return (le16_to_cpu(ee_map->d0_power)); return(0); } From mallikarjuna.chilakala@intel.com Thu Apr 28 19:04:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:04:15 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T24C7J024492 for ; Thu, 28 Apr 2005 19:04:12 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T247mZ005591; Fri, 29 Apr 2005 02:04:07 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T247P3026492; Fri, 29 Apr 2005 02:04:07 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819040615482 ; Thu, 28 Apr 2005 19:04:06 -0700 Date: Thu, 28 Apr 2005 19:04:07 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 7/11] ixgb: Support for ethtool -d Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 973 Lines: 22 ixgb support for ethtool -d Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_ethtool.c 2005-04-05 23:06:36.331229608 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_ethtool.c 2005-04-05 23:06:38.037970144 -0700 @@ -252,7 +252,9 @@ ixgb_get_regs(struct net_device *netdev, uint32_t *reg_start = reg; uint8_t i; - regs->version = (adapter->hw.device_id << 16) | adapter->hw.subsystem_id; + /* the 1 (one) below indicates an attempt at versioning, if the + * interface in ethtool or the driver this 1 should be incremented */ + regs->version = (1<<24) | hw->revision_id << 16 | hw->device_id; /* General Registers */ *reg++ = IXGB_READ_REG(hw, CTRL0); /* 0 */ From mallikarjuna.chilakala@intel.com Thu Apr 28 19:04:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:04:41 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T24d7J024749 for ; Thu, 28 Apr 2005 19:04:39 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T24XmZ005723; Fri, 29 Apr 2005 02:04:33 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T24VoW007253; Fri, 29 Apr 2005 02:04:33 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819043204967 ; Thu, 28 Apr 2005 19:04:32 -0700 Date: Thu, 28 Apr 2005 19:04:32 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 8/11] ixgb: Remove hook for suspend, no power management Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3626 Lines: 130 Remove hook for suspend. No power management in 10GbE Controllers Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -120,33 +120,20 @@ static int ixgb_change_mtu(struct net_de static void ixgb_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid); static void ixgb_restore_vlan(struct ixgb_adapter *adapter); -static int ixgb_notify_reboot(struct notifier_block *, unsigned long event, - void *ptr); -static int ixgb_suspend(struct pci_dev *pdev, uint32_t state); - #ifdef CONFIG_NET_POLL_CONTROLLER /* for netdump / net console */ static void ixgb_netpoll(struct net_device *dev); #endif -struct notifier_block ixgb_notifier_reboot = { - .notifier_call = ixgb_notify_reboot, - .next = NULL, - .priority = 0 -}; - /* Exported from other modules */ extern void ixgb_check_options(struct ixgb_adapter *adapter); static struct pci_driver ixgb_driver = { - .name = ixgb_driver_name, + .name = ixgb_driver_name, .id_table = ixgb_pci_tbl, - .probe = ixgb_probe, - .remove = __devexit_p(ixgb_remove), - /* Power Managment Hooks */ - .suspend = NULL, - .resume = NULL + .probe = ixgb_probe, + .remove = __devexit_p(ixgb_remove), }; MODULE_AUTHOR("Intel Corporation, "); @@ -169,17 +179,12 @@ MODULE_LICENSE("GPL"); static int __init ixgb_init_module(void) { - int ret; printk(KERN_INFO "%s - version %s\n", ixgb_driver_string, ixgb_driver_version); printk(KERN_INFO "%s\n", ixgb_copyright); - ret = pci_module_init(&ixgb_driver); - if(ret >= 0) { - register_reboot_notifier(&ixgb_notifier_reboot); - } - return ret; + return pci_module_init(&ixgb_driver); } module_init(ixgb_init_module); @@ -194,7 +194,6 @@ module_init(ixgb_init_module); static void __exit ixgb_exit_module(void) { - unregister_reboot_notifier(&ixgb_notifier_reboot); pci_unregister_driver(&ixgb_driver); } @@ -2121,54 +2092,6 @@ ixgb_restore_vlan(struct ixgb_adapter *a } } -/** - * ixgb_notify_reboot - handles OS notification of reboot event. - * @param nb notifier block, unused - * @param event Event being passed to driver to act upon - * @param p A pointer to our net device - **/ -static int -ixgb_notify_reboot(struct notifier_block *nb, unsigned long event, void *p) -{ - struct pci_dev *pdev = NULL; - - switch(event) { - case SYS_DOWN: - case SYS_HALT: - case SYS_POWER_OFF: - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { - if (pci_dev_driver(pdev) == &ixgb_driver) - ixgb_suspend(pdev, 3); - } - } - return NOTIFY_DONE; -} - -/** - * ixgb_suspend - driver suspend function called from notify. - * @param pdev pci driver structure used for passing to - * @param state power state to enter - **/ -static int -ixgb_suspend(struct pci_dev *pdev, uint32_t state) -{ - struct net_device *netdev = pci_get_drvdata(pdev); - struct ixgb_adapter *adapter = netdev->priv; - - netif_device_detach(netdev); - - if(netif_running(netdev)) - ixgb_down(adapter, TRUE); - - pci_save_state(pdev); - - state = (state > 0) ? 3 : 0; - pci_set_power_state(pdev, state); - msec_delay(200); - - return 0; -} - #ifdef CONFIG_NET_POLL_CONTROLLER /* * Polling 'interrupt' - used by things like netconsole to send skbs From mallikarjuna.chilakala@intel.com Thu Apr 28 19:05:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:05:05 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2517J025098 for ; Thu, 28 Apr 2005 19:05:01 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T24tdg001719; Fri, 29 Apr 2005 02:04:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T24slJ008837; Fri, 29 Apr 2005 02:04:55 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819045409564 ; Thu, 28 Apr 2005 19:04:54 -0700 Date: Thu, 28 Apr 2005 19:04:54 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 9/11] ixgb: Code optimization Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3173 Lines: 106 Code optimization Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -1822,7 +1822,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a struct pci_dev *pdev = adapter->pdev; struct ixgb_rx_desc *rx_desc, *next_rxd; struct ixgb_buffer *buffer_info, *next_buffer, *next2_buffer; - struct sk_buff *skb, *next_skb; uint32_t length; unsigned int i, j; boolean_t cleaned = FALSE; @@ -1832,6 +1831,8 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a buffer_info = &rx_ring->buffer_info[i]; while(rx_desc->status & IXGB_RX_DESC_STATUS_DD) { + struct sk_buff *skb, *next_skb; + u8 status; #ifdef CONFIG_IXGB_NAPI if(*work_done >= work_to_do) @@ -1839,7 +1840,9 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a (*work_done)++; #endif + status = rx_desc->status; skb = buffer_info->skb; + prefetch(skb->data); if(++i == rx_ring->count) i = 0; @@ -1864,7 +1835,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a length = le16_to_cpu(rx_desc->length); - if(unlikely(!(rx_desc->status & IXGB_RX_DESC_STATUS_EOP))) { + if(unlikely(!(status & IXGB_RX_DESC_STATUS_EOP))) { /* All receives must fit into a single buffer */ @@ -1872,12 +1835,7 @@ "length<%x>\n", length); dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - - rx_desc = next_rxd; - buffer_info = next_buffer; - continue; + goto rxdesc_done; } if (unlikely(rx_desc->errors @@ -1886,12 +1835,7 @@ IXGB_RX_DESC_ERRORS_RXE))) { dev_kfree_skb_irq(skb); - rx_desc->status = 0; - buffer_info->skb = NULL; - - rx_desc = next_rxd; - buffer_info = next_buffer; - continue; + goto rxdesc_done; } /* Good Receive */ @@ -1902,7 +1879,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a skb->protocol = eth_type_trans(skb, netdev); #ifdef CONFIG_IXGB_NAPI - if(adapter->vlgrp && (rx_desc->status & IXGB_RX_DESC_STATUS_VP)) { + if(adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special) & IXGB_RX_DESC_SPECIAL_VLAN_MASK); @@ -1910,7 +1879,7 @@ netif_receive_skb(skb); } #else /* CONFIG_IXGB_NAPI */ - if(adapter->vlgrp && (rx_desc->status & IXGB_RX_DESC_STATUS_VP)) { + if(adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) { vlan_hwaccel_rx(skb, adapter->vlgrp, le16_to_cpu(rx_desc->special) & IXGB_RX_DESC_SPECIAL_VLAN_MASK); @@ -1920,9 +1913,12 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a #endif /* CONFIG_IXGB_NAPI */ netdev->last_rx = jiffies; +rxdesc_done: + /* clean up descriptor, might be written over by hw */ rx_desc->status = 0; buffer_info->skb = NULL; + /* use prefetched values */ rx_desc = next_rxd; buffer_info = next_buffer; } From mallikarjuna.chilakala@intel.com Thu Apr 28 19:05:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:05:20 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T25I7J025385 for ; Thu, 28 Apr 2005 19:05:18 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T25CEf022946; Fri, 29 Apr 2005 02:05:12 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T25CP5026996; Fri, 29 Apr 2005 02:05:12 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819051210458 ; Thu, 28 Apr 2005 19:05:12 -0700 Date: Thu, 28 Apr 2005 19:05:12 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 10/11] ixgb: Fixed msec_delay in osdep to use msleep Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 762 Lines: 21 Fixed msec_delay in osdep to use msleep Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h --- net-drivers-2.6/drivers/net/ixgb/ixgb_osdep.h 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_osdep.h 2005-04-05 23:06:38.300930168 -0700 @@ -45,8 +45,7 @@ /* Don't mdelay in interrupt context! */ \ BUG(); \ } else { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout((x * HZ)/1000 + 2); \ + msleep(x); \ } } while(0) #endif From mallikarjuna.chilakala@intel.com Thu Apr 28 19:05:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:05:41 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T25c7J025811 for ; Thu, 28 Apr 2005 19:05:38 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T25X5P008346; Fri, 29 Apr 2005 02:05:33 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T25QoY007974; Fri, 29 Apr 2005 02:05:33 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819053205037 ; Thu, 28 Apr 2005 19:05:32 -0700 Date: Thu, 28 Apr 2005 19:05:32 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 11/11] ixgb: Driver version, white space, comments, device id Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1906 Lines: 52 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/ixgb/ixgb_main.c net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c --- net-drivers-2.6/drivers/net/ixgb/ixgb_main.c 2005-04-05 23:06:36.332229456 -0700 +++ net-drivers-2.6/drivers/net/ixgb.new/ixgb_main.c 2005-04-05 23:06:38.283932752 -0700 @@ -47,7 +47,7 @@ char ixgb_driver_string[] = "Intel(R) PR #else #define DRIVERNAPI "-NAPI" #endif -char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_driver_version[] = "1.0.95-k2"DRIVERNAPI; char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table @@ -103,6 +103,7 @@ static int ixgb_change_mtu(struct net_de static int ixgb_set_mac(struct net_device *netdev, void *p); static irqreturn_t ixgb_intr(int irq, void *data, struct pt_regs *regs); static boolean_t ixgb_clean_tx_irq(struct ixgb_adapter *adapter); + #ifdef CONFIG_IXGB_NAPI static int ixgb_clean(struct net_device *netdev, int *budget); static boolean_t ixgb_clean_rx_irq(struct ixgb_adapter *adapter, @@ -1253,6 +1254,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter unsigned int nr_frags = skb_shinfo(skb)->nr_frags; unsigned int f; + len -= skb->data_len; i = tx_ring->next_to_use; @@ -1857,7 +1833,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a next_skb = next_buffer->skb; prefetch(next_skb); - cleaned = TRUE; pci_unmap_single(pdev, @@ -2108,6 +2095,7 @@ ixgb_restore_vlan(struct ixgb_adapter *a static void ixgb_netpoll(struct net_device *dev) { struct ixgb_adapter *adapter = dev->priv; + disable_irq(adapter->pdev->irq); ixgb_intr(adapter->pdev->irq, dev, NULL); enable_irq(adapter->pdev->irq); From mallikarjuna.chilakala@intel.com Thu Apr 28 19:17:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:17:28 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2HQ7J028019 for ; Thu, 28 Apr 2005 19:17:26 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2HLEf024676; Fri, 29 Apr 2005 02:17:21 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2HIP5000730; Fri, 29 Apr 2005 02:17:21 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819172011248 ; Thu, 28 Apr 2005 19:17:20 -0700 Date: Thu, 28 Apr 2005 19:17:20 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 2/6] e100: Render e100 NAPI state machine Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 7238 Lines: 236 Render e100 NAPI state machine to be similar to the non-NAPI one. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 @@ -269,6 +269,12 @@ enum scb_status { rus_mask = 0x3C, }; +enum ru_state { + RU_SUSPENDED = 0, + RU_RUNNING = 1, + RU_UNINITIALIZED = -1, +}; + enum scb_stat_ack { stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, @@ -510,7 +515,7 @@ struct nic { struct rx *rx_to_use; struct rx *rx_to_clean; struct rfd blank_rfd; - int ru_running; + enum ru_state ru_running; spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; @@ -1204,7 +1210,9 @@ static void e100_update_stats(struct nic } } - e100_exec_cmd(nic, cuc_dump_reset, 0); + + if(e100_exec_cmd(nic, cuc_dump_reset, 0)) + DPRINTK(TX_ERR, DEBUG, "exec cuc_dump_reset failed\n"); } static void e100_adjust_adaptive_ifs(struct nic *nic, int speed, int duplex) @@ -1298,7 +1306,8 @@ static int e100_xmit_frame(struct sk_buf /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang. Issue a NOP command followed by a 1us delay before issuing the Tx command. */ - e100_exec_cmd(nic, cuc_nop, 0); + if(e100_exec_cmd(nic, cuc_nop, 0)) + DPRINTK(TX_ERR, DEBUG, "exec cuc_nop failed\n"); udelay(1); } @@ -1416,12 +1425,18 @@ static int e100_alloc_cbs(struct nic *ni return 0; } -static inline void e100_start_receiver(struct nic *nic) +static inline void e100_start_receiver(struct nic *nic, struct rx *rx) { + if(!nic->rxs) return; + if(RU_SUSPENDED != nic->ru_running) return; + + /* handle init time starts */ + if(!rx) rx = nic->rxs; + /* (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; + if(rx->skb) { + e100_exec_cmd(nic, ruc_start, rx->dma_addr); + nic->ru_running = RU_RUNNING; } } @@ -1438,6 +1453,13 @@ static inline int e100_rx_alloc_skb(stru rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data, RFD_BUF_LEN, PCI_DMA_BIDIRECTIONAL); + if(pci_dma_mapping_error(rx->dma_addr)) { + dev_kfree_skb_any(rx->skb); + rx->skb = 0; + rx->dma_addr = 0; + return -ENOMEM; + } + /* Link the RFD to end of RFA by linking previous RFD to * this one, and clearing EL bit of previous. */ if(rx->prev->skb) { @@ -1472,7 +1494,7 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -ENODATA; /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1483,6 +1505,10 @@ static inline int e100_rx_indicate(struc pci_unmap_single(nic->pdev, rx->dma_addr, RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + /* this allows for a fast restart without re-enabling interrupts */ + if(le16_to_cpu(rfd->command) & cb_el) + nic->ru_running = RU_SUSPENDED; + /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); skb_put(skb, actual_size); @@ -1515,20 +1541,45 @@ static inline void e100_rx_clean(struct unsigned int work_to_do) { struct rx *rx; + int restart_required = 0; + struct rx *rx_to_start = NULL; + + /* are we already rnr? then pay attention!!! this ensures that + * the state machine progression never allows a start with a + * partially cleaned list, avoiding a race between hardware + * and rx_to_clean when in NAPI mode */ + if(RU_SUSPENDED == nic->ru_running) + restart_required = 1; /* Indicate newly arrived packets */ 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)) + int err = e100_rx_indicate(nic, rx, work_done, work_to_do); + if(-EAGAIN == err) { + /* hit quota so have more work to do, restart once + * cleanup is complete */ + restart_required = 0; + break; + } else if(-ENODATA == err) break; /* No more to clean */ } + /* save our starting point as the place we'll restart the receiver */ + if(restart_required) + rx_to_start = nic->rx_to_clean; + /* Alloc new skbs to refill list */ 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) */ } - e100_start_receiver(nic); + if(restart_required) { + // ack the rnr? + writeb(stat_ack_rnr, &nic->csr->scb.stat_ack); + e100_start_receiver(nic, rx_to_start); + if(work_done) + (*work_done)++; + } } static void e100_rx_clean_list(struct nic *nic) @@ -1536,6 +1587,8 @@ static void e100_rx_clean_list(struct ni struct rx *rx; unsigned int i, count = nic->params.rfds.count; + nic->ru_running = RU_UNINITIALIZED; + if(nic->rxs) { for(rx = nic->rxs, i = 0; i < count; rx++, i++) { if(rx->skb) { @@ -1549,7 +1602,6 @@ static void e100_rx_clean_list(struct ni } nic->rx_to_use = nic->rx_to_clean = NULL; - nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) @@ -1558,6 +1610,7 @@ static int e100_rx_alloc_list(struct nic unsigned int i, count = nic->params.rfds.count; nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = RU_UNINITIALIZED; if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; @@ -1573,6 +1626,7 @@ static int e100_rx_alloc_list(struct nic } nic->rx_to_use = nic->rx_to_clean = nic->rxs; + nic->ru_running = RU_SUSPENDED; return 0; } @@ -1594,7 +1648,7 @@ static irqreturn_t e100_intr(int irq, vo /* We hit Receive No Resource (RNR); restart RU after cleaning */ if(stat_ack & stat_ack_rnr) - nic->ru_running = 0; + nic->ru_running = RU_SUSPENDED; e100_disable_irq(nic); netif_rx_schedule(netdev); @@ -1684,7 +1700,7 @@ static int e100_up(struct nic *nic) if((err = e100_hw_init(nic))) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) @@ -1759,7 +1813,7 @@ static int e100_loopback_test(struct nic mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, BMCR_LOOPBACK); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; @@ -2233,6 +2287,7 @@ static int __devinit e100_probe(struct p e100_get_defaults(nic); + /* locks must be initialized before calling hw_reset */ spin_lock_init(&nic->cb_lock); spin_lock_init(&nic->cmd_lock); @@ -2348,7 +2355,8 @@ static int e100_resume(struct pci_dev *p pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); - e100_hw_init(nic); + if(e100_hw_init(nic)) + DPRINTK(HW, ERR, "e100_hw_init failed\n"); netif_device_attach(netdev); if(netif_running(netdev)) From mallikarjuna.chilakala@intel.com Thu Apr 28 19:17:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:17:51 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2Hn7J028255 for ; Thu, 28 Apr 2005 19:17:49 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2HgTs003151; Fri, 29 Apr 2005 02:17:42 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2HcP5000889; Fri, 29 Apr 2005 02:17:42 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819174222127 ; Thu, 28 Apr 2005 19:17:42 -0700 Date: Thu, 28 Apr 2005 19:17:42 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 3/6] e100: Synchronize interface link state with poll routine Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1314 Lines: 38 Synchronize interface link state with e100 poll routine Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 @@ -1743,8 +1743,11 @@ static int e100_up(struct nic *nic) if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) goto err_no_irq; - e100_enable_irq(nic); netif_wake_queue(nic->netdev); + netif_poll_enable(nic->netdev); + /* enable ints _after_ enabling poll, preventing a race between + * disable ints+schedule */ + e100_enable_irq(nic); return 0; err_no_irq: @@ -1758,11 +1758,13 @@ err_rx_clean_list: static void e100_down(struct nic *nic) { + /* wait here for poll to complete */ + netif_poll_disable(nic->netdev); + netif_stop_queue(nic->netdev); e100_hw_reset(nic); free_irq(nic->pdev->irq, nic->netdev); del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); - netif_stop_queue(nic->netdev); e100_clean_cbs(nic); e100_rx_clean_list(nic); } From mallikarjuna.chilakala@intel.com Thu Apr 28 19:17:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:17:07 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2H57J027990 for ; Thu, 28 Apr 2005 19:17:05 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2GwmZ009432; Fri, 29 Apr 2005 02:16:58 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2GwoS016283; Fri, 29 Apr 2005 02:16:58 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819165805785 ; Thu, 28 Apr 2005 19:16:58 -0700 Date: Thu, 28 Apr 2005 19:16:58 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 1/6] e100: Execute tx_timeout task outside interrupt context Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1532 Lines: 44 Execute tx_timeout task outside the interrupt context Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 @@ -539,6 +539,7 @@ struct nic { struct timer_list watchdog; struct timer_list blink_timer; struct mii_if_info mii; + struct work_struct tx_timeout_task; enum loopback loopback; struct mem *mem; @@ -1716,6 +1717,15 @@ static void e100_tx_timeout(struct net_d { struct nic *nic = netdev_priv(netdev); + /* Reset outside of interrupt context, to avoid request_irq + * in interrupt context */ + schedule_work(&nic->tx_timeout_task); +} + +static void e100_tx_timeout_task(struct net_device *netdev) +{ + struct nic *nic = netdev_priv(netdev); + DPRINTK(TX_ERR, DEBUG, "scb.status=0x%02X\n", readb(&nic->csr->scb.status)); e100_down(netdev_priv(netdev)); @@ -2240,6 +2250,9 @@ static int __devinit e100_probe(struct p nic->blink_timer.function = e100_blink_led; nic->blink_timer.data = (unsigned long)nic; + INIT_WORK(&nic->tx_timeout_task, + (void (*)(void *))e100_tx_timeout_task, netdev); + if((err = e100_alloc(nic))) { DPRINTK(PROBE, ERR, "Cannot alloc driver memory, aborting.\n"); goto err_out_iounmap; From mallikarjuna.chilakala@intel.com Thu Apr 28 19:16:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:16:54 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2Gq7J027961 for ; Thu, 28 Apr 2005 19:16:52 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2Gk14019790; Fri, 29 Apr 2005 02:16:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2GclL014312; Fri, 29 Apr 2005 02:16:46 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819164610953 ; Thu, 28 Apr 2005 19:16:46 -0700 Date: Thu, 28 Apr 2005 19:16:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 0/6] e100: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 520 Lines: 12 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1. Execute tx_timeout task outside the interrupt context 2. Render e100 NAPI state machine to be similar to the non-NAPI one. 3. Synchronize interface link state with e100 poll routine. 4. Fix wake on lan related issues 5. Performance optimizations to e100 Tx path 6. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Thu Apr 28 19:18:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:18:04 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2I27J028453 for ; Thu, 28 Apr 2005 19:18:02 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2HtEf024772; Fri, 29 Apr 2005 02:17:55 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2HcPF000889; Fri, 29 Apr 2005 02:17:55 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819175422145 ; Thu, 28 Apr 2005 19:17:54 -0700 Date: Thu, 28 Apr 2005 19:17:54 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 4/6] e100: Fix Wake on lan related issues Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2904 Lines: 97 Fix Wake on lan related issues Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e100.c net-drivers-2.6/drivers/net/e100.c.new --- net-drivers-2.6/drivers/net/e100.c 2005-04-07 03:22:36.805273784 -0700 +++ net-drivers-2.6/drivers/net/e100.c.new 2005-04-07 03:22:37.251205992 -0700 @@ -971,7 +971,8 @@ static void e100_configure(struct nic *n if(nic->flags & multicast_all) config->multicast_all = 0x1; /* 1=accept, 0=no */ - if(!(nic->flags & wol_magic)) + /* disable WoL when up */ + if(netif_running(nic->netdev) || !(nic->flags & wol_magic)) config->magic_packet_disable = 0x1; /* 1=off, 0=on */ if(nic->mac >= mac_82558_D101_A4) { @@ -1718,6 +1719,7 @@ static int e100_change_mtu(struct net_de return 0; } +#ifdef CONFIG_PM static int e100_asf(struct nic *nic) { /* ASF can be enabled from eeprom */ @@ -1726,6 +1728,7 @@ static int e100_asf(struct nic *nic) !(nic->eeprom[eeprom_config_asf] & eeprom_gcl) && ((nic->eeprom[eeprom_smbus_addr] & 0xFF) != 0xFE)); } +#endif static int e100_up(struct nic *nic) { @@ -1938,7 +1941,6 @@ static int e100_set_wol(struct net_devic else nic->flags &= ~wol_magic; - pci_enable_wake(nic->pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); e100_exec_cb(nic, NULL, e100_configure); return 0; @@ -2336,7 +2338,8 @@ static int __devinit e100_probe(struct p (nic->eeprom[eeprom_id] & eeprom_id_wol)) nic->flags |= wol_magic; - pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); + /* ack any pending wake events, disable PME */ + pci_enable_wake(pdev, 0, 0); strcpy(netdev->name, "eth%d"); if((err = register_netdev(netdev))) { @@ -2408,6 +2347,8 @@ static int e100_resume(struct pci_dev *p pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); + /* ack any pending wake events, disable PME */ + pci_enable_wake(pdev, 0, 0); if(e100_hw_init(nic)) DPRINTK(HW, ERR, "e100_hw_init failed\n"); @@ -2419,6 +2424,21 @@ static int e100_resume(struct pci_dev *p } #endif + +static void e100_shutdown(struct device *dev) +{ + struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); + struct net_device *netdev = pci_get_drvdata(pdev); + struct nic *nic = netdev_priv(netdev); + +#ifdef CONFIG_PM + pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); +#else + pci_enable_wake(pdev, 0, nic->flags & (wol_magic)); +#endif +} + + static struct pci_driver e100_driver = { .name = DRV_NAME, .id_table = e100_id_table, @@ -2428,6 +2448,11 @@ static struct pci_driver e100_driver = { .suspend = e100_suspend, .resume = e100_resume, #endif + + .driver = { + .shutdown = e100_shutdown, + } + }; static int __init e100_init_module(void) From mallikarjuna.chilakala@intel.com Thu Apr 28 19:41:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:41:58 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2ft7J000337 for ; Thu, 28 Apr 2005 19:41:55 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2flEf029499; Fri, 29 Apr 2005 02:41:47 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2fbP7016149; Fri, 29 Apr 2005 02:41:47 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819414623688 ; Thu, 28 Apr 2005 19:41:46 -0700 Date: Thu, 28 Apr 2005 19:41:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 10/16] e1000: Implement a workaround for 82546 errata 10 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1808 Lines: 40 Implement 82546 errata 10 -- first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -1777,6 +1777,15 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif + /* work-around for errata 10 and it applies + * to all controllers in PCI-X mode + * The fix is to make sure that the first descriptor of a + * packet is smaller than 2048 - 16 - 16 (or 2016) bytes + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (size > 2015) && count == 0)) + size = 2015; + /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ if(unlikely(adapter->pcix_82544 && @@ -1979,6 +1988,13 @@ e1000_xmit_frame(struct sk_buff *skb, st if(adapter->pcix_82544) count++; + /* work-around for errata 10 and it applies to all controllers + * in PCI-X mode, so add one more descriptor to the count + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (len > 2015))) + count++; + nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, From mallikarjuna.chilakala@intel.com Thu Apr 28 19:41:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:41:36 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2fX7J032745 for ; Thu, 28 Apr 2005 19:41:34 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2fSmZ017518; Fri, 29 Apr 2005 02:41:28 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2fNoW004021; Fri, 29 Apr 2005 02:41:28 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819412707331 ; Thu, 28 Apr 2005 19:41:27 -0700 Date: Thu, 28 Apr 2005 19:41:28 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 9/16] e1000: e1000 stops working after resume Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 935 Lines: 22 e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -3172,9 +3172,8 @@ e1000_resume(struct pci_dev *pdev) pci_set_power_state(pdev, 0); pci_restore_state(pdev); - ret = pci_enable_device(pdev); - if (pdev->is_busmaster) - pci_set_master(pdev); + ret = pci_enable_device(pdev); + pci_set_master(pdev); pci_enable_wake(pdev, 3, 0); pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */ From mallikarjuna.chilakala@intel.com Thu Apr 28 19:42:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:42:12 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2gA7J000462 for ; Thu, 28 Apr 2005 19:42:10 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2g5Ef029579; Fri, 29 Apr 2005 02:42:05 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2fxPB016417; Fri, 29 Apr 2005 02:42:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819420423713 ; Thu, 28 Apr 2005 19:42:04 -0700 Date: Thu, 28 Apr 2005 19:42:04 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 11/16] e1000:Removed redundant statement in e1000_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 734 Lines: 18 Removed redundant statement in e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -2436,7 +2436,6 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc->lower.data = 0; tx_desc->upper.data = 0; - cleaned = (i == eop); if(unlikely(++i == tx_ring->count)) i = 0; } From mallikarjuna.chilakala@intel.com Thu Apr 28 19:44:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:44:33 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2iU7J001973 for ; Thu, 28 Apr 2005 19:44:31 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2iPmZ018432; Fri, 29 Apr 2005 02:44:25 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2iPoS006464; Fri, 29 Apr 2005 02:44:25 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819442507518 ; Thu, 28 Apr 2005 19:44:25 -0700 Date: Thu, 28 Apr 2005 19:44:25 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 15/16] e1000:Adjust flow control watermarks for Jumbo Frames Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1800 Lines: 50 Adjust flow control watermarks for Jumbo Frames Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -409,7 +409,10 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { + struct net_device *netdev = adapter->netdev; uint32_t pba, manc; + uint16_t fc_high_water_mark = E1000_FC_HIGH_DIFF; + uint16_t fc_low_water_mark = E1000_FC_LOW_DIFF; /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. @@ -428,6 +428,16 @@ break; } + if((adapter->hw.mac_type != e1000_82573) && + (adapter->rx_buffer_len > E1000_RXBUFFER_8192)) { + pba -= 8; /* allocate more FIFO for Tx */ + /* send an XOFF when there is enough space in the + * Rx FIFO to hold one extra full size Rx packet + */ + fc_high_water_mark = netdev->mtu + ENET_HEADER_SIZE + + ETHERNET_FCS_SIZE + 1; + fc_low_water_mark = fc_high_water_mark + 8; + } if(adapter->hw.mac_type == e1000_82547) { @@ -442,9 +442,9 @@ /* flow control settings */ adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - - E1000_FC_HIGH_DIFF; + fc_high_water_mark; adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - - E1000_FC_LOW_DIFF; + fc_low_water_mark; adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME; adapter->hw.fc_send_xon = 1; adapter->hw.fc = adapter->hw.original_fc; From mallikarjuna.chilakala@intel.com Thu Apr 28 19:43:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:43:36 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2hX7J001499 for ; Thu, 28 Apr 2005 19:43:34 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2hS5P022305; Fri, 29 Apr 2005 02:43:28 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2hBPF017168; Fri, 29 Apr 2005 02:43:28 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819432823805 ; Thu, 28 Apr 2005 19:43:28 -0700 Date: Thu, 28 Apr 2005 19:43:28 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 12/16] e1000: Modified e1000_clean:: exit poll Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 22 Modified e1000_clean:: exit poll if no Tx and work_done == 0 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -2368,9 +2368,8 @@ e1000_clean(struct net_device *netdev, i *budget -= work_done; netdev->quota -= work_done; - /* if no Tx and not enough Rx work done, exit the polling mode */ - if((!tx_cleaned && (work_done < work_to_do)) || - !netif_running(netdev)) { + /* If no Tx and no Rx work done, exit the polling mode */ + if ((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; From mallikarjuna.chilakala@intel.com Thu Apr 28 19:44:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:44:22 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2iK7J001928 for ; Thu, 28 Apr 2005 19:44:20 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2iFTs019751; Fri, 29 Apr 2005 02:44:15 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2iFP3017736; Fri, 29 Apr 2005 02:44:15 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819441417992 ; Thu, 28 Apr 2005 19:44:14 -0700 Date: Thu, 28 Apr 2005 19:44:14 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 14/16] e1000:Fix Packet Buffer Allocation logic for 82547_rev_2 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 738 Lines: 18 Fix Packet Buffer Allocation logic for 82547_rev_2 controller Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -417,6 +417,7 @@ e1000_down(struct e1000_adapter *adapter switch (adapter->hw.mac_type) { case e1000_82547: + case e1000_82547_rev_2: pba = E1000_PBA_30K; break; case e1000_82573: From mallikarjuna.chilakala@intel.com Thu Apr 28 19:44:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:44:57 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2ir7J002192 for ; Thu, 28 Apr 2005 19:44:53 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2il5P022676; Fri, 29 Apr 2005 02:44:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2iiP5018024; Fri, 29 Apr 2005 02:44:47 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819444613145 ; Thu, 28 Apr 2005 19:44:46 -0700 Date: Thu, 28 Apr 2005 19:44:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 16/16] e1000:Driver version,white space,comments,device id Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 25308 Lines: 682 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.6/drivers/net/e1000/e1000_ethtool.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_ethtool.c 2005-04-11 02:22:28.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -69,6 +69,7 @@ static const struct e1000_stats e1000_gs { "rx_crc_errors", E1000_STAT(net_stats.rx_crc_errors) }, { "rx_frame_errors", E1000_STAT(net_stats.rx_frame_errors) }, { "rx_fifo_errors", E1000_STAT(net_stats.rx_fifo_errors) }, + { "rx_no_buffer_count", E1000_STAT(stats.rnbc) }, { "rx_missed_errors", E1000_STAT(net_stats.rx_missed_errors) }, { "tx_aborted_errors", E1000_STAT(net_stats.tx_aborted_errors) }, { "tx_carrier_errors", E1000_STAT(net_stats.tx_carrier_errors) }, @@ -593,7 +594,7 @@ e1000_set_ringparam(struct net_device *n tx_old = adapter->tx_ring; rx_old = adapter->rx_ring; - if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) + if((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) return -EINVAL; if(netif_running(adapter->netdev)) @@ -784,8 +785,8 @@ e1000_intr_test(struct e1000_adapter *ad /* Hook up test interrupt handler just for this test */ if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) { shared_int = FALSE; - } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, - netdev->name, netdev)){ + } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, + netdev->name, netdev)){ *data = 1; return -1; } @@ -842,10 +843,8 @@ e1000_intr_test(struct e1000_adapter *ad * test failed. */ adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, - (~mask & 0x00007FFF)); - E1000_WRITE_REG(&adapter->hw, ICS, - (~mask & 0x00007FFF)); + E1000_WRITE_REG(&adapter->hw, IMC, ~mask & 0x00007FFF); + E1000_WRITE_REG(&adapter->hw, ICS, ~mask & 0x00007FFF); msec_delay(10); if(adapter->test_icr) { @@ -1010,7 +1009,7 @@ e1000_setup_desc_rings(struct e1000_adap struct e1000_rx_desc *rx_desc = E1000_RX_DESC(*rxdr, i); struct sk_buff *skb; - if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, + if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, GFP_KERNEL))) { ret_val = 6; goto err_nomem; @@ -1387,13 +1386,12 @@ static int e1000_link_test(struct e1000_adapter *adapter, uint64_t *data) { *data = 0; - if (adapter->hw.media_type == e1000_media_type_internal_serdes) { int i = 0; adapter->hw.serdes_link_down = TRUE; - /* on some blade server designs link establishment */ - /* could take as long as 2-3 minutes. */ + /* On some blade server designs, link establishment + * could take as long as 2-3 minutes */ do { e1000_check_for_link(&adapter->hw); if (adapter->hw.serdes_link_down == FALSE) @@ -1401,7 +1373,7 @@ e1000_link_test(struct e1000_adapter *ad msec_delay(20); } while (i++ < 3750); - *data = 1; + *data = 1; } else { e1000_check_for_link(&adapter->hw); if(adapter->hw.autoneg) /* if auto_neg is set wait for it */ diff -up net-drivers-2.6/drivers/net/e1000/e1000.h net-drivers-2.6/drivers/net/e1000.new/e1000.h --- net-drivers-2.6/drivers/net/e1000/e1000.h 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000.h 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -139,9 +138,9 @@ struct e1000_adapter; /* How many Rx Buffers do we bundle into one write to the hardware ? */ #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ -#define AUTO_ALL_MODES 0 -#define E1000_EEPROM_82544_APM 0x0004 -#define E1000_EEPROM_APME 0x0400 +#define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0400 +#define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE /* Switch to override PHY master/slave setting */ diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.c net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.6/drivers/net/e1000/e1000_hw.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.c 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -144,7 +144,6 @@ e1000_phy_init_script(struct e1000_hw *h DEBUGFUNC("e1000_phy_init_script"); - if(hw->phy_init_script) { msec_delay(20); diff -up net-drivers-2.6/drivers/net/e1000/e1000_hw.h net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.6/drivers/net/e1000/e1000_hw.h 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_hw.h 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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,33 +29,9 @@ #include "e1000.h" /* Change Log - * 5.3.12 6/7/04 - * - kcompat NETIF_MSG for older kernels (2.4.9) - * - if_mii support and associated kcompat for older kernels - * - More errlogging support from Jon Mason - * - Fix TSO issues on PPC64 machines -- Jon Mason - * - * 5.7.1 12/16/04 - * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This - * fix was removed as it caused system instability. The suspected cause of - * this is the called to e1000_irq_disable in e1000_intr. Inlined the - * required piece of e1000_irq_disable into e1000_intr - Anton Blanchard - * 5.7.0 12/10/04 - * - include fix to the condition that determines when to quit NAPI - Robert Olsson - * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down - * 5.6.5 11/01/04 - * - Enabling NETIF_F_SG without checksum offload is illegal - - John Mason - * 5.6.3 10/26/04 - * - Remove redundant initialization - Jamal Hadi - * - Reset buffer_info->dma in tx resource cleanup logic - * 5.6.2 10/12/04 - * - Avoid filling tx_ring completely - shemminger@osdl.org - * - Replace schedule_timeout() with msleep()/msleep_interruptible() - - * nacc@us.ibm.com - * - Sparse cleanup - shemminger@osdl.org - * - Fix tx resource cleanup logic - * - LLTX support - ak@suse.de and hadi@cyberus.ca + * 6.0.44+ 2/15/05 + * o applied Anton's patch to resolve tx hang in hardware + * o Applied Andrew Mortons patch - e1000 stops working after resume */ char e1000_driver_name[] = "e1000"; @@ -65,8 +110,8 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -#define DRV_VERSION "5.7.6-k2"DRIVERNAPI -char e1000_driver_version[] = DRV_VERSION; +#define DRV_VERSION "6.0.54-k2"DRIVERNAPI +char e1000_driver_version[] = DRV_VERSION; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -96,6 +72,7 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x1017), INTEL_E1000_ETHERNET_DEVICE(0x1018), INTEL_E1000_ETHERNET_DEVICE(0x1019), + INTEL_E1000_ETHERNET_DEVICE(0x101A), INTEL_E1000_ETHERNET_DEVICE(0x101D), INTEL_E1000_ETHERNET_DEVICE(0x101E), INTEL_E1000_ETHERNET_DEVICE(0x1026), @@ -110,6 +87,9 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x107B), INTEL_E1000_ETHERNET_DEVICE(0x107C), INTEL_E1000_ETHERNET_DEVICE(0x108A), + INTEL_E1000_ETHERNET_DEVICE(0x108B), + INTEL_E1000_ETHERNET_DEVICE(0x108C), + INTEL_E1000_ETHERNET_DEVICE(0x1099), /* required last entry */ {0,} }; @@ -350,8 +351,11 @@ e1000_up(struct e1000_adapter *adapter) #endif if((err = request_irq(adapter->pdev->irq, &e1000_intr, SA_SHIRQ | SA_SAMPLE_RANDOM, - netdev->name, netdev))) + netdev->name, netdev))) { + DPRINTK(PROBE, ERR, + "Unable to allocate interrupt Error: %d\n", err); return err; + } mod_timer(&adapter->watchdog_timer, jiffies); @@ -636,7 +619,7 @@ e1000_probe(struct pci_dev *pdev, /* copy the MAC address out of the EEPROM */ - if (e1000_read_mac_addr(&adapter->hw)) + if(e1000_read_mac_addr(&adapter->hw)) DPRINTK(PROBE, ERR, "EEPROM Read Error\n"); memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len); @@ -963,12 +946,10 @@ e1000_check_64k_bound(struct e1000_adapt unsigned long begin = (unsigned long) start; unsigned long end = begin + len; - /* first rev 82545 and 82546 need to not allow any memory - * write location to cross a 64k boundary due to errata 23 */ + /* First rev 82545 and 82546 need to not allow any memory + * write location to cross 64k boundary due to errata 23 */ if (adapter->hw.mac_type == e1000_82545 || - adapter->hw.mac_type == e1000_82546 ) { - - /* check buffer doesn't cross 64kB */ + adapter->hw.mac_type == e1000_82546) { return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; } @@ -992,8 +973,8 @@ e1000_setup_tx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * txdr->count; txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Transmit descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -1006,22 +925,22 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { setup_tx_desc_die: - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the transmit descriptor ring\n"); return -ENOMEM; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { void *olddesc = txdr->desc; dma_addr_t olddma = txdr->dma; - DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", - txdr->size, txdr->desc); - /* try again, without freeing the previous */ + DPRINTK(TX_ERR, ERR, "txdr align check failed: %u bytes " + "at %p\n", txdr->size, txdr->desc); + /* Try again, without freeing the previous */ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); - /* failed allocation, critial failure */ if(!txdr->desc) { + /* Failed allocation, critical failure */ pci_free_consistent(pdev, txdr->size, olddesc, olddma); goto setup_tx_desc_die; } @@ -1028,16 +925,16 @@ if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { /* give up */ - pci_free_consistent(pdev, txdr->size, - txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, txdr->desc, + txdr->dma); pci_free_consistent(pdev, txdr->size, olddesc, olddma); DPRINTK(PROBE, ERR, - "Unable to Allocate aligned Memory for the Transmit" - " descriptor ring\n"); + "Unable to allocate aligned memory " + "for the transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } else { - /* free old, move on with the new one since its okay */ + /* Free old allocation, new allocation was successful */ pci_free_consistent(pdev, txdr->size, olddesc, olddma); } } @@ -1144,8 +1058,8 @@ e1000_setup_rx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * rxdr->count; rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Recieve descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the receive descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -1185,25 +1058,24 @@ if(!rxdr->desc) { setup_rx_desc_die: - DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the receive descriptor ring\n"); return -ENOMEM; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { void *olddesc = rxdr->desc; dma_addr_t olddma = rxdr->dma; - DPRINTK(RX_ERR,ERR, - "rxdr align check failed: %u bytes at %p\n", - rxdr->size, rxdr->desc); - /* try again, without freeing the previous */ + DPRINTK(RX_ERR, ERR, "rxdr align check failed: %u bytes " + "at %p\n", rxdr->size, rxdr->desc); + /* Try again, without freeing the previous */ rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); - /* failed allocation, critial failure */ if(!rxdr->desc) { + /* Failed allocation, critical failure */ pci_free_consistent(pdev, rxdr->size, olddesc, olddma); goto setup_rx_desc_die; } @@ -1210,18 +1058,18 @@ if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { /* give up */ - pci_free_consistent(pdev, rxdr->size, - rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, rxdr->desc, + rxdr->dma); pci_free_consistent(pdev, rxdr->size, olddesc, olddma); - DPRINTK(PROBE, ERR, - "Unable to Allocate aligned Memory for the" - " Receive descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate aligned memory " + "for the receive descriptor ring\n"); vfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); return -ENOMEM; } else { - /* free old, move on with the new one since its okay */ + /* Free old allocation, new allocation was successful */ pci_free_consistent(pdev, rxdr->size, olddesc, olddma); } } @@ -1234,7 +1123,7 @@ setup_rx_desc_die: } /** - * e1000_setup_rctl - configure the receive control register + * e1000_setup_rctl - configure the receive control registers * @adapter: Board private structure **/ @@ -1426,13 +1406,11 @@ static inline void e1000_unmap_and_free_tx_resource(struct e1000_adapter *adapter, struct e1000_buffer *buffer_info) { - struct pci_dev *pdev = adapter->pdev; - if(buffer_info->dma) { - pci_unmap_page(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_TODEVICE); + pci_unmap_page(adapter->pdev, + buffer_info->dma, + buffer_info->length, + PCI_DMA_TODEVICE); buffer_info->dma = 0; } if(buffer_info->skb) { @@ -1457,7 +1435,7 @@ e1000_clean_tx_ring(struct e1000_adapter /* Free all the Tx ring sk_buffs */ if (likely(adapter->previous_buffer_info.skb != NULL)) { - e1000_unmap_and_free_tx_resource(adapter, + e1000_unmap_and_free_tx_resource(adapter, &adapter->previous_buffer_info); } @@ -1659,15 +1637,15 @@ e1000_set_multi(struct net_device *netde struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; struct dev_mc_list *mc_ptr; + unsigned long flags; uint32_t rctl; uint32_t hash_value; int i; - unsigned long flags; - - /* Check for Promiscuous and All Multicast modes */ spin_lock_irqsave(&adapter->tx_lock, flags); + /* Check for Promiscuous and All Multicast modes */ + rctl = E1000_READ_REG(hw, RCTL); if(netdev->flags & IFF_PROMISC) { @@ -1874,7 +1852,7 @@ e1000_watchdog_task(struct e1000_adapter /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Force detection of hung controller every watchdog period*/ + /* Force detection of hung controller every watchdog period */ adapter->detect_tx_hung = TRUE; /* Reset the timer */ @@ -2255,7 +2233,7 @@ e1000_xmit_frame(struct sk_buff *skb, st #ifdef NETIF_F_TSO mss = skb_shinfo(skb)->tso_size; - /* The controller does a simple calculation to + /* The controller does a simple calculation to * make sure there is enough room in the FIFO before * initiating the DMA for each buffer. The calc is: * 4 = ceil(buffer len/mss). To make sure we don't @@ -2268,7 +2246,7 @@ e1000_xmit_frame(struct sk_buff *skb, st if((mss) || (skb->ip_summed == CHECKSUM_HW)) count++; - count++; /* for sentinel desc */ + count++; #else if(skb->ip_summed == CHECKSUM_HW) count++; @@ -2658,7 +2315,7 @@ e1000_intr(int irq, void *data, struct p */ if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ atomic_inc(&adapter->irq_sem); - E1000_WRITE_REG(&adapter->hw, IMC, ~0); + E1000_WRITE_REG(hw, IMC, ~0); } for(i = 0; i < E1000_MAX_INTR; i++) @@ -2686,7 +2355,7 @@ e1000_clean(struct net_device *netdev, i int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; - + tx_cleaned = e1000_clean_tx_irq(adapter); adapter->clean_rx(adapter, &work_done, work_to_do); @@ -2776,9 +2443,9 @@ e1000_clean_tx_irq(struct e1000_adapter netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); - if(adapter->detect_tx_hung) { - /* detect a transmit hang in hardware, this serializes the + + /* Detect a transmit hang in hardware, this serializes the * check with the clearing of time_stamp and movement of i */ adapter->detect_tx_hung = FALSE; if (tx_ring->buffer_info[i].dma && @@ -2923,7 +2901,7 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ E1000_DBG("%s: Receive packet consumed multiple" - " buffers\n", netdev->name); + " buffers\n", netdev->name); dev_kfree_skb_irq(skb); goto next_desc; } @@ -3130,32 +2619,33 @@ e1000_alloc_rx_buffers(struct e1000_adap struct e1000_rx_desc *rx_desc; struct e1000_buffer *buffer_info; struct sk_buff *skb; - unsigned int i, bufsz; + unsigned int i; + unsigned int bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; - skb = dev_alloc_skb(bufsz); + if(unlikely(!skb)) { /* Better luck next round */ break; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { struct sk_buff *oldskb = skb; - DPRINTK(RX_ERR,ERR, - "skb align check failed: %u bytes at %p\n", - bufsz, skb->data); - /* try again, without freeing the previous */ + DPRINTK(RX_ERR, ERR, "skb align check failed: %u bytes " + "at %p\n", bufsz, skb->data); + /* Try again, without freeing the previous */ skb = dev_alloc_skb(bufsz); + /* Failed allocation, critical failure */ if (!skb) { dev_kfree_skb(oldskb); break; } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { /* give up */ dev_kfree_skb(skb); @@ -3162,11 +2619,10 @@ dev_kfree_skb(oldskb); break; /* while !buffer_info->skb */ } else { - /* move on with the new one */ + /* Use new allocation */ dev_kfree_skb(oldskb); } } - /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -3182,25 +3160,23 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); - /* fix for errata 23, cant cross 64kB boundary */ - if(!e1000_check_64k_bound(adapter, - (void *)(unsigned long)buffer_info->dma, - adapter->rx_buffer_len)) { - DPRINTK(RX_ERR,ERR, - "dma align check failed: %u bytes at %ld\n", - adapter->rx_buffer_len, (unsigned long)buffer_info->dma); - + /* Fix for errata 23, can't cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR, ERR, + "dma align check failed: %u bytes at %p\n", + adapter->rx_buffer_len, + (void *)(unsigned long)buffer_info->dma); dev_kfree_skb(skb); buffer_info->skb = NULL; - pci_unmap_single(pdev, - buffer_info->dma, + pci_unmap_single(pdev, buffer_info->dma, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); break; /* while !buffer_info->skb */ } - rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); @@ -3210,7 +3186,6 @@ e1000_alloc_rx_buffers(struct e1000_adap * applicable for weak-ordered memory model archs, * such as IA-64). */ wmb(); - E1000_WRITE_REG(&adapter->hw, RDT, i); } @@ -3483,9 +3458,10 @@ void e1000_pci_set_mwi(struct e1000_hw *hw) { struct e1000_adapter *adapter = hw->back; + int ret_val = pci_set_mwi(adapter->pdev); - int ret; - ret = pci_set_mwi(adapter->pdev); + if(ret_val) + DPRINTK(PROBE, ERR, "Error in setting MWI\n"); } void @@ -3643,8 +3619,7 @@ e1000_set_spd_dplx(struct e1000_adapter break; case SPEED_1000 + DUPLEX_HALF: /* not supported */ default: - DPRINTK(PROBE, ERR, - "Unsupported Speed/Duplexity configuration\n"); + DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n"); return -EINVAL; } return 0; @@ -3810,7 +3785,7 @@ e1000_resume(struct pci_dev *pdev) * the interrupt routine is executing. */ static void -e1000_netpoll (struct net_device *netdev) +e1000_netpoll(struct net_device *netdev) { struct e1000_adapter *adapter = netdev->priv; disable_irq(adapter->pdev->irq); diff -up net-drivers-2.6/drivers/net/e1000/e1000_osdep.h net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.6/drivers/net/e1000/e1000_osdep.h 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_osdep.h 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.6/drivers/net/e1000/e1000_param.c net-drivers-2.6/drivers/net/e1000.new/e1000_param.c --- net-drivers-2.6/drivers/net/e1000/e1000_param.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_param.c 2005-04-11 02:22:29.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -478,7 +532,6 @@ e1000_check_options(struct e1000_adapter DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); break; - case -1: default: e1000_validate_option(&adapter->itr, &opt, adapter); From mallikarjuna.chilakala@intel.com Thu Apr 28 19:51:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 19:51:40 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T2pa7J004088 for ; Thu, 28 Apr 2005 19:51:38 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2pVmZ020695; Fri, 29 Apr 2005 02:51:31 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2pMP7021234; Fri, 29 Apr 2005 02:51:31 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819513118345 ; Thu, 28 Apr 2005 19:51:31 -0700 Received: from fmsmsx403.amr.corp.intel.com ([132.233.42.207]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 19:51:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [RESEND][PATCH net-drivers-2.6 0/16] e1000: driver update Date: Thu, 28 Apr 2005 19:51:30 -0700 Message-ID: <331AD7BED1579543AD146F5A1A44D52506E6C95A@fmsmsx403.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RESEND][PATCH net-drivers-2.6 0/16] e1000: driver update thread-index: AcVMZNFw35T64xAnQg277UXL/nYANAAAL63A From: "Chilakala, Mallikarjuna" To: "Jeff Garzik" Cc: "netdev" X-OriginalArrivalTime: 29 Apr 2005 02:51:31.0606 (UTC) FILETIME=[59277360:01C54C66] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3T2pa7J004088 X-archive-position: 386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1027 Lines: 34 Unfortunately, all the patches seem to have been mangled when I had RESEND them yesterday. Not sure if my mailer did it, but it sure made them harder to handle. People monitoring on the netdev list are having problems, So I'm resending them with proper text server like PINE Please bare with me -Malli -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Thursday, April 28, 2005 7:40 PM To: Chilakala, Mallikarjuna Cc: netdev Subject: Re: [RESEND][PATCH net-drivers-2.6 0/16] e1000: driver update On Thu, Apr 28, 2005 at 07:38:17PM -0700, Malli Chilakala wrote: > Signed-off-by: Mallikarjuna R Chilakala > Signed-off-by: Ganesh Venkatesan > Signed-off-by: John Ronciak Unless you've changed anything, there's no need to resend these. I've got them all in my inbox. Just plodding very slow ATM as I figure out how to best represent the 40+ branches of netdev-2.6 inside a git repository. :) Jeff From mallikarjuna.chilakala@intel.com Thu Apr 28 20:08:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:08:13 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T38B7J005348 for ; Thu, 28 Apr 2005 20:08:12 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T386ch001822; Fri, 29 Apr 2005 03:08:06 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T37gPK031003; Fri, 29 Apr 2005 03:08:06 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820080519350 ; Thu, 28 Apr 2005 20:08:06 -0700 Date: Thu, 28 Apr 2005 20:08:06 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 0/16] e1000: driver update Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1462 Lines: 23 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak 1 . Added enhanced functionality to the loopback diags to wrap the descriptor rings. 2 . Fix msec-delay definition in e1000_osdep.h to use msleep 3. MSI support for PCI-e adapters 4. Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] 5. Fix kernel panic with 82541 LOM when using a 100M cable 6. Delay clean-up of last Tx packet to fix pre-mature writeback issue of Tx descriptors only when TSO is enabled 7. Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached 8. Fix computation of netdev stats from controller stats counters 9. e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch 10. Implement 82546 errata 10 -- first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. 11. Removed redundant statement in e1000_clean_tx_irq 12. Modified e1000_clean:: exit poll if no Tx and work_done == 0 13. 82573 specific code & packet split code 14. Fix Packet Buffer Allocation logic for 82547_rev_2 controller 15. Adjust flow control watermarks for Jumbo Frames 16. Driver version, white space, comments, device id & other From mallikarjuna.chilakala@intel.com Thu Apr 28 20:09:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:09:37 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T39Z7J005602 for ; Thu, 28 Apr 2005 20:09:35 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T39TmZ026763; Fri, 29 Apr 2005 03:09:29 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T39HPD031895; Fri, 29 Apr 2005 03:09:29 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820092909044 ; Thu, 28 Apr 2005 20:09:29 -0700 Date: Thu, 28 Apr 2005 20:09:29 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 1/16] e1000: made loopback diags robust Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 3995 Lines: 123 Added enhanced functionality to the loopback diags to wrap the descriptor rings. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c 2005-04-12 23:00:55.000000000 -0700 @@ -919,7 +919,8 @@ e1000_setup_desc_rings(struct e1000_adap /* Setup Tx descriptor ring and Tx buffers */ - txdr->count = 80; + if(!txdr->count) + txdr->count = E1000_DEFAULT_TXD; size = txdr->count * sizeof(struct e1000_buffer); if(!(txdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -974,7 +975,8 @@ e1000_setup_desc_rings(struct e1000_adap /* Setup Rx descriptor ring and Rx buffers */ - rxdr->count = 80; + if(!rxdr->count) + rxdr->count = E1000_DEFAULT_RXD; size = rxdr->count * sizeof(struct e1000_buffer); if(!(rxdr->buffer_info = kmalloc(size, GFP_KERNEL))) { @@ -1309,31 +1311,62 @@ e1000_run_loopback_test(struct e1000_ada struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i, ret_val; + int i, j, k, l, lc, good_cnt, ret_val=0; + unsigned long time; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); - for(i = 0; i < 64; i++) { - e1000_create_lbtest_frame(txdr->buffer_info[i].skb, 1024); - pci_dma_sync_single(pdev, txdr->buffer_info[i].dma, - txdr->buffer_info[i].length, - PCI_DMA_TODEVICE); - } - E1000_WRITE_REG(&adapter->hw, TDT, i); - - msec_delay(200); - - i = 0; - do { - pci_dma_sync_single(pdev, rxdr->buffer_info[i].dma, - rxdr->buffer_info[i].length, - PCI_DMA_FROMDEVICE); - - ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, - 1024); - i++; - } while (ret_val != 0 && i < 64); + /* Calculate the loop count based on the largest descriptor ring + * The idea is to wrap the largest ring a number of times using 64 + * send/receive pairs during each loop + */ + + if(rxdr->count <= txdr->count) + lc = ((txdr->count / 64) * 2) + 1; + else + lc = ((rxdr->count / 64) * 2) + 1; + k = l = 0; + for(j = 0; j <= lc; j++) { /* loop count loop */ + for(i = 0; i < 64; i++) { /* send the packets */ + e1000_create_lbtest_frame(txdr->buffer_info[i].skb, + 1024); + pci_dma_sync_single(pdev, + txdr->buffer_info[k].dma, + txdr->buffer_info[k].length, + PCI_DMA_TODEVICE); + if(unlikely(++k == txdr->count)) k = 0; + } + E1000_WRITE_REG(&adapter->hw, TDT, k); + msec_delay(200); + time = jiffies; /* set the start time for the receive */ + good_cnt = 0; + do { /* receive the sent packets */ + pci_dma_sync_single(pdev, + rxdr->buffer_info[l].dma, + rxdr->buffer_info[l].length, + PCI_DMA_FROMDEVICE); + + ret_val = e1000_check_lbtest_frame( + rxdr->buffer_info[l].skb, + 1024); + if(!ret_val) + good_cnt++; + if(unlikely(++l == rxdr->count)) l = 0; + /* time + 20 msecs (200 msecs on 2.4) is more than + * enough time to complete the receives, if it's + * exceeded, break and error off + */ + } while (good_cnt < 64 && jiffies < (time + 20)); + if(good_cnt != 64) { + ret_val = 13; /* ret_val is the same as mis-compare */ + break; + } + if(jiffies >= (time + 2)) { + ret_val = 14; /* error code for time out error */ + break; + } + } /* end loop count loop */ return ret_val; } @@ -1370,6 +1404,8 @@ e1000_link_test(struct e1000_adapter *ad *data = 1; } else { e1000_check_for_link(&adapter->hw); + if(adapter->hw.autoneg) /* if auto_neg is set wait for it */ + msec_delay(4000); if(!(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU)) { *data = 1; From mallikarjuna.chilakala@intel.com Thu Apr 28 20:09:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:09:48 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T39k7J005670 for ; Thu, 28 Apr 2005 20:09:46 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T39edg025055; Fri, 29 Apr 2005 03:09:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T39elH007941; Fri, 29 Apr 2005 03:09:40 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820093917199 ; Thu, 28 Apr 2005 20:09:39 -0700 Date: Thu, 28 Apr 2005 20:09:39 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 2/16] e1000: Fix msec-delay definition to use msleep Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1007 Lines: 22 Fix msec-delay definition in e1000_osdep.h to use msleep Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_osdep.h net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.4/drivers/net/e1000/e1000_osdep.h 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h 2005-04-12 23:00:55.000000000 -0700 @@ -46,9 +46,9 @@ /* Don't mdelay in interrupt context! */ \ BUG(); \ } else { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout((x * HZ)/1000 + 2); \ + msleep(x); \ } } while(0) + /* Some workarounds require millisecond delays and are run during interrupt * context. Most notably, when establishing link, the phy may need tweaking * but cannot process phy register reads/writes faster than millisecond From mallikarjuna.chilakala@intel.com Thu Apr 28 20:11:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:11:06 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3B47J006556 for ; Thu, 28 Apr 2005 20:11:04 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3Aw5P032305; Fri, 29 Apr 2005 03:10:58 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3AwP3000680; Fri, 29 Apr 2005 03:10:58 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820105809165 ; Thu, 28 Apr 2005 20:10:58 -0700 Date: Thu, 28 Apr 2005 20:10:58 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 3/16] e1000:MSI support for PCI-e adapters Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1915 Lines: 51 MSI support for PCI-e adapters Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h 2005-04-12 23:00:55.000000000 -0700 @@ -259,5 +259,8 @@ struct e1000_adapter { uint32_t pci_state[16]; int msg_enable; +#ifdef CONFIG_PCI_MSI + boolean_t have_msi; +#endif }; #endif /* _E1000_H_ */ diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -309,6 +309,16 @@ e1000_up(struct e1000_adapter *adapter) e1000_configure_rx(adapter); e1000_alloc_rx_buffers(adapter); +#ifdef CONFIG_PCI_MSI + if(adapter->hw.mac_type > e1000_82547_rev_2) { + adapter->have_msi = TRUE; + if((err = pci_enable_msi(adapter->pdev))) { + DPRINTK(PROBE, ERR, + "Unable to allocate MSI interrupt Error: %d\n", err); + adapter->have_msi = FALSE; + } + } +#endif if((err = request_irq(adapter->pdev->irq, &e1000_intr, SA_SHIRQ | SA_SAMPLE_RANDOM, netdev->name, netdev))) @@ -330,6 +330,11 @@ e1000_down(struct e1000_adapter *adapter e1000_irq_disable(adapter); free_irq(adapter->pdev->irq, netdev); +#ifdef CONFIG_PCI_MSI + if(adapter->hw.mac_type > e1000_82547_rev_2 && + adapter->have_msi == TRUE) + pci_disable_msi(adapter->pdev); +#endif del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); From mallikarjuna.chilakala@intel.com Thu Apr 28 20:11:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:11:16 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3BE7J006575 for ; Thu, 28 Apr 2005 20:11:14 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3B8mZ027296; Fri, 29 Apr 2005 03:11:08 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3B8P3000796; Fri, 29 Apr 2005 03:11:08 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820110825466 ; Thu, 28 Apr 2005 20:11:08 -0700 Date: Thu, 28 Apr 2005 20:11:08 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 4/16] e1000:Enable polling before enabling interrupts Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 924 Lines: 24 Enable polling before enabling interrupts -- avoids (in NAPI mode) entering the ISR and returning without doing any work because polling is not enabled. [romieu@fr.zoriel.com] Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -325,11 +325,12 @@ e1000_up(struct e1000_adapter *adapter) return err; mod_timer(&adapter->watchdog_timer, jiffies); - e1000_irq_enable(adapter); #ifdef CONFIG_E1000_NAPI netif_poll_enable(netdev); #endif + e1000_irq_enable(adapter); + return 0; } From mallikarjuna.chilakala@intel.com Thu Apr 28 20:11:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:11:26 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3BO7J006670 for ; Thu, 28 Apr 2005 20:11:24 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3BJmZ027354; Fri, 29 Apr 2005 03:11:19 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3BFP5000871; Fri, 29 Apr 2005 03:11:18 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820111809193 ; Thu, 28 Apr 2005 20:11:18 -0700 Date: Thu, 28 Apr 2005 20:11:18 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 5/16] e1000:Fix kernel panic with 82541 LOM Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 766 Lines: 18 Fix kernel panic with 82541 LOM when using a 100M cable Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -369,6 +369,7 @@ e1000_down(struct e1000_adapter *adapter e1000_read_phy_reg(&adapter->hw, PHY_CTRL, &mii_reg); mii_reg |= MII_CR_POWER_DOWN; e1000_write_phy_reg(&adapter->hw, PHY_CTRL, mii_reg); + mdelay(1); } } From mallikarjuna.chilakala@intel.com Thu Apr 28 20:12:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:12:38 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Ca7J007885 for ; Thu, 28 Apr 2005 20:12:36 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3CV5P000482; Fri, 29 Apr 2005 03:12:31 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3CHP9001579; Fri, 29 Apr 2005 03:12:31 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820123025565 ; Thu, 28 Apr 2005 20:12:30 -0700 Date: Thu, 28 Apr 2005 20:12:30 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 6/16] e1000: Delay clean-up of last Tx packet Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2815 Lines: 78 Delay clean-up of last Tx packet to fix pre-mature writeback issue of Tx descriptors only when TSO is enabled Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2341,11 +2341,10 @@ e1000_clean_tx_irq(struct e1000_adapter eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { - /* pre-mature writeback of Tx descriptors */ - /* clear (free buffers and unmap pci_mapping) */ - /* previous_buffer_info */ + /* Premature writeback of Tx descriptors clear (free buffers + * and unmap pci_mapping) previous_buffer_info */ if (likely(adapter->previous_buffer_info.skb != NULL)) { - e1000_unmap_and_free_tx_resource(adapter, + e1000_unmap_and_free_tx_resource(adapter, &adapter->previous_buffer_info); } @@ -2354,20 +2725,25 @@ e1000_clean_tx_irq(struct e1000_adapter buffer_info = &tx_ring->buffer_info[i]; cleaned = (i == eop); - /* pre-mature writeback of Tx descriptors */ - /* save the cleaning of the this for the */ - /* next iteration */ - if (cleaned) { - memcpy(&adapter->previous_buffer_info, - buffer_info, - sizeof(struct e1000_buffer)); - memset(buffer_info, - 0, - sizeof(struct e1000_buffer)); +#ifdef NETIF_F_TSO + if (!(netdev->features & NETIF_F_TSO)) { +#endif + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); +#ifdef NETIF_F_TSO } else { - e1000_unmap_and_free_tx_resource(adapter, - buffer_info); + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource( + adapter, buffer_info); + } } +#endif tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; @@ -2400,7 +2760,14 @@ e1000_clean_tx_irq(struct e1000_adapter !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) netif_stop_queue(netdev); } +#ifdef NETIF_F_TSO + + if( unlikely(!(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) && + time_after(jiffies, adapter->previous_buffer_info.time_stamp + HZ))) + e1000_unmap_and_free_tx_resource( + adapter, &adapter->previous_buffer_info); +#endif return cleaned; } From mallikarjuna.chilakala@intel.com Thu Apr 28 20:12:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:12:51 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Cm7J007925 for ; Thu, 28 Apr 2005 20:12:48 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3Chpr002630; Fri, 29 Apr 2005 03:12:43 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3ChP3001909; Fri, 29 Apr 2005 03:12:43 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820124219670 ; Thu, 28 Apr 2005 20:12:43 -0700 Date: Thu, 28 Apr 2005 20:12:43 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 7/16] e1000: Dump information on Tx ring Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 2046 Lines: 51 Dump information on Tx ring when 'NETDEV: Watchdog' condition is reached Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2399,10 +2399,37 @@ e1000_clean_tx_irq(struct e1000_adapter /* detect a transmit hang in hardware, this serializes the * check with the clearing of time_stamp and movement of i */ adapter->detect_tx_hung = FALSE; - if(tx_ring->buffer_info[i].dma && - time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + if (tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) + && !(E1000_READ_REG(&adapter->hw, STATUS) & + E1000_STATUS_TXOFF)) { + + /* detected Tx unit hang */ + i = tx_ring->next_to_clean; + eop = tx_ring->buffer_info[i].next_to_watch; + eop_desc = E1000_TX_DESC(*tx_ring, eop); + DPRINTK(TX_ERR, ERR, "Detected Tx Unit Hang\n" + " TDH <%x>\n" + " TDT <%x>\n" + " next_to_use <%x>\n" + " next_to_clean <%x>\n" + "buffer_info[next_to_clean]\n" + " dma <%llx>\n" + " time_stamp <%lx>\n" + " next_to_watch <%x>\n" + " jiffies <%lx>\n" + " next_to_watch.status <%x>\n", + E1000_READ_REG(&adapter->hw, TDH), + E1000_READ_REG(&adapter->hw, TDT), + tx_ring->next_to_use, + i, + tx_ring->buffer_info[i].dma, + tx_ring->buffer_info[i].time_stamp, + eop, + jiffies, + eop_desc->upper.fields.status); netif_stop_queue(netdev); + } } #ifdef NETIF_F_TSO From mallikarjuna.chilakala@intel.com Thu Apr 28 20:13:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:13:14 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3DA7J008386 for ; Thu, 28 Apr 2005 20:13:11 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3D55P000742; Fri, 29 Apr 2005 03:13:05 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3D5P3002168; Fri, 29 Apr 2005 03:13:05 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820130514917 ; Thu, 28 Apr 2005 20:13:05 -0700 Date: Thu, 28 Apr 2005 20:13:05 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 8/16] e1000: Fix computation of netdev stats from controller stats counters Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1207 Lines: 24 Fix computation of netdev stats from controller stats counters - from sfeldma@pobox.com Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2187,9 +2187,9 @@ e1000_update_stats(struct e1000_adapter adapter->net_stats.rx_errors = adapter->stats.rxerrc + adapter->stats.crcerrs + adapter->stats.algnerrc + - adapter->stats.rlec + adapter->stats.rnbc + - adapter->stats.mpc + adapter->stats.cexterr; - adapter->net_stats.rx_dropped = adapter->stats.rnbc; + adapter->stats.rlec + adapter->stats.mpc + + adapter->stats.cexterr; + adapter->net_stats.rx_dropped = adapter->stats.mpc; adapter->net_stats.rx_length_errors = adapter->stats.rlec; adapter->net_stats.rx_crc_errors = adapter->stats.crcerrs; adapter->net_stats.rx_frame_errors = adapter->stats.algnerrc; From mallikarjuna.chilakala@intel.com Thu Apr 28 20:14:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:14:53 -0700 (PDT) Received: from fmsfmr002.fm.intel.com (fmr14.intel.com [192.55.52.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Ep7J009815 for ; Thu, 28 Apr 2005 20:14:51 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3Ek5P001453; Fri, 29 Apr 2005 03:14:46 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3EVPD003140; Fri, 29 Apr 2005 03:14:46 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820144615061 ; Thu, 28 Apr 2005 20:14:46 -0700 Date: Thu, 28 Apr 2005 20:14:46 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 10/16] e1000:Implement a workaround for 82546 errata 10 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1825 Lines: 40 Implement a workaround for 82546 errata 10 -- first Tx descriptor cannot have more than 2015 byte of data in it or it could hang the transmitter. Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -1750,6 +1750,15 @@ e1000_tx_map(struct e1000_adapter *adapt if(unlikely(mss && !nr_frags && size == len && size > 8)) size -= 4; #endif + /* work-around for errata 10 and it applies + * to all controllers in PCI-X mode + * The fix is to make sure that the first descriptor of a + * packet is smaller than 2048 - 16 - 16 (or 2016) bytes + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (size > 2015) && count == 0)) + size = 2015; + /* Workaround for potential 82544 hang in PCI-X. Avoid * terminating buffers within evenly-aligned dwords. */ if(unlikely(adapter->pcix_82544 && @@ -1951,6 +1960,13 @@ e1000_xmit_frame(struct sk_buff *skb, st if(adapter->pcix_82544) count++; + /* work-around for errata 10 and it applies to all controllers + * in PCI-X mode, so add one more descriptor to the count + */ + if(unlikely((adapter->hw.bus_type == e1000_bus_type_pcix) && + (len > 2015))) + count++; + nr_frags = skb_shinfo(skb)->nr_frags; for(f = 0; f < nr_frags; f++) count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size, From mallikarjuna.chilakala@intel.com Thu Apr 28 20:14:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:14:45 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Eh7J009757 for ; Thu, 28 Apr 2005 20:14:43 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3EYwf000819; Fri, 29 Apr 2005 03:14:34 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3EDld010526; Fri, 29 Apr 2005 03:14:34 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820143317846 ; Thu, 28 Apr 2005 20:14:33 -0700 Date: Thu, 28 Apr 2005 20:14:34 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 9/16] e1000: stops working after resume Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 975 Lines: 22 e1000 stops working after resume, call pci_enable_device after pci_restore_state - Modified Andrew Morton's patch Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -3128,9 +3128,10 @@ e1000_resume(struct pci_dev *pdev) struct e1000_adapter *adapter = netdev->priv; uint32_t manc, ret; - ret = pci_enable_device(pdev); pci_set_power_state(pdev, 0); pci_restore_state(pdev, adapter->pci_state); + ret = pci_enable_device(pdev); + pci_set_master(pdev); pci_enable_wake(pdev, 3, 0); pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */ From mallikarjuna.chilakala@intel.com Thu Apr 28 20:15:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:15:29 -0700 (PDT) Received: from fmsfmr006.fm.intel.com (fmr16.intel.com [192.55.52.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3FR7J010282 for ; Thu, 28 Apr 2005 20:15:27 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3FLpr003085; Fri, 29 Apr 2005 03:15:21 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3FLP3003760; Fri, 29 Apr 2005 03:15:21 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820152015109 ; Thu, 28 Apr 2005 20:15:20 -0700 Date: Thu, 28 Apr 2005 20:15:20 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 11/16] e1000:Removed redundant statement in e1000_clean_tx_irq Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 734 Lines: 18 Removed redundant statement in e1000_clean_tx_irq Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2393,7 +2393,6 @@ e1000_clean_tx_irq(struct e1000_adapter tx_desc->lower.data = 0; tx_desc->upper.data = 0; - cleaned = (i == eop); if(unlikely(++i == tx_ring->count)) i = 0; } From mallikarjuna.chilakala@intel.com Thu Apr 28 20:15:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:15:41 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Fd7J010367 for ; Thu, 28 Apr 2005 20:15:39 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3FWTs004836; Fri, 29 Apr 2005 03:15:32 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3FWP5003941; Fri, 29 Apr 2005 03:15:32 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820153219886 ; Thu, 28 Apr 2005 20:15:32 -0700 Date: Thu, 28 Apr 2005 20:15:32 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 12/16] e1000: Modified e1000_clean:: exit poll Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 22 Modified e1000_clean:: exit poll if no Tx and work_done == 0 Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -2325,9 +2325,8 @@ e1000_clean(struct net_device *netdev, i *budget -= work_done; netdev->quota -= work_done; - /* if no Tx and not enough Rx work done, exit the polling mode */ - if((!tx_cleaned && (work_done < work_to_do)) || - !netif_running(netdev)) { + /* If no Tx and no Rx work done, exit the polling mode */ + if ((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; From mallikarjuna.chilakala@intel.com Thu Apr 28 20:17:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:17:43 -0700 (PDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Hf7J012074 for ; Thu, 28 Apr 2005 20:17:42 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3HVdg027864; Fri, 29 Apr 2005 03:17:31 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3HUlJ012346; Fri, 29 Apr 2005 03:17:31 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820173018259 ; Thu, 28 Apr 2005 20:17:30 -0700 Date: Thu, 28 Apr 2005 20:17:31 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 14/16] e1000: Fix Packet Buffer logic for 82547_rev_2 Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 738 Lines: 18 Fix Packet Buffer Allocation logic for 82547_rev_2 controller Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -414,6 +414,7 @@ e1000_down(struct e1000_adapter *adapter switch (adapter->hw.mac_type) { case e1000_82547: + case e1000_82547_rev_2: pba = E1000_PBA_30K; break; case e1000_82573: From mallikarjuna.chilakala@intel.com Thu Apr 28 20:17:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:17:49 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3Hl7J012092 for ; Thu, 28 Apr 2005 20:17:47 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3HgmZ029650; Fri, 29 Apr 2005 03:17:42 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3HbP7005337; Fri, 29 Apr 2005 03:17:41 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820174109726 ; Thu, 28 Apr 2005 20:17:41 -0700 Date: Thu, 28 Apr 2005 20:17:41 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 15/16] e1000: Adjust flow control watermarks for JumboFrames Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1800 Lines: 50 Adjust flow control watermarks for Jumbo Frames Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -406,7 +406,10 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { + struct net_device *netdev = adapter->netdev; uint32_t pba, manc; + uint16_t fc_high_water_mark = E1000_FC_HIGH_DIFF; + uint16_t fc_low_water_mark = E1000_FC_LOW_DIFF; /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. @@ -425,6 +425,16 @@ break; } + if((adapter->hw.mac_type != e1000_82573) && + (adapter->rx_buffer_len > E1000_RXBUFFER_8192)) { + pba -= 8; /* allocate more FIFO for Tx */ + /* send an XOFF when there is enough space in the + * Rx FIFO to hold one extra full size Rx packet + */ + fc_high_water_mark = netdev->mtu + ENET_HEADER_SIZE + + ETHERNET_FCS_SIZE + 1; + fc_low_water_mark = fc_high_water_mark + 8; + } if(adapter->hw.mac_type == e1000_82547) { @@ -439,9 +439,9 @@ /* flow control settings */ adapter->hw.fc_high_water = (pba << E1000_PBA_BYTES_SHIFT) - - E1000_FC_HIGH_DIFF; + fc_high_water_mark; adapter->hw.fc_low_water = (pba << E1000_PBA_BYTES_SHIFT) - - E1000_FC_LOW_DIFF; + fc_low_water_mark; adapter->hw.fc_pause_time = E1000_FC_PAUSE_TIME; adapter->hw.fc_send_xon = 1; adapter->hw.fc = adapter->hw.original_fc; From mallikarjuna.chilakala@intel.com Thu Apr 28 20:18:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Apr 2005 20:18:24 -0700 (PDT) Received: from fmsfmr001.fm.intel.com (fmr13.intel.com [192.55.52.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T3IJ7J012323 for ; Thu, 28 Apr 2005 20:18:19 -0700 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T3IDTs006271; Fri, 29 Apr 2005 03:18:13 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T3IAP5005721; Fri, 29 Apr 2005 03:18:13 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042820181320122 ; Thu, 28 Apr 2005 20:18:13 -0700 Date: Thu, 28 Apr 2005 20:18:13 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.4 16/16] e1000: Driver version, white space, comments, deviceid Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 24616 Lines: 664 Driver version, white space, comments, device id & other Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c --- net-drivers-2.4/drivers/net/e1000/e1000_ethtool.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_ethtool.c 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -69,6 +69,7 @@ static const struct e1000_stats e1000_gs { "rx_crc_errors", E1000_STAT(net_stats.rx_crc_errors) }, { "rx_frame_errors", E1000_STAT(net_stats.rx_frame_errors) }, { "rx_fifo_errors", E1000_STAT(net_stats.rx_fifo_errors) }, + { "rx_no_buffer_count", E1000_STAT(stats.rnbc) }, { "rx_missed_errors", E1000_STAT(net_stats.rx_missed_errors) }, { "tx_aborted_errors", E1000_STAT(net_stats.tx_aborted_errors) }, { "tx_carrier_errors", E1000_STAT(net_stats.tx_carrier_errors) }, @@ -593,7 +594,7 @@ e1000_set_ringparam(struct net_device *n tx_old = adapter->tx_ring; rx_old = adapter->rx_ring; - if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) + if((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) return -EINVAL; if(netif_running(adapter->netdev)) @@ -784,8 +785,8 @@ e1000_intr_test(struct e1000_adapter *ad /* Hook up test interrupt handler just for this test */ if(!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) { shared_int = FALSE; - } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, - netdev->name, netdev)){ + } else if(request_irq(irq, &e1000_test_intr, SA_SHIRQ, + netdev->name, netdev)){ *data = 1; return -1; } @@ -842,10 +843,8 @@ e1000_intr_test(struct e1000_adapter *ad * test failed. */ adapter->test_icr = 0; - E1000_WRITE_REG(&adapter->hw, IMC, - (~mask & 0x00007FFF)); - E1000_WRITE_REG(&adapter->hw, ICS, - (~mask & 0x00007FFF)); + E1000_WRITE_REG(&adapter->hw, IMC, ~mask & 0x00007FFF); + E1000_WRITE_REG(&adapter->hw, ICS, ~mask & 0x00007FFF); msec_delay(10); if(adapter->test_icr) { @@ -1386,13 +1385,12 @@ static int e1000_link_test(struct e1000_adapter *adapter, uint64_t *data) { *data = 0; - if (adapter->hw.media_type == e1000_media_type_internal_serdes) { int i = 0; adapter->hw.serdes_link_down = TRUE; - /* on some blade server designs link establishment */ - /* could take as long as 2-3 minutes. */ + /* On some blade server designs, link establishment + * could take as long as 2-3 minutes */ do { e1000_check_for_link(&adapter->hw); if (adapter->hw.serdes_link_down == FALSE) @@ -1400,7 +1373,7 @@ e1000_link_test(struct e1000_adapter *ad msec_delay(20); } while (i++ < 3750); - *data = 1; + *data = 1; } else { e1000_check_for_link(&adapter->hw); if(adapter->hw.autoneg) /* if auto_neg is set wait for it */ diff -up net-drivers-2.4/drivers/net/e1000/e1000.h net-drivers-2.4/drivers/net/e1000.new/e1000.h --- net-drivers-2.4/drivers/net/e1000/e1000.h 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000.h 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -141,9 +138,9 @@ struct e1000_adapter; /* How many Rx Buffers do we bundle into one write to the hardware ? */ #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ -#define AUTO_ALL_MODES 0 -#define E1000_EEPROM_82544_APM 0x0004 -#define E1000_EEPROM_APME 0x0400 +#define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0400 +#define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE /* Switch to override PHY master/slave setting */ diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.c net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c --- net-drivers-2.4/drivers/net/e1000/e1000_hw.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.c 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -144,7 +144,6 @@ e1000_phy_init_script(struct e1000_hw *h DEBUGFUNC("e1000_phy_init_script"); - if(hw->phy_init_script) { msec_delay(20); diff -up net-drivers-2.4/drivers/net/e1000/e1000_hw.h net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h --- net-drivers-2.4/drivers/net/e1000/e1000_hw.h 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_hw.h 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.4/drivers/net/e1000/e1000_main.c net-drivers-2.4/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.4/drivers/net/e1000/e1000_main.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_main.c 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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,33 +29,9 @@ #include "e1000.h" /* Change Log - * 5.3.12 6/7/04 - * - kcompat NETIF_MSG for older kernels (2.4.9) - * - if_mii support and associated kcompat for older kernels - * - More errlogging support from Jon Mason - * - Fix TSO issues on PPC64 machines -- Jon Mason - * 5.7.1 12/16/04 - * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This - * fix was removed as it caused system instability. The suspected cause of - * this is the called to e1000_irq_disable in e1000_intr. Inlined the - * required piece of e1000_irq_disable into e1000_intr. - * 5.7.0 12/10/04 - * - include fix to the condition that determines when to quit NAPI - Robert Olsson - * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down - * 5.6.5 11/01/04 - * - Enabling NETIF_F_SG without checksum offload is illegal - - John Mason - * 5.6.3 10/26/04 - * - Remove redundant initialization - Jamal Hadi - * - Reset buffer_info->dma in tx resource cleanup logic - * 5.6.2 10/12/04 - * - Avoid filling tx_ring completely - shemminger@osdl.org - * - Replace schedule_timeout() with msleep()/msleep_interruptible() - - * nacc@us.ibm.com - * - Sparse cleanup - shemminger@osdl.org - * - Fix tx resource cleanup logic - * - LLTX support - ak@suse.de and hadi@cyberus.ca - * - {set, get}_wol is now symmetric for 82545EM adapters + * 6.0.44+ 2/15/05 + * o applied Anton's patch to resolve tx hang in hardware + * o Applied Andrew Mortons patch - e1000 stops working after resume */ char e1000_driver_name[] = "e1000"; @@ -65,8 +110,8 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.7.6-k1"DRIVERNAPI; -char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +char e1000_driver_version[] = "6.0.54-k1"DRIVERNAPI; +char e1000_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table * @@ -95,6 +71,7 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x1017), INTEL_E1000_ETHERNET_DEVICE(0x1018), INTEL_E1000_ETHERNET_DEVICE(0x1019), + INTEL_E1000_ETHERNET_DEVICE(0x101A), INTEL_E1000_ETHERNET_DEVICE(0x101D), INTEL_E1000_ETHERNET_DEVICE(0x101E), INTEL_E1000_ETHERNET_DEVICE(0x1026), @@ -109,6 +86,9 @@ static struct pci_device_id e1000_pci_tb INTEL_E1000_ETHERNET_DEVICE(0x107B), INTEL_E1000_ETHERNET_DEVICE(0x107C), INTEL_E1000_ETHERNET_DEVICE(0x108A), + INTEL_E1000_ETHERNET_DEVICE(0x108B), + INTEL_E1000_ETHERNET_DEVICE(0x108C), + INTEL_E1000_ETHERNET_DEVICE(0x1099), /* required last entry */ {0,} }; @@ -347,8 +351,11 @@ e1000_up(struct e1000_adapter *adapter) #endif if((err = request_irq(adapter->pdev->irq, &e1000_intr, SA_SHIRQ | SA_SAMPLE_RANDOM, - netdev->name, netdev))) + netdev->name, netdev))) { + DPRINTK(PROBE, ERR, + "Unable to allocate interrupt Error: %d\n", err); return err; + } mod_timer(&adapter->watchdog_timer, jiffies); @@ -630,7 +613,7 @@ e1000_probe(struct pci_dev *pdev, /* copy the MAC address out of the EEPROM */ - if (e1000_read_mac_addr(&adapter->hw)) + if(e1000_read_mac_addr(&adapter->hw)) DPRINTK(PROBE, ERR, "EEPROM Read Error\n"); memcpy(netdev->dev_addr, adapter->hw.mac_addr, netdev->addr_len); @@ -950,12 +933,10 @@ e1000_check_64k_bound(struct e1000_adapt unsigned long begin = (unsigned long) start; unsigned long end = begin + len; - /* first rev 82545 and 82546 need to not allow any memory - * write location to cross a 64k boundary due to errata 23 */ + /* First rev 82545 and 82546 need to not allow any memory + * write location to cross 64k boundary due to errata 23 */ if (adapter->hw.mac_type == e1000_82545 || - adapter->hw.mac_type == e1000_82546 ) { - - /* check buffer doesn't cross 64kB */ + adapter->hw.mac_type == e1000_82546) { return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; } @@ -979,8 +960,8 @@ e1000_setup_tx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * txdr->count; txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Transmit descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -993,22 +925,22 @@ e1000_setup_tx_resources(struct e1000_ad txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { setup_tx_desc_die: - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the transmit descriptor ring\n"); return -ENOMEM; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { void *olddesc = txdr->desc; dma_addr_t olddma = txdr->dma; - DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", - txdr->size, txdr->desc); - /* try again, without freeing the previous */ + DPRINTK(TX_ERR, ERR, "txdr align check failed: %u bytes " + "at %p\n", txdr->size, txdr->desc); + /* Try again, without freeing the previous */ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); - /* failed allocation, critial failure */ if(!txdr->desc) { + /* Failed allocation, critical failure */ pci_free_consistent(pdev, txdr->size, olddesc, olddma); goto setup_tx_desc_die; } @@ -1015,16 +925,16 @@ if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { /* give up */ - pci_free_consistent(pdev, txdr->size, - txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, txdr->desc, + txdr->dma); pci_free_consistent(pdev, txdr->size, olddesc, olddma); DPRINTK(PROBE, ERR, - "Unable to Allocate aligned Memory for the Transmit" - " descriptor ring\n"); + "Unable to allocate aligned memory " + "for the transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } else { - /* free old, move on with the new one since its okay */ + /* Free old allocation, new allocation was successful */ pci_free_consistent(pdev, txdr->size, olddesc, olddma); } } @@ -1131,8 +1058,8 @@ e1000_setup_rx_resources(struct e1000_ad size = sizeof(struct e1000_buffer) * rxdr->count; rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { - DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Recieve descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the receive descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -1172,25 +1058,24 @@ if(!rxdr->desc) { setup_rx_desc_die: - DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); + DPRINTK(PROBE, ERR, + "Unable to allocate memory for the receive descriptor ring\n"); return -ENOMEM; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { void *olddesc = rxdr->desc; dma_addr_t olddma = rxdr->dma; - DPRINTK(RX_ERR,ERR, - "rxdr align check failed: %u bytes at %p\n", - rxdr->size, rxdr->desc); - /* try again, without freeing the previous */ + DPRINTK(RX_ERR, ERR, "rxdr align check failed: %u bytes " + "at %p\n", rxdr->size, rxdr->desc); + /* Try again, without freeing the previous */ rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); - /* failed allocation, critial failure */ if(!rxdr->desc) { + /* Failed allocation, critical failure */ pci_free_consistent(pdev, rxdr->size, olddesc, olddma); goto setup_rx_desc_die; } @@ -1197,18 +1058,18 @@ if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { /* give up */ - pci_free_consistent(pdev, rxdr->size, - rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, rxdr->desc, + rxdr->dma); pci_free_consistent(pdev, rxdr->size, olddesc, olddma); - DPRINTK(PROBE, ERR, - "Unable to Allocate aligned Memory for the" - " Receive descriptor ring\n"); + DPRINTK(PROBE, ERR, + "Unable to allocate aligned memory " + "for the receive descriptor ring\n"); vfree(rxdr->buffer_info); kfree(rxdr->ps_page); kfree(rxdr->ps_page_dma); return -ENOMEM; } else { - /* free old, move on with the new one since its okay */ + /* Free old allocation, new allocation was successful */ pci_free_consistent(pdev, rxdr->size, olddesc, olddma); } } @@ -1221,7 +1123,7 @@ setup_rx_desc_die: } /** - * e1000_setup_rctl - configure the receive control register + * e1000_setup_rctl - configure the receive control registers * @adapter: Board private structure **/ @@ -1413,13 +1393,11 @@ static inline void e1000_unmap_and_free_tx_resource(struct e1000_adapter *adapter, struct e1000_buffer *buffer_info) { - struct pci_dev *pdev = adapter->pdev; - if(buffer_info->dma) { - pci_unmap_page(pdev, - buffer_info->dma, - buffer_info->length, - PCI_DMA_TODEVICE); + pci_unmap_page(adapter->pdev, + buffer_info->dma, + buffer_info->length, + PCI_DMA_TODEVICE); buffer_info->dma = 0; } if(buffer_info->skb) { @@ -1444,7 +1422,7 @@ e1000_clean_tx_ring(struct e1000_adapter /* Free all the Tx ring sk_buffs */ if (likely(adapter->previous_buffer_info.skb != NULL)) { - e1000_unmap_and_free_tx_resource(adapter, + e1000_unmap_and_free_tx_resource(adapter, &adapter->previous_buffer_info); } @@ -1646,15 +1624,15 @@ e1000_set_multi(struct net_device *netde struct e1000_adapter *adapter = netdev->priv; struct e1000_hw *hw = &adapter->hw; struct dev_mc_list *mc_ptr; + unsigned long flags; uint32_t rctl; uint32_t hash_value; int i; - unsigned long flags; - - /* Check for Promiscuous and All Multicast modes */ spin_lock_irqsave(&adapter->tx_lock, flags); + /* Check for Promiscuous and All Multicast modes */ + rctl = E1000_READ_REG(hw, RCTL); if(netdev->flags & IFF_PROMISC) { @@ -1854,7 +1832,7 @@ e1000_watchdog(unsigned long data) /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Force detection of hung controller every watchdog period*/ + /* Force detection of hung controller every watchdog period */ adapter->detect_tx_hung = TRUE; /* Reset the timer */ @@ -2240,7 +2218,7 @@ e1000_xmit_frame(struct sk_buff *skb, st if((mss) || (skb->ip_summed == CHECKSUM_HW)) count++; - count++; /* for sentinel desc */ + count++; #else if(skb->ip_summed == CHECKSUM_HW) count++; @@ -2615,7 +2315,7 @@ e1000_intr(int irq, void *data, struct p */ if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ atomic_inc(&adapter->irq_sem); - E1000_WRITE_REG(&adapter->hw, IMC, ~0); + E1000_WRITE_REG(hw, IMC, ~0); } for(i = 0; i < E1000_MAX_INTR; i++) @@ -2643,7 +2355,7 @@ e1000_clean(struct net_device *netdev, i int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; - + tx_cleaned = e1000_clean_tx_irq(adapter); adapter->clean_rx(adapter, &work_done, work_to_do); @@ -2733,9 +2443,9 @@ e1000_clean_tx_irq(struct e1000_adapter netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); - if(adapter->detect_tx_hung) { - /* detect a transmit hang in hardware, this serializes the + + /* Detect a transmit hang in hardware, this serializes the * check with the clearing of time_stamp and movement of i */ adapter->detect_tx_hung = FALSE; if (tx_ring->buffer_info[i].dma && @@ -2880,7 +2858,7 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) { /* All receives must fit into a single buffer */ E1000_DBG("%s: Receive packet consumed multiple" - " buffers\n", netdev->name); + " buffers\n", netdev->name); dev_kfree_skb_irq(skb); goto next_desc; } @@ -3088,32 +2619,33 @@ e1000_alloc_rx_buffers(struct e1000_adap struct e1000_buffer *buffer_info; struct sk_buff *skb; int reserve_len = 2; - unsigned int i, bufsz; + unsigned int i; + unsigned int bufsz = adapter->rx_buffer_len + 2; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - bufsz = adapter->rx_buffer_len + reserve_len; - skb = dev_alloc_skb(bufsz); + if(unlikely(!skb)) { /* Better luck next round */ break; } - /* fix for errata 23, cant cross 64kB boundary */ + /* Fix for errata 23, can't cross 64kB boundary */ if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { struct sk_buff *oldskb = skb; - DPRINTK(RX_ERR,ERR, - "skb align check failed: %u bytes at %p\n", - bufsz, skb->data); - /* try again, without freeing the previous */ + DPRINTK(RX_ERR, ERR, "skb align check failed: %u bytes " + "at %p\n", bufsz, skb->data); + /* Try again, without freeing the previous */ skb = dev_alloc_skb(bufsz); + /* Failed allocation, critical failure */ if (!skb) { dev_kfree_skb(oldskb); break; } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { /* give up */ dev_kfree_skb(skb); @@ -3120,11 +2619,10 @@ dev_kfree_skb(oldskb); break; /* while !buffer_info->skb */ } else { - /* move on with the new one */ + /* Use new allocation */ dev_kfree_skb(oldskb); } } - /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -3140,25 +3118,23 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); - /* fix for errata 23, cant cross 64kB boundary */ - if(!e1000_check_64k_bound(adapter, - (void *)(unsigned long)buffer_info->dma, - adapter->rx_buffer_len)) { - DPRINTK(RX_ERR,ERR, - "dma align check failed: %u bytes at %ld\n", - adapter->rx_buffer_len, (unsigned long)buffer_info->dma); - + /* Fix for errata 23, can't cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR, ERR, + "dma align check failed: %u bytes at %p\n", + adapter->rx_buffer_len, + (void *)(unsigned long)buffer_info->dma); dev_kfree_skb(skb); buffer_info->skb = NULL; - pci_unmap_single(pdev, - buffer_info->dma, + pci_unmap_single(pdev, buffer_info->dma, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); break; /* while !buffer_info->skb */ } - rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); @@ -3168,7 +3144,6 @@ e1000_alloc_rx_buffers(struct e1000_adap * applicable for weak-ordered memory model archs, * such as IA-64). */ wmb(); - E1000_WRITE_REG(&adapter->hw, RDT, i); } @@ -3441,9 +3416,10 @@ void e1000_pci_set_mwi(struct e1000_hw *hw) { struct e1000_adapter *adapter = hw->back; + int ret_val = pci_set_mwi(adapter->pdev); - int ret; - ret = pci_set_mwi(adapter->pdev); + if(ret_val) + DPRINTK(PROBE, ERR, "Error in setting MWI\n"); } void @@ -3601,8 +3577,7 @@ e1000_set_spd_dplx(struct e1000_adapter break; case SPEED_1000 + DUPLEX_HALF: /* not supported */ default: - DPRINTK(PROBE, ERR, - "Unsupported Speed/Duplexity configuration\n"); + DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n"); return -EINVAL; } return 0; @@ -3768,7 +3743,7 @@ e1000_resume(struct pci_dev *pdev) * the interrupt routine is executing. */ static void -e1000_netpoll (struct net_device *netdev) +e1000_netpoll(struct net_device *netdev) { struct e1000_adapter *adapter = netdev->priv; disable_irq(adapter->pdev->irq); diff -up net-drivers-2.4/drivers/net/e1000/e1000_osdep.h net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h --- net-drivers-2.4/drivers/net/e1000/e1000_osdep.h 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_osdep.h 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 diff -up net-drivers-2.4/drivers/net/e1000/e1000_param.c net-drivers-2.4/drivers/net/e1000.new/e1000_param.c --- net-drivers-2.4/drivers/net/e1000/e1000_param.c 2005-04-12 23:00:53.000000000 -0700 +++ net-drivers-2.4/drivers/net/e1000.new/e1000_param.c 2005-04-12 23:00:55.000000000 -0700 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 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 @@ -455,7 +532,6 @@ e1000_check_options(struct e1000_adapter DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); break; - case -1: default: e1000_validate_option(&adapter->itr, &opt, adapter); From herbert@gondor.apana.org.au Fri Apr 29 00:05:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 00:06:02 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T75o7J025535 for ; Fri, 29 Apr 2005 00:05:54 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DRPYf-00075o-00; Fri, 29 Apr 2005 17:05:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DRPYd-0005RO-00; Fri, 29 Apr 2005 17:05:03 +1000 From: Herbert Xu To: pbadari@us.ibm.com (Badari Pulavarty) Subject: Re: Panic in sk_stream_wait_memory() while doing iSCSI testing Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <1114726972.26913.711.camel@dyn318077bld.beaverton.ibm.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 29 Apr 2005 17:05:03 +1000 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 939 Lines: 24 Badari Pulavarty wrote: > > I ran into panic in sk_stream_wait_memory() while doing iSCSI > testing on 2.6.12-rc2. The problem seems to be while doing > > set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); > > sk->sk_socket seems to be NULL. Can this happen ? Do we need If sk->sk_socket is NULL, then either the socket hasn't been initialised yet or it has already been freed. Either way you've got socket life-cycle management issues in your code. Basically, while you're in sk_stream_wait_memory, you must arrange it so that the socket does not go away under you. Normally this is done by holding a reference on the socket, either directly or indirectly through a file descriptor. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jbenc@suse.cz Fri Apr 29 02:40:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 02:40:41 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T9ec7J004029 for ; Fri, 29 Apr 2005 02:40:39 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with SMTP id 191256282E3 for ; Fri, 29 Apr 2005 11:40:33 +0200 (CEST) Date: Fri, 29 Apr 2005 11:42:08 +0200 From: Jiri Benc To: netdev@oss.sgi.com Subject: [RFC/PATCH] Fixes for ULi5261 (tulip driver) Message-Id: <20050429114208.39b53ccf@griffin.suse.cz> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; x86_64-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 3280 Lines: 82 (Sent to lkml few days ago - sorry for not CCing netdev list.) With integrated ALi/ULi M5261 ethernet controller using tulip driver, autonegotation doesn't work and card is forced to 10 Mbps half-duplex mode. I found two problems with tulip driver regarding ULi5261. 1. In tulip_up() media selection does not work properly. No media from EEPROM media list is set as default in ULi's EEPROM. In such case tulip driver searches for first non-fullduplex media. I have no idea why the search is not performed for MII capable media first. Maybe because of problems with some other cards? EEPROM media list is reported to be as follows: tulip0: EEPROM default media type Autosense. tulip0: MII interface PHY 1, setup/reset sequences 0/2 long, capabilities 00 01. tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. tulip0: Index #1 - Media 10baseT (#0) described by a (128) block. tulip0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. tulip0: Index #3 - Media 10base2 (#1) described by a 21140 non-MII (0) block. tulip0: Index #4 - Media 10baseT-FDX (#4) described by a 21140 non-MII (0) block. tulip0: Index #5 - Media 100baseTx-FDX (#5) described by a 21140 non-MII (0) block. I added code that performs search for MII capable media in case of ULi5261 card. Shouldn't it be performed generally? 2. PHY chip DM9161E used on my M5261 seems to claim (in BMCR register) that autonegotiation is enabled after initialization, but it needs to set BMCR_ANRESTART for autonegotiation to work. Without forcing of restart of autonegotiation, MII_LPA returns always 0. Is there any way to detect that DM9161E is used? It may be used with another ethernet cards (and there may be another PHY used in M5261 as well), so restarting autonegotiation in case of ULi5261 doesn't seem to be a solution. The only way I see is to always restart autonegotiation in tulip_find_mii(). It probably has the side-effect that other cards with autonegotiation enabled by default will perform autonegotiation twice. Thanks for your suggestions. --- linux-2.6.12-rc3/drivers/net/tulip/media.c +++ linux-2.6.12-rc3-patched/drivers/net/tulip/media.c @@ -517,10 +517,11 @@ void __devinit tulip_find_mii (struct ne /* Enable autonegotiation: some boards default to off. */ if (tp->default_port == 0) { new_bmcr = mii_reg0 | BMCR_ANENABLE; - if (new_bmcr != mii_reg0) { - new_bmcr |= BMCR_ANRESTART; - ane_switch = 1; - } + /* DM9161E PHY seems to need to restart + * autonegotiation even if it defaults to enabled. + */ + new_bmcr |= BMCR_ANRESTART; + ane_switch = 1; } /* ...or disable nway, if forcing media */ else { --- linux-2.6.12-rc3/drivers/net/tulip/tulip_core.c +++ linux-2.6.12-rc3-patched/drivers/net/tulip/tulip_core.c @@ -383,6 +383,11 @@ static void tulip_up(struct net_device * goto media_picked; } } + if (tp->chip_id == ULI526X) { + for (i = tp->mtable->leafcount - 1; i >= 0; i--) + if (tulip_media_cap[tp->mtable->mleaf[i].media] & MediaIsMII) + goto media_picked; + } /* Start sensing first non-full-duplex media. */ for (i = tp->mtable->leafcount - 1; (tulip_media_cap[tp->mtable->mleaf[i].media] & MediaAlwaysFD) && i > 0; i--) -- Jiri Benc SUSE Labs From tommy.christensen@tpack.net Fri Apr 29 02:51:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 02:51:58 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3T9ps7J004778 for ; Fri, 29 Apr 2005 02:51:55 -0700 Received: (qmail 31178 invoked from network); 29 Apr 2005 09:51:48 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 29 Apr 2005 09:51:48 -0000 Subject: Re: [PATCH] net: Disable queueing when carrier is lost From: Tommy Christensen To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <20050427234359.GB22238@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> <20050427234359.GB22238@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-EIU1GPvPvAE3JEFONXJG" Message-Id: <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 29 Apr 2005 11:51:48 +0200 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 2989 Lines: 83 --=-EIU1GPvPvAE3JEFONXJG Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-04-28 at 01:43, Herbert Xu wrote: > On Thu, Apr 28, 2005 at 01:27:57AM +0200, Tommy Christensen wrote: > > This is indeed possible, but hopefully you can agree that this would be > > a driver bug. As stated above, I'm not trying to solve everything. We > > have to assume some level of sanity of the drivers. E.g. for a NIC that > > stalls the TX engine on carrier off, the driver would have to flush the > > TX ring and either call netif_stop_queue or discard packets in their > > hard_start_xmit function. At present, even such well-behaving drivers > > would hit the problem, because packets were piling up in the qdisc. > > I am not saying that there is nothing to fix. I'm simply stating > that doing it in the watchdog is not ideal for two reasons: > > 1) The watchdog is not always there. > 2) The delay introduced by the watchdog is driver-dependent and > varies wildly. For the purpose of shutting down the qdisc after > a carrier off we want everything to use the same delay (if we're > going to delay at all). > > So instead of doing it in the watchdog, just do both actions in > the link_watch worker. Originally, I was afraid it could get too trigger happy, so I left this idea. Perhaps that's not such a big deal afterall. How does this look? Signed-off-by: Tommy S. Christensen --=-EIU1GPvPvAE3JEFONXJG Content-Description: Content-Disposition: inline; filename=carrier-2.patch Content-Type: text/x-patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-04-29 11:22:05.330262591 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + if (dev->qdisc_sleeping != &noop_qdisc) + dev_activate(dev); + } else if (netif_queue_stopped(dev)) + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-04-29 11:22:05.420250195 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev) && netif_queue_stopped(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --=-EIU1GPvPvAE3JEFONXJG-- From mallikarjuna.chilakala@intel.com Fri Apr 29 03:17:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 03:18:03 -0700 (PDT) Received: from fmsfmr005.fm.intel.com (fmr15.intel.com [192.55.52.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TAHn7J006314 for ; Fri, 29 Apr 2005 03:17:50 -0700 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3T2fBmZ017440; Fri, 29 Apr 2005 02:41:11 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3T2fBoS003838; Fri, 29 Apr 2005 02:41:11 GMT Received: from isotope.jf.intel.com ([10.23.35.8]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042819411007314 ; Thu, 28 Apr 2005 19:41:10 -0700 Date: Thu, 28 Apr 2005 19:41:11 -0700 (PDT) From: Malli Chilakala To: netdev cc: "jgarzik@pobox.com" Subject: [resend][PATCH net-drivers-2.6 8/16] e1000:Fix computation of netdev stats from controller stats counters Message-ID: ReplyTo: "Malli Chilakala" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mallikarjuna.chilakala@intel.com Precedence: bulk X-list: netdev Content-Length: 1207 Lines: 24 Fix computation of netdev stats from controller stats counters - from sfeldma@pobox.com Signed-off-by: Mallikarjuna R Chilakala Signed-off-by: Ganesh Venkatesan Signed-off-by: John Ronciak diff -up net-drivers-2.6/drivers/net/e1000/e1000_main.c net-drivers-2.6/drivers/net/e1000.new/e1000_main.c --- net-drivers-2.6/drivers/net/e1000/e1000_main.c 2005-04-11 02:22:27.000000000 -0700 +++ net-drivers-2.6/drivers/net/e1000.new/e1000_main.c 2005-04-11 02:22:29.000000000 -0700 @@ -2230,9 +2230,9 @@ e1000_update_stats(struct e1000_adapter adapter->net_stats.rx_errors = adapter->stats.rxerrc + adapter->stats.crcerrs + adapter->stats.algnerrc + - adapter->stats.rlec + adapter->stats.rnbc + - adapter->stats.mpc + adapter->stats.cexterr; - adapter->net_stats.rx_dropped = adapter->stats.rnbc; + adapter->stats.rlec + adapter->stats.mpc + + adapter->stats.cexterr; + adapter->net_stats.rx_dropped = adapter->stats.mpc; adapter->net_stats.rx_length_errors = adapter->stats.rlec; adapter->net_stats.rx_crc_errors = adapter->stats.crcerrs; adapter->net_stats.rx_frame_errors = adapter->stats.algnerrc; From herbert@gondor.apana.org.au Fri Apr 29 03:18:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 03:19:06 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TAIq7J006435 for ; Fri, 29 Apr 2005 03:18:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DRSZz-0007yM-00; Fri, 29 Apr 2005 20:18:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DRSZw-0000b5-00; Fri, 29 Apr 2005 20:18:36 +1000 Date: Fri, 29 Apr 2005 20:18:36 +1000 To: Tommy Christensen Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost Message-ID: <20050429101836.GA2237@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> <20050427234359.GB22238@gondor.apana.org.au> <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1394 Lines: 42 On Fri, Apr 29, 2005 at 11:51:48AM +0200, Tommy Christensen wrote: > > Originally, I was afraid it could get too trigger happy, so I left > this idea. Perhaps that's not such a big deal afterall. Even if it does flap we've still got the built-in one second flap-protection of link_watch. > How does this look? Much better :) > @@ -74,6 +75,12 @@ > clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); > > if (dev->flags & IFF_UP) { > + if (netif_carrier_ok(dev)) { > + if (dev->qdisc_sleeping != &noop_qdisc) > + dev_activate(dev); I don't see how qdisc_sleeping can be noop_qdisc unless there is a bug. So why not convert this to a BUG_ON? > diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c > --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 > +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-04-29 11:22:05.420250195 +0200 > @@ -539,6 +539,10 @@ > write_unlock_bh(&qdisc_tree_lock); > } > > + if (!netif_carrier_ok(dev) && netif_queue_stopped(dev)) > + /* Delay activation until next carrier-on event */ > + return; How about moving this check into dev_open? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Fri Apr 29 03:41:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 03:41:45 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TAfY7J007869 for ; Fri, 29 Apr 2005 03:41:35 -0700 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j3TAf65t031639; Fri, 29 Apr 2005 14:41:06 +0400 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.12.11/8.12.1/Submit) id j3TAf3Si031621; Fri, 29 Apr 2005 14:41:03 +0400 Date: Fri, 29 Apr 2005 14:41:03 +0400 From: Evgeniy Polyakov To: netdev@oss.sgi.com Cc: Herbert Xu , Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050429144103.A23268@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [0.0.0.0]); Fri, 29 Apr 2005 14:41:06 +0400 (MSD) X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 3579 Lines: 147 Hello. I've created POC code to perform asynchronous IPsec [ESP] processing. Please comment about bugs in the following patch. It of course very dirty - but it is only begining, I just want to know if approach is right. Patch was tested with several ssh session and some traffic like find / and tcpdump over them. Thank you. diff -ru ../linux-2.6-orig/net/ipv4/esp4.c ./net/ipv4/esp4.c --- ../linux-2.6-orig/net/ipv4/esp4.c 2005-04-25 15:41:39.000000000 +0400 +++ ./net/ipv4/esp4.c 2005-04-29 14:34:10.000000000 +0400 @@ -7,6 +7,7 @@ #include #include #include +#include #include #include @@ -17,6 +18,95 @@ __u8 proto; }; +static int esp_output(struct xfrm_state *x, struct sk_buff *skb); + +struct esp_async { + struct timer_list tm; + struct sk_buff *skb; + struct xfrm_state *x; + struct dst_entry *dst; +}; + +static void esp4_callback(unsigned long data) +{ + struct esp_async *ea = (struct esp_async *)data; + struct sk_buff *skb = ea->skb; + struct dst_entry *dst = ea->dst; + struct xfrm_state *x = ea->x; + int err; + + printk("%s: skb=%p, skb->users=%d.\n", __func__, skb, atomic_read(&skb->users)); + printk("%s: dst=%p, skb->dst=%p.\n", __func__, dst, skb->dst); + printk("%s: xfrm=%p, skb->dst->xfrm=%p.\n", __func__, x, (skb->dst)?skb->dst->xfrm:NULL); + + spin_lock_bh(&x->lock); + err = esp_output(x, skb); + spin_unlock_bh(&x->lock); + + printk("%s: Data has been processed: err=%d.\n", __func__, err); + + if (err) + goto err_out; + + skb->dst = dst_pop(dst); + printk("%s: pop has been finished: skb->dst=%p, dst=%p, skb->users=%d.\n", + __func__, skb->dst, dst, atomic_read(&skb->users)); + if (!skb->dst) + goto err_out; + + dst_output(skb); + +out: + kfree(ea); + return; + +err_out: + kfree_skb(skb); + goto out; +} + +static int esp_output_async(struct xfrm_state *x, struct sk_buff *skb) +{ + struct esp_async *ea; + struct dst_entry *child; + + printk("%s: enter. Child list: ", __func__); + for (child = skb->dst; child; child = child->child) + printk("%p [%s] [%d] -> ", child, child->dev->name, atomic_read(&child->__refcnt)); + printk("\n"); + + ea = kmalloc(sizeof(*ea), GFP_ATOMIC); + if (!ea) + return -ENOMEM; + + memset(ea, 0, sizeof(*ea)); + + skb = skb_clone(skb, GFP_ATOMIC); + if (!skb) + return -ENOMEM; + dst_hold(skb->dst); + + ea->skb = skb; + ea->x = x; + ea->dst = skb->dst; + + printk("%s: x=%p, skb=%p, skb->dst=%p, skb->dst->xfrm=%p.\n", + __func__, x, skb, skb->dst, skb->dst->xfrm); + + init_timer(&ea->tm); + ea->tm.function = &esp4_callback; + ea->tm.data = (unsigned long)ea; + ea->tm.expires = jiffies; + + add_timer(&ea->tm); + + printk("%s: timer added: skb->users=%d.\n", __func__, atomic_read(&skb->users)); + + return 0; + +} + + static int esp_output(struct xfrm_state *x, struct sk_buff *skb) { int err; @@ -465,7 +555,7 @@ .get_max_size = esp4_get_max_size, .input = esp_input, .post_input = esp_post_input, - .output = esp_output + .output = esp_output_async }; static struct net_protocol esp4_protocol = { diff -ru ../linux-2.6-orig/net/ipv4/xfrm4_output.c ./net/ipv4/xfrm4_output.c --- ../linux-2.6-orig/net/ipv4/xfrm4_output.c 2005-04-25 15:41:40.000000000 +0400 +++ ./net/ipv4/xfrm4_output.c 2005-04-29 12:13:41.000000000 +0400 @@ -124,12 +124,6 @@ x->curlft.packets++; spin_unlock_bh(&x->lock); - - if (!(skb->dst = dst_pop(dst))) { - err = -EHOSTUNREACH; - goto error_nolock; - } - err = NET_XMIT_BYPASS; out_exit: return err; -- Evgeniy Polyakov From tommy.christensen@tpack.net Fri Apr 29 05:22:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:22:49 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3TCMf7J015498 for ; Fri, 29 Apr 2005 05:22:42 -0700 Received: (qmail 24928 invoked from network); 29 Apr 2005 12:22:36 -0000 Received: from tsc-6.cph.tpack.net (HELO ?192.168.9.22?) (192.168.9.22) by 0 with SMTP; 29 Apr 2005 12:22:36 -0000 Subject: Re: [PATCH] net: Disable queueing when carrier is lost From: Tommy Christensen To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <20050429101836.GA2237@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> <20050427234359.GB22238@gondor.apana.org.au> <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> <20050429101836.GA2237@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="=-hX5Sj6f8b3ADswQ3SGCz" Message-Id: <1114777355.4695.1598.camel@tsc-6.cph.tpack.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 29 Apr 2005 14:22:36 +0200 X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Content-Length: 3025 Lines: 89 --=-hX5Sj6f8b3ADswQ3SGCz Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-04-29 at 12:18, Herbert Xu wrote: > On Fri, Apr 29, 2005 at 11:51:48AM +0200, Tommy Christensen wrote: > > @@ -74,6 +75,12 @@ > > clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); > > > > if (dev->flags & IFF_UP) { > > + if (netif_carrier_ok(dev)) { > > + if (dev->qdisc_sleeping != &noop_qdisc) > > + dev_activate(dev); > > I don't see how qdisc_sleeping can be noop_qdisc unless there is a bug. > So why not convert this to a BUG_ON? Calling dev->open instead of dev_open leads to this. Probably that shouldn't be allowed anyway. But since it doesn't hurt us here, I'd rather settle for a WARN_ON. > > diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c > > --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 > > +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-04-29 11:22:05.420250195 +0200 > > @@ -539,6 +539,10 @@ > > write_unlock_bh(&qdisc_tree_lock); > > } > > > > + if (!netif_carrier_ok(dev) && netif_queue_stopped(dev)) > > + /* Delay activation until next carrier-on event */ > > + return; > > How about moving this check into dev_open? But that would indeed leave qdisc_sleeping set to noop_qdisc, wouldn't it? Besides, I wanted to catch qdisc changes done by tc as well. Signed-off-by: Tommy S. Christensen --=-hX5Sj6f8b3ADswQ3SGCz Content-Description: Content-Disposition: inline; filename=carrier-3.patch Content-Type: text/x-patch; charset=iso-8859-1 Content-Transfer-Encoding: 7bit diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-04-29 14:19:07.356024339 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + WARN_ON(dev->qdisc_sleeping == &noop_qdisc); + dev_activate(dev); + } else if (netif_queue_stopped(dev)) + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-04-29 11:22:05.420250195 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev) && netif_queue_stopped(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --=-hX5Sj6f8b3ADswQ3SGCz-- From linville@bilbo.tuxdriver.com Fri Apr 29 05:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:23:01 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TCMw7J015722 for ; Fri, 29 Apr 2005 05:22:59 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j3TCJig10950; Fri, 29 Apr 2005 08:19:44 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j3TCMoKQ031834; Fri, 29 Apr 2005 08:22:50 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j3TCMoAY031833; Fri, 29 Apr 2005 08:22:50 -0400 Date: Fri, 29 Apr 2005 08:22:50 -0400 From: "John W. Linville" To: Malli Chilakala Cc: netdev , "jgarzik@pobox.com" Subject: Re: [RESEND][PATCH net-drivers-2.6 0/16] e1000: driver update Message-ID: <20050429122250.GC31796@tuxdriver.com> Mail-Followup-To: Malli Chilakala , netdev , "jgarzik@pobox.com" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 213 Lines: 9 On Thu, Apr 28, 2005 at 07:38:17PM -0700, Malli Chilakala wrote: > 13. 82573 specific code & packet split code Patch 13 seems to be missing...? (2.4 version as well) -- John W. Linville linville@tuxdriver.com From linville@bilbo.tuxdriver.com Fri Apr 29 05:22:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:22:21 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TCMF7J015264 for ; Fri, 29 Apr 2005 05:22:16 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j3TCJ1g10938; Fri, 29 Apr 2005 08:19:01 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j3TCM7PO031828; Fri, 29 Apr 2005 08:22:07 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j3TCM7tE031827; Fri, 29 Apr 2005 08:22:07 -0400 Date: Fri, 29 Apr 2005 08:22:07 -0400 From: "John W. Linville" To: Malli Chilakala Cc: netdev , "jgarzik@pobox.com" Subject: Re: [resend][PATCH net-drivers-2.6 0/6] e100: driver update Message-ID: <20050429122206.GB31796@tuxdriver.com> Mail-Followup-To: Malli Chilakala , netdev , "jgarzik@pobox.com" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 258 Lines: 10 On Thu, Apr 28, 2005 at 07:16:46PM -0700, Malli Chilakala wrote: > 5. Performance optimizations to e100 Tx path > 6. Driver version, white space, comments, device id & other Patches 5 & 6 seem to be missing...? -- John W. Linville linville@tuxdriver.com From kaber@trash.net Fri Apr 29 05:17:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:17:08 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TCH07J014905 for ; Fri, 29 Apr 2005 05:17:01 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DRUQM-0004rC-H6; Fri, 29 Apr 2005 14:16:50 +0200 Message-ID: <427225B2.6010705@trash.net> Date: Fri, 29 Apr 2005 14:16:50 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Nicolas DICHTEL , netdev@oss.sgi.com, linux-net@vger.kernel.org, "David S. Miller" Subject: Re: Question about QOS References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> <426F42F0.9020609@6wind.com> <20050427114216.GV577@postel.suug.ch> In-Reply-To: <20050427114216.GV577@postel.suug.ch> Content-Type: multipart/mixed; boundary="------------030708050507000800080306" X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1978 Lines: 54 This is a multi-part message in MIME format. --------------030708050507000800080306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thomas Graf wrote: > * Nicolas DICHTEL <426F42F0.9020609@6wind.com> 2005-04-27 09:44 > >>>Yes I agree, it doesn't really matter what value we return and `bound' >>>is most likely to be correct. I think we should also fix the unlikely >>>but still possible case when tv1.tv_usec is slightly smaller than >>>tv2.tv_usec. I know it is very unlikely but do_gettimeofday really >>>is not that reliable and we have users which rely on a positive >>>delta. Can you extend your patch to return abs(delta) for case 0 >>>in PSCHED_TDIFF_SAFE? Why abs(delta)? It could be above bound, in fact all cases besides delta_sec > 2 doesn't take care to stay inside [0..bound] at all. --------------030708050507000800080306 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [PKT_SCHED]: Fix range in PSCHED_TDIFF_SAFE to 0..bound Signed-off-by: Patrick McHardy --- commit d5f65671be760f33c1c7667f793ed75ad6e6a710 tree 4af3018396f125b0c2601882d924e63a0d74bef4 parent 980207c270e72e2cc6ae7b0de6ea6cd38a726e5b author Patrick McHardy 1114776755 +0200 committer Patrick McHardy 1114776755 +0200 Index: include/net/pkt_sched.h =================================================================== --- e38e7620d369bfa898a2e3f6aaf2f04c8826f38e/include/net/pkt_sched.h (mode:100644 sha1:7352e455053cc857e70f0cb1e008eb7adabbe011) +++ 4af3018396f125b0c2601882d924e63a0d74bef4/include/net/pkt_sched.h (mode:100644 sha1:fcb05a387dbee560d6a0f20b6e8c3c4f1b2d93f1) @@ -157,7 +157,8 @@ case 1: \ __delta += 1000000; \ case 0: \ - __delta = abs(__delta); \ + if (__delta > bound || __delta < 0) \ + __delta = bound; \ } \ __delta; \ }) --------------030708050507000800080306-- From tgraf@suug.ch Fri Apr 29 05:38:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:39:02 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TCcv7J017960 for ; Fri, 29 Apr 2005 05:38:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 8CAEC1C0EB; Fri, 29 Apr 2005 14:39:08 +0200 (CEST) Date: Fri, 29 Apr 2005 14:39:08 +0200 From: Thomas Graf To: Patrick McHardy Cc: Nicolas DICHTEL , netdev@oss.sgi.com, linux-net@vger.kernel.org, "David S. Miller" Subject: Re: Question about QOS Message-ID: <20050429123908.GB577@postel.suug.ch> References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> <426F42F0.9020609@6wind.com> <20050427114216.GV577@postel.suug.ch> <427225B2.6010705@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427225B2.6010705@trash.net> X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 238 Lines: 5 * Patrick McHardy <427225B2.6010705@trash.net> 2005-04-29 14:16 > Why abs(delta)? It could be above bound, in fact all cases besides > delta_sec > 2 doesn't take care to stay inside [0..bound] at all. Doh, of course. Absolutely correct. From hadi@cyberus.ca Fri Apr 29 05:51:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 05:52:02 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TCpr7J018914 for ; Fri, 29 Apr 2005 05:51:54 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DRUyE-0006Oz-GV for netdev@oss.sgi.com; Fri, 29 Apr 2005 08:51:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DRUyA-00054T-R3; Fri, 29 Apr 2005 08:51:47 -0400 Subject: Re: patch2: del/get byid From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Alexey Kuznetsov , netdev@oss.sgi.com, "David S. Miller" In-Reply-To: <20050428231154.GA14215@gondor.apana.org.au> References: <1114654284.7663.50.camel@localhost.localdomain> <20050428021426.GA23415@gondor.apana.org.au> <1114655014.7663.61.camel@localhost.localdomain> <20050428022549.GA23556@gondor.apana.org.au> <1114655980.7663.76.camel@localhost.localdomain> <20050428024253.GA23695@gondor.apana.org.au> <1114656932.7663.88.camel@localhost.localdomain> <20050428030325.GB23823@gondor.apana.org.au> <1114658657.7663.110.camel@localhost.localdomain> <1114698033.7663.197.camel@localhost.localdomain> <20050428231154.GA14215@gondor.apana.org.au> Content-Type: text/plain Organization: unknown Date: Fri, 29 Apr 2005 08:51:44 -0400 Message-Id: <1114779104.7800.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 416 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: 810 Lines: 35 On Fri, 2005-29-04 at 09:11 +1000, Herbert Xu wrote: > Now that you are allowing the user to set the index, this excl check > really needs to go. Otherwise the user can add two policies with > the same index. Agreed. > > You also still need to solve the problem that you may need to > delete two policies if one matches the index while the other matches > the selector (or selector plus priority if you do that). > Ok, this bit is tricky... that is unless we disallowed it from happening in the first place maybe i.e something along the lines of: delp1 = find by index delp2 = find by selector if delp1 && delp2 and delp1 != delp2 return -EINVAL // so far good. check the add case if delp1 || delp2 and excl return -EEXIST do the insert here based on priority .. Thoughts? cheers, jamal From ak@muc.de Fri Apr 29 08:29:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 08:30:04 -0700 (PDT) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TFTj7J028170 for ; Fri, 29 Apr 2005 08:29:47 -0700 Received: (qmail 39967 invoked by uid 3709); 29 Apr 2005 15:29:39 -0000 Date: 29 Apr 2005 17:29:39 +0200 Date: Fri, 29 Apr 2005 17:29:39 +0200 From: Andi Kleen To: "David S. Miller" Cc: glen.turner@aarnet.edu.au, netdev@oss.sgi.com, mtk-lkml@gmx.net Subject: Re: network manpages was Re: is UDP_CORK "real" Message-ID: <20050429152939.GB38331@muc.de> References: <426833F0.9010803@hp.com> <426F2A1D.10001@aarnet.edu.au> <20050427122648.GA12597@muc.de> <20050427114323.53e43e32.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427114323.53e43e32.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 418 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: 784 Lines: 23 On Wed, Apr 27, 2005 at 11:43:23AM -0700, David S. Miller wrote: > On 27 Apr 2005 14:26:48 +0200 > Andi Kleen wrote: > > > It would be nice of course if David could enforce a policy > > to require a manpage patch for new ioctls/socket options etc. > > in the future, then such documentation lag would not happen. > > I could easily do this if the files were in the kernel tree > itself, but since it's external it's not so easy to do. Hmm, you could ask them at least to submit a patch. > > Why don't we put them into the kernel tree? They are just > small documents and I bet they will stay in sync better if > they were moved into the kernel tree. Well, you have to talk to Michael who maintains them now. I personally think it would be a good idea, yes. -Andi From ganesh.venkatesan@intel.com Fri Apr 29 08:54:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Apr 2005 08:54:36 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3TFsU7J030368 for ; Fri, 29 Apr 2005 08:54:31 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3TFsP5f017927; Fri, 29 Apr 2005 15:54:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3TFsH5f027311; Fri, 29 Apr 2005 15:54:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042908542531134 ; Fri, 29 Apr 2005 08:54:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 08:54:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: msleep_interruptible() in ethtool ioctl and keyboard input Date: Fri, 29 Apr 2005 08:54:23 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E05195E08@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: msleep_interruptible() in ethtool ioctl and keyboard input Thread-Index: AcVM07arVR5CRDUqSzWaE28yJRdwoQ== From: "Venkatesan, Ganesh" To: Cc: X-OriginalArrivalTime: 29 Apr 2005 15:54:25.0386 (UTC) FILETIME=[B7B574A0:01C54CD3] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3TFsU7J030368 X-archive-position: 419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2257 Lines: 64 In response of ethtool -p eth? [time], e1000 calls msleep_interruptible() to sleep for