From waldi@debian.org Tue Feb 1 00:21:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 00:21:50 -0800 (PST) Received: from wavehammer.waldi.eu.org (postfix@wavehammer.waldi.eu.org [82.139.196.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j118LgLa010982 for ; Tue, 1 Feb 2005 00:21:43 -0800 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id B5C1E3C02A; Tue, 1 Feb 2005 09:21:39 +0100 (CET) Date: Tue, 1 Feb 2005 09:21:39 +0100 From: Bastian Blank To: linux-kernel@vger.kernel.org, pavlic@de.ibm.com Cc: netdev@oss.sgi.com, davem@davemloft.net Subject: [RFC] device types for s390 network devices Message-ID: <20050201082139.GB31992@wavehammer.waldi.eu.org> Mail-Followup-To: linux-kernel@vger.kernel.org, pavlic@de.ibm.com, netdev@oss.sgi.com, davem@davemloft.net Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: waldi@debian.org Precedence: bulk X-list: netdev --H1spWtNR+x+ondvy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The s390 network devices specifies device types which does not match the reality. ctc =3D=3D=3D This device is currently specified as ARPHRD_SLIP. If I see it correctly, SLIP is an IP-only transport. ctc is more, the link level header contains the ethernet protocoll type, so it is some sort of pointopoint ethernet (which is sometimes crippled to IPv4-only for compatiblity reasons). qeth =3D=3D=3D=3D This device is currently specified as the corresponding real device type if it is a real adapter, or ARPHRD_ETHER if it is a virtual one. The virtual device behaves different in different modi: - "layer2": In this mode, the device behaves like a real layer 2 device. - "fake_ll": The kernel prepends a faked link level header. - default: The kernel processes the IP-packages. This is the most used mode, in whom it is impossible to use a standard libpcap as it parses the IP-headers as Ethernet. (IBM suggests to patch libpcap, but I think that changing the device type to something more matching is the correct solution.) At least the last part needs some fix, but I don't know how to fix if properly. Bastian --=20 The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8 --H1spWtNR+x+ondvy 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) iEYEARECAAYFAkH/PBMACgkQnw66O/MvCNF2kACfZfwLIsQfwOQN1FttPlez0RP1 1b4Ani15xbP7UoHepA/yvwXBP2a1Kxjy =38zD -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From au@unterluggauer.org Tue Feb 1 02:53:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 02:53:39 -0800 (PST) Received: from mail.unterluggauer.org (chello062178068189.23.11.vie.surfer.at [62.178.68.189]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11ArYZM019026 for ; Tue, 1 Feb 2005 02:53:35 -0800 Received: from litiusoft.usoft.at (litiusoft.usoft.at [192.168.2.5]) by mail.unterluggauer.org (8.12.11/8.12.11) with ESMTP id j11Ar3bf013171; Tue, 1 Feb 2005 11:53:03 +0100 From: Andreas Unterluggauer To: Herbert Xu Subject: Re: Fw: [Bugme-new] [Bug 4138] New: ipsec with racoon in transport mode with esp and ah hangs (problem is in xfrm_state_add) Date: Tue, 1 Feb 2005 11:53:02 +0100 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com, "David S. Miller" References: <200501311640.16118.au@unterluggauer.org> <20050131211102.GA20323@gondor.apana.org.au> In-Reply-To: <20050131211102.GA20323@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502011153.03284.au@unterluggauer.org> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: au@unterluggauer.org Precedence: bulk X-list: netdev Hallo Herbert, > On Mon, Jan 31, 2005 at 03:40:16PM +0000, Andreas Unterluggauer wrote: > > 2005-01-31 16:29:58: DEBUG: === > > 2005-01-31 16:29:58: DEBUG: get pfkey ADD message > > andi: libipsec/pfkey.c, pfkey_check: start (msg->sadb_msg_satype: 3) > > 2005-01-31 16:29:58: DEBUG: andi: in pfkey.c, pk_recvadd: > > msg->sadb_msg_seq 2, msg->sadb_msg_type: ADD 2005-01-31 16:29:58: INFO: > > IPsec-SA established: ESP/Transport 192.168.2.5->192.168.2.3 > > spi=103868257(0x630e761) 2005-01-31 16:29:58: DEBUG: === > > Does the machine hang at this point in time? If not, then this is > simply a racoon bug. Although the acquire message carries a policy > with it, it's really only acquiring a single SA. Therefore, only > the SA being acquired should be added with that sequence number. the machine (kernel) is not hanging! only the programm (e.g. ping ) is hanging until it gets a timeout. the kernel is acquiring a SA and racoon answers, and the kernel is acquiring and racoon answers ... until the user-programm stops. thanks for the information, that its a racoon (ipsec-tools) problem. I will contact the ipsec-tools developers. ciao andi From andy.furniss@dsl.pipex.com Tue Feb 1 03:32:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 03:32:21 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11BWF8c020548 for ; Tue, 1 Feb 2005 03:32:16 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 67097E0002A7; Tue, 1 Feb 2005 11:32:07 +0000 (GMT) Message-ID: <41FF68B8.5050208@dsl.pipex.com> Date: Tue, 01 Feb 2005 11:32:08 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Cc: netdev@oss.sgi.com Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> In-Reply-To: <1107123123.8021.80.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev I sent two replies to this thread last night, which haven't shown up yet - did anyone get them? Andy. From hadi@cyberus.ca Tue Feb 1 03:49:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 03:49:59 -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 j11BnrWv021303 for ; Tue, 1 Feb 2005 03:49:54 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CvwXU-0003QR-9v for netdev@oss.sgi.com; Tue, 01 Feb 2005 06:49:48 -0500 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 1CvwXP-0003LR-G4; Tue, 01 Feb 2005 06:49:43 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <41FEB3AE.3090400@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107258578.1095.570.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 06:49:40 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1144 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-01-31 at 17:39, Andy Furniss wrote: > Jamal Hadi Salim wrote: > > 2) Allows for queueing incoming traffic for shaping instead of > > dropping. I am not aware of any study that shows policing is > > worse than shaping in achieving the end goal of rate control. > > I would say the end goal is shaping not just rate control. Shaping > meaning different things to different people and ingress shaping being > different from egress. I know for a while the Bart howto was mislabeling the meaning of policing - not sure about shaping. Shaping has a precise definition that involves a queue and a non-working-conserving scheduler in order to rate control. This doesnt matter where it happens (egress or ingress). Policing on the other hand is work conserving etc. > For me it's from the wrong end of a relativly narrow (512kbit) > bottleneck link that has a 600ms fifo at the other end. My aim to > sacrifice as little bandwidth as possible while not adding latency > bursts for gaming and per user bandwidth allocation (with sharing of > unused) and sfq within that for bulk tcp traffic. > > If I was shaping LAN traffic, then policers/drops would be OK for me - > but for a slow link I think queueing and dropping are better/give more > control eg. I get to use sfq which should not drop the one packet a 56k > user has managed to send me in the face of lots of incoming from low > latency high bandwidth servers. > > Even if it's possible I bet few can easily get policers to setup the > complex sharing/prioritisations that you can with HTB or HFSC. sfq has a built in classifier that can efficiently separate those flows so you can achieve semi-fairness; so its not the shaping perse that helps, rather you ended up using a clever scheme that can isolate flows and benefited from shaping as a result; the hashing function should prove weak when a lot of flows start showing up. You could write some interesting classifier (as an example steal the one that sfq has) and achieve the same end results with policing. This would be easier now with ematches .. > > But i wont go back to putting netfilter hooks in the device to satisfy > > this. I also dont think its worth it hacking dummy some more to be > > aware of say L3 info and play ip rule tricks to achieve this. > > --> Instead the plan is to have a contrack related action. This action > > will selectively either query/create contrack state on incoming packets. > > I don't understand exactly what you mean here - for my setup to work I > need to see denatted addresses and mark (connbytes - it helps me be > extra nasty to multiple simoultaneous connections in slowstart and > prioritise browsing over bulk) in prerouting mangle. Of course if I can > use netfilter to classify and save into contrack then I could do > evrything in netfilter and then use something like connmark to save it > per connection. > You may be refering to requirement #3 then? In other words what you are doing is best served by knowing the state? Are pre/post routing sufficient as netfilter hooks for your case? > > Packets could then be redirected to dummy based on what happens -> eg > > on incoming packets; if we find they are of known state we could send to > > a different queue than one which didnt have existing state. This > > all however is dependent on whatever rules the admin enters. > > > How does the admin enter the rules - netfilter or other? > Just like i showed in that post (It was long - so dont wanna cutnpaste here). cheers, jamal From hadi@cyberus.ca Tue Feb 1 04:02:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 04:02:58 -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 j11C2qQT022537 for ; Tue, 1 Feb 2005 04:02:52 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Cvwk3-0008Bd-3w for netdev@oss.sgi.com; Tue, 01 Feb 2005 07:02:47 -0500 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 1Cvwjz-0004aM-OQ; Tue, 01 Feb 2005 07:02:44 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050131225328.GI31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107259361.1095.584.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 07:02:41 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1145 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-01-31 at 17:53, Thomas Graf wrote: > I was thinking of the parameters to define what a flow consists of. > Extended SFQ basically allows you to define the hash function. I think > I misunderstood you before and you don't want allow adjustable > states on only a subset of the attributes, e.g. only L3 data. Why bother putting extra classifier functionality into a qdisc? you should be able to rip off the classifier from sfq so you dont depend on it; you can then select one of n queues (eaction meta set class 1:X based on result of sfq classifier - or you can have it set the classids based on resulting hash index) > > I think the eactions etc are adding a lot of value towards usability. > > Hasso Tepper was ealrier complaining about this same issue. > > As an example, I think u32 and ematches would improve a great deal now > > and be more understandable. True, work/time still needs to be invested. > > I'd guess that the basic classifier will make the race because the > documentation will be smaller due to the lack of parameters. ;-> Well, even if it is just being able to describe in english the u32 parameters and displaying them in english (by using a ID stored) its already huge progress. > But yes I agree, I think we're making small step forwards and hopefully > the network config shell/tool/whatever will ease the steps to configure > things. My primary goal is to allow using it without looking up > parameters all the time, given one is aware of the common terms and basic > concepts. Online easy to use help is always valuable. > I'll have some more time next week and will try to implement the > traffic control bits or at least some of them. The wind forecast is pretty > good for the next days so I won't have too much time. ;-> Weather is also predicted to be good here for the week; we are planning to get out of our igloos and go tobagoning;-> cheers, jamal From tgraf@suug.ch Tue Feb 1 04:51:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 04:51:36 -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 j11CpUj5027701 for ; Tue, 1 Feb 2005 04:51:30 -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 7C07982; Tue, 1 Feb 2005 13:51:06 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 71E821C0EA; Tue, 1 Feb 2005 13:51:47 +0100 (CET) Date: Tue, 1 Feb 2005 13:51:47 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201125147.GK31837@postel.suug.ch> References: <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107259361.1095.584.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1146 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 > Why bother putting extra classifier functionality into a qdisc? > you should be able to rip off the classifier from sfq so you dont depend > on it; you can then select one of n queues (eaction meta set class 1:X > based on result of sfq classifier - or you can have it set the classids > based on resulting hash index) Excellent idea, this would allow for various hash functions to be used in a single sfq. We can use skb->tc_index for it so we can easly combine it with a underlying dsmark. The hardest part is to find a intuitive form to define the hash, it should be possible to for example define a hash based on daddr + hproto only completely ignoring saddr. The perutrbation must be made optional, sometimes the hash will not produce any unwanted collisions (hash based on dscp for example) so modifying it wouldn't make sense. We can fork sfq and make a gsfq which takes the hash from tc_index and disabled perturbation if it is set to 0. Thoughts? > Well, even if it is just being able to describe in english the u32 > parameters and displaying them in english (by using a ID stored) > its already huge progress. True. I've some notes on paper describing a match definition db which basically defines a u32 like match and assigns a name and id to it, it is stored in a external database file so everyone can define their own pre defined matches without recompiling. I've put together some code printing a tc tree as a whole and added it to netconfig. It's just a start and still contains redundant information which can be removed but I think it's already a step forward because it all gets down to one command. Currently it's only possible to filter on the device but I'll extend this later so one can extract a part of the tree. One pretty ugly thing is that cbq creates a qdisc and class with the same handle which gets quite confusing if one wants list the filters attached to a certain handle because they will show up for both, the qdisc and the root class. Full output for a default ethernet device: lsx# tc tree full where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 txqlen 1000 weight 64 qdisc pfifo_fast irq 19 index 4 brd ff:ff:ff:ff:ff:ff pfifo_fast qdisc dev eth0 handle none parent none bands 3 refcnt 1 priomap [1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1] besteffort => 1 0x8 => 1 filler => 2 0x9 => 1 bulk => 2 0xa => 1 0x3 => 2 0xb => 1 interactive_bulk => 1 0xc => 1 0x5 => 2 0xd => 1 interactive => 0 0xe => 1 control => 0 0xf => 1 Brief output for some cbq classes: lsx# tc tree where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 cbq qdisc dev eth0 handle 10: parent none rate 11.92MiB/s (95Mbit) prio 8 cbq class dev eth0 handle 10: parent root rate 11.92MiB/s (95Mbit) prio 8 u32 cls dev eth0 handle none parent 10: prio 10 protocol ip u32 cls dev eth0 handle 8000: parent 10: prio 10 protocol ip divisor 1 u32 cls dev eth0 handle 8000:800 parent 10: prio 10 protocol ip target 10:12 cbq class dev eth0 handle 10:12 parent 10: rate 11.92MiB/s (95Mbit) prio 3 sfq qdisc dev eth0 handle 8003: parent 10:12 quantum 1514 perturb 0us Full output with stats for some cbq classes: lsx# tc tree stats where device eth0 eth0 ether 00:02:44:63:ed:53 mtu 1500 txqlen 1000 weight 64 qdisc cbq irq 19 index 4 brd ff:ff:ff:ff:ff:ff Stats: bytes packets errors dropped fifo-err compressed RX 46.65 MiB 42211 0 0 0 0 TX 1.91 MiB 16234 0 0 0 0 Errors: length over crc frame missed multicast RX 0 0 0 0 0 0 Errors: aborted carrier heartbeat window collision TX 0 0 0 0 0 cbq qdisc dev eth0 handle 10: parent none rate 11.92MiB/s (95Mbit) prio 8 refcnt 1 avgpkt 1400 mpu 64 cell 16 allot 1514 weight 95Mbit minidle 65535999us maxidle 2us offtime 0us level 1 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 44.02 KiB 380 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 114 0 cbq class dev eth0 handle 10: parent root rate 11.92MiB/s (95Mbit) prio 8 avgpkt 1400 mpu 64 cell 16 allot 1514 weight 95Mbit minidle 65535999us maxidle 2us offtime 0us level 1 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 44.02 KiB 380 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 114 0 u32 cls dev eth0 handle none parent 10: prio 10 protocol ip Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps u32 cls dev eth0 handle 8000: parent 10: prio 10 protocol ip divisor 1 Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps u32 cls dev eth0 handle 8000:800 parent 10: prio 10 protocol ip target 10:12 nkeys 1 ht key 0x800 hash 0x0 match u32 at 8 & 0x00ff0000 == 0x00010000 successful 34 Stats: bytes packets drops overlimits qlen backlog 0.00 B 0 0 0 0 0 0.00 B/s 0 pps successful hits 34 379 cbq class dev eth0 handle 10:12 parent 10: rate 11.92MiB/s (95Mbit) prio 3 child-qdisc 8003: avgpkt 500 mpu 0 cell 8 allot 1514 weight 95Mbit minidle 65535999us maxidle 0us offtime 0us level 0 ewma_log 5 penalty 0us strategy classic split none defmap 0x00000000 police ok Stats: bytes packets drops overlimits qlen backlog 3.25 KiB 34 0 0 0 0 0.00 B/s 0 pps borrows overact avgidle undertime 0 0 40 0 sfq qdisc dev eth0 handle 8003: parent 10:12 quantum 1514 perturb 0us refcnt 1 limit 128 divisor 1024 flows 128 Stats: bytes packets drops overlimits qlen backlog 3.25 KiB 34 0 0 0 0 0.00 B/s 0 pps From hadi@cyberus.ca Tue Feb 1 05:13:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 05:13:50 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11DDhdP029189 for ; Tue, 1 Feb 2005 05:13:44 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1Cvxqb-0006Ew-Dc for netdev@oss.sgi.com; Tue, 01 Feb 2005 06:13:37 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Cvxqa-0005XU-7n; Tue, 01 Feb 2005 08:13:36 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050201125147.GK31837@postel.suug.ch> References: <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107263612.1095.598.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Feb 2005 08:13:33 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1147 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-02-01 at 07:51, Thomas Graf wrote: > > Why bother putting extra classifier functionality into a qdisc? > > you should be able to rip off the classifier from sfq so you dont depend > > on it; you can then select one of n queues (eaction meta set class 1:X > > based on result of sfq classifier - or you can have it set the classids > > based on resulting hash index) > > Excellent idea, this would allow for various hash functions to be used > in a single sfq. We can use skb->tc_index for it so we can easly combine Let the meta action do that. Just set the skb->tc_classid in my opinion; recall we can change classid now .. > it with a underlying dsmark. The hardest part is to find a intuitive > form to define the hash, it should be possible to for example define > a hash based on daddr + hproto only completely ignoring saddr. The > perutrbation must be made optional, sometimes the hash will not produce > any unwanted collisions (hash based on dscp for example) so modifying it > wouldn't make sense. We can fork sfq and make a gsfq which takes the > hash from tc_index and disabled perturbation if it is set to 0. > Thoughts? You can let the user define that via tc but have a default; eg: tc dev eth0 add sfq ematch tc dev eth0 set sfq pertub xxx match u32 ... ematch sfq ematch meta classid 1:2 eaction meta set tcindex 101 eaction meta set fwmark .. etc I have to run, havent looked at the rest of your email - will later. cheers, jamal From tgraf@suug.ch Tue Feb 1 05:31:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 05:31:25 -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 j11DVK97030050 for ; Tue, 1 Feb 2005 05:31:20 -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 4B45082; Tue, 1 Feb 2005 14:30:56 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4CB841C0EA; Tue, 1 Feb 2005 14:31:38 +0100 (CET) Date: Tue, 1 Feb 2005 14:31:38 +0100 From: Thomas Graf To: Andy Furniss Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201133138.GM31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FED514.7060702@dsl.pipex.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1148 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 > >> X = ---------------------------------------------------------- > >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) > >> > >>Where: > >> > >> X is the transmit rate in bytes/second. > >> s is the packet size in bytes. > >> R is the round trip time in seconds. > >> p is the loss event rate, between 0 and 1.0, of the number of loss > >> events as a fraction of the number of packets transmitted. > >> t_RTO is the TCP retransmission timeout value in seconds. > >> b is the number of packets acknowledged by a single TCP > >> acknowledgement. > > WRT policers I never figured out where you would put the effects of > playing with the burst size parameter and it's effects with few/many > connections and any burstiness caused into an equasion like that. A burst buffer has impact on R on later packets, it can "smooth" R and X and thus results in more stable rates. Depending on the actual burst, it can avoid retransmits which stabilizes the rate as well. > This sounds cool. For me in someways I think it could be nicer (in the > case of shaping from the wrong end of a slow link) to delay the real > packets - that way the tcps of the clients get to see the smoothed > version of the traffic and you can delay udp aswell. It's impossible to never drop anything, for udp we can either drop it or use ECN and hope the other ip stack takes care of it or the application implements its own cc algorithm. Basically you can already do that with (G)RED. Most UDP users which provide a continous stream such as video streams, implement some kind of key datagram which contains the number of datagrams received since the last key datagram and the application throttles down based on that so dropping is often the only way to achieve a general working solution. Delaying UDP packets and then drop them if the buffer is full is very dangerous, often the protocols based on UDP rely on the assumption that datagrams get lost randomly and not succcessive. We can think about precicse policing for UDP again once the current poor application level cc algorithms have failed and the industry accepted ECN as the right thing. For now most of them still suffer from the NIH syndrom in this area. > How intelligent and how much, if any, per connection state do you/could > you keep? I keep a rate estimator for every flow on ingress in a hash table and lookup it up on egress with the flow parameters reversed. It gets pretty expensive on huge amounts of connection usually one doesn't want to do per connection policing on such boxes. ;-> From linville@bilbo.tuxdriver.com Tue Feb 1 06:25:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 06:25:50 -0800 (PST) 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 j11EPhb7032035 for ; Tue, 1 Feb 2005 06:25:44 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j11EFcl23172; Tue, 1 Feb 2005 09:15:38 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j11EPYtw015189; Tue, 1 Feb 2005 09:25:34 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j11EPXWD015188; Tue, 1 Feb 2005 09:25:33 -0500 Date: Tue, 1 Feb 2005 09:25:33 -0500 From: "John W. Linville" To: Anton Blanchard Cc: Scott Feldman , jgarzik@pobox.com, netdev@oss.sgi.com, lunz@falooley.org Subject: Re: [PATCH 2.6] e100: remove reference to NAPI config option Message-ID: <20050201142533.GB15056@tuxdriver.com> Mail-Followup-To: Anton Blanchard , Scott Feldman , jgarzik@pobox.com, netdev@oss.sgi.com, lunz@falooley.org References: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> <20050201014358.GD15786@krispykreme.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201014358.GD15786@krispykreme.ozlabs.ibm.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1149 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 On Tue, Feb 01, 2005 at 12:43:58PM +1100, Anton Blanchard wrote: > > Hi Scott, > > > e100 is NAPI all the time, so the Kconfig option is wasting space. > > Speaking of NAPI... > > We have seen issues with NAPI on ppc64 on various cards in the past. Just curious...wanna try this patch I got from Intel? I think it may help... John --- linux-2.6.9/drivers/net/e100.c.napifix 2005-01-25 15:54:28.830937362 -0500 +++ linux-2.6.9/drivers/net/e100.c 2005-01-25 15:54:56.350257693 -0500 @@ -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 +516,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; @@ -1417,12 +1423,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; } } @@ -1473,7 +1485,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; @@ -1484,6 +1496,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); @@ -1516,20 +1532,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) @@ -1537,6 +1578,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) { @@ -1550,7 +1593,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) @@ -1559,6 +1601,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; @@ -1574,6 +1617,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; } @@ -1595,7 +1639,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); @@ -1611,6 +1655,7 @@ static int e100_poll(struct net_device * int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); + // should we be quota on tx? tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ @@ -1684,7 +1729,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 +1804,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; -- John W. Linville linville@tuxdriver.com From andy.furniss@dsl.pipex.com Tue Feb 1 06:53:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 06:53:44 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11ErdLA003342 for ; Tue, 1 Feb 2005 06:53:40 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 18C66E0002A4; Tue, 1 Feb 2005 14:53:28 +0000 (GMT) Message-ID: <41FF97E9.7040501@dsl.pipex.com> Date: Tue, 01 Feb 2005 14:53:29 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> In-Reply-To: <1107258578.1095.570.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev jamal wrote: > On Mon, 2005-01-31 at 17:39, Andy Furniss wrote: > >>Jamal Hadi Salim wrote: > > >>>2) Allows for queueing incoming traffic for shaping instead of >>>dropping. I am not aware of any study that shows policing is >>>worse than shaping in achieving the end goal of rate control. >> >>I would say the end goal is shaping not just rate control. Shaping >>meaning different things to different people and ingress shaping being >>different from egress. > > > I know for a while the Bart howto was mislabeling the meaning of > policing - not sure about shaping. > Shaping has a precise definition that involves a queue and a > non-working-conserving scheduler in order to rate control. This doesnt > matter where it happens (egress or ingress). Policing on the other hand > is work conserving etc. Ok, but shaping to LARTC posters means being able to classify traffic and set up sharing/priorotising of classes. This is the reason most need to be able to queue - they want to use htb/hfsc for complicated setups and until now were not aware that it was even possible to replicate this in policers and if it becomes feasable it will probably appear daunting to do compared with HTB and all the existing docs/scripts. For me, I think queuing and dropping is better than just dropping, you can affect tcp by delaying eg. 1 ack per packet rather than delayed acks and clocking out the packets helps smooth burstiness, which hurts latency if you are doing traffic control from the wrong end of the bottleneck. > >>For me it's from the wrong end of a relativly narrow (512kbit) >>bottleneck link that has a 600ms fifo at the other end. My aim to >>sacrifice as little bandwidth as possible while not adding latency >>bursts for gaming and per user bandwidth allocation (with sharing of >>unused) and sfq within that for bulk tcp traffic. >> >>If I was shaping LAN traffic, then policers/drops would be OK for me - >>but for a slow link I think queueing and dropping are better/give more >>control eg. I get to use sfq which should not drop the one packet a 56k >>user has managed to send me in the face of lots of incoming from low >>latency high bandwidth servers. >> >>Even if it's possible I bet few can easily get policers to setup the >>complex sharing/prioritisations that you can with HTB or HFSC. > > > sfq has a built in classifier that can efficiently separate those > flows so you can achieve semi-fairness; so its not the shaping perse > that helps, rather you ended up using a clever scheme that can isolate > flows and benefited from shaping as a result; the hashing function > should prove weak when a lot of flows start showing up. > You could write some interesting classifier (as an example steal the one > that sfq has) and achieve the same end results with policing. This would > be easier now with ematches .. The idea of loosing the s from sfq and doing multilevel hash/mapping is attractive - of course I would want to queue each flow and have the queue be variable length for each flow depending on occupancy of other flows. I suppose a per flow intelligent dropping scheme would be even better. It would be nice to be able to set/control queuelength for link bandwidth, nothing classful in linux tc does this. > > >>>But i wont go back to putting netfilter hooks in the device to satisfy >>>this. I also dont think its worth it hacking dummy some more to be >>>aware of say L3 info and play ip rule tricks to achieve this. >>>--> Instead the plan is to have a contrack related action. This action >>>will selectively either query/create contrack state on incoming packets. >> >>I don't understand exactly what you mean here - for my setup to work I >>need to see denatted addresses and mark (connbytes - it helps me be >>extra nasty to multiple simoultaneous connections in slowstart and >>prioritise browsing over bulk) in prerouting mangle. Of course if I can >>use netfilter to classify and save into contrack then I could do >>evrything in netfilter and then use something like connmark to save it >>per connection. >> > > > You may be refering to requirement #3 then? > In other words what you are doing is best served by knowing the state? As long as I could use netfilter to mark/classify connections then I think I can sort my setup, don't know about others. > Are pre/post routing sufficient as netfilter hooks for your case? Yes but depends on where in pre/postrouting. For me after/before nat, as I say above though I could workaround if I classify connections with netfilter. For others as long as they can filter on a mark/classify set in forward, then I think it will be OK for them. > > >>>Packets could then be redirected to dummy based on what happens -> eg >>>on incoming packets; if we find they are of known state we could send to >>>a different queue than one which didnt have existing state. This >>>all however is dependent on whatever rules the admin enters. >> >> >>How does the admin enter the rules - netfilter or other? >> > > Just like i showed in that post (It was long - so dont wanna cutnpaste > here). > I am not sure what exactly can can't be done in your example: ># redirect all IP packets arriving in eth0 to dummy0 ># use mark 1 --> puts them onto class 1:1 >$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ >match u32 0 0 flowid 1:1 \ What I can do here depends where it hooks packets. >action ipt -j MARK --set-mark 1 \ I don't know what table I am using - may be OK as long as I can test for a mark I made earlier in the egress dummy case or test connmark/state I set for that connection in the ingress case. >action mirred egress redirect dev dummy0 Andy. > cheers, > jamal > > From andy.furniss@dsl.pipex.com Tue Feb 1 07:04:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 07:04:06 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11F41CJ004128 for ; Tue, 1 Feb 2005 07:04:02 -0800 Received: from dsl.pipex.com (81-178-203-167.dsl.pipex.com [81.178.203.167]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 5A265E000239; Tue, 1 Feb 2005 15:03:49 +0000 (GMT) Message-ID: <41FF9A55.4080005@dsl.pipex.com> Date: Tue, 01 Feb 2005 15:03:49 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> <20050201133138.GM31837@postel.suug.ch> In-Reply-To: <20050201133138.GM31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Thomas Graf wrote: >>>> X = ---------------------------------------------------------- >>>> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) >>>> >>>>Where: >>>> >>>> X is the transmit rate in bytes/second. >>>> s is the packet size in bytes. >>>> R is the round trip time in seconds. >>>> p is the loss event rate, between 0 and 1.0, of the number of loss >>>> events as a fraction of the number of packets transmitted. >>>> t_RTO is the TCP retransmission timeout value in seconds. >>>> b is the number of packets acknowledged by a single TCP >>>> acknowledgement. >> >>WRT policers I never figured out where you would put the effects of >>playing with the burst size parameter and it's effects with few/many >>connections and any burstiness caused into an equasion like that. > > > A burst buffer has impact on R on later packets, it can "smooth" R > and X and thus results in more stable rates. Depending on the actual > burst, it can avoid retransmits which stabilizes the rate as well. But it's not a real rate limiting buffer in the policer case is it? > > >>This sounds cool. For me in someways I think it could be nicer (in the >>case of shaping from the wrong end of a slow link) to delay the real >>packets - that way the tcps of the clients get to see the smoothed >>version of the traffic and you can delay udp aswell. > > > It's impossible to never drop anything, for udp we can either drop > it or use ECN and hope the other ip stack takes care of it or the > application implements its own cc algorithm. Basically you can already > do that with (G)RED. Most UDP users which provide a continous stream > such as video streams, implement some kind of key datagram which contains > the number of datagrams received since the last key datagram and the > application throttles down based on that so dropping is often the only > way to achieve a general working solution. Delaying UDP packets and > then drop them if the buffer is full is very dangerous, often the > protocols based on UDP rely on the assumption that datagrams get lost > randomly and not succcessive. We can think about precicse policing > for UDP again once the current poor application level cc algorithms > have failed and the industry accepted ECN as the right thing. For > now most of them still suffer from the NIH syndrom in this area. Interesting stuff. I was thinking of game udp where just dropping would simulate what the user should have done anyway, but costing you bandwidth. If alot of gamers share a slow link then if you lag them out they know it's time to turn the rate down. > > >>How intelligent and how much, if any, per connection state do you/could >>you keep? > > > I keep a rate estimator for every flow on ingress in a hash table and > lookup it up on egress with the flow parameters reversed. It gets > pretty expensive on huge amounts of connection usually one doesn't > want to do per connection policing on such boxes. ;-> > Nice - are you planning to add anything to tweak things for the wrong end of the bottleneck problems? Andy. From sfeldma@pobox.com Tue Feb 1 11:10:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:10:19 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JAALn020342 for ; Tue, 1 Feb 2005 11:10:13 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id DC5B595; Tue, 1 Feb 2005 14:10:09 -0500 (EST) Received: from [192.168.0.3] (wbar2.sea1-4-5-062-153.sea1.dsl-verizon.net [4.5.62.153]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 4DA1189; Tue, 1 Feb 2005 14:10:08 -0500 (EST) Subject: [PATCH 2.6] eepro100: remove ID for 82556 From: Scott Feldman Reply-To: sfeldma@pobox.com To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1107285106.3366.106.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 01 Feb 2005 11:11:46 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1152 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 82556 support doesn't work with eepro100, so this removes the ID (0x1228) for 82556. See this thread for more info: http://marc.theaimsgroup.com/?l=linux-kernel&m=110726223221165&w=2 Signed-off-by: Scott Feldman --- linux-2.4.28-rc1/drivers/net/eepro100.c.orig 2005-02-01 10:58:56.878906632 -0800 +++ linux-2.4.28-rc1/drivers/net/eepro100.c 2005-02-01 10:59:10.479838976 -0800 @@ -2395,7 +2395,6 @@ { PCI_VENDOR_ID_INTEL, 0x1050, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1059, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1227, PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, 0x1228, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x2449, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x2459, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x245D, PCI_ANY_ID, PCI_ANY_ID, }, From olh@suse.de Tue Feb 1 11:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:27:47 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JRg8d021316 for ; Tue, 1 Feb 2005 11:27:43 -0800 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 Cantor.suse.de (Postfix) with ESMTP id 8875B13E97C4; Tue, 1 Feb 2005 20:27:36 +0100 (CET) Date: Tue, 1 Feb 2005 20:27:35 +0100 From: Olaf Hering To: Ganesh Venkatesan , netdev@oss.sgi.com Cc: linuxppc64-dev@ozlabs.org Subject: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Message-ID: <20050201192735.GB7433@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev We have this patch in SLES9 SP1. I asked google about 'fix for errata 23, cant cross 64kB boundary', and it shhows such a patch is also part of RH 2.6.9. It still applies to current Linus tree. Can you check wether this is still required for the current driver? References: SUSE48368 LTC12567 Need to check 64k boundary on DMA address as well. We also need to have 64k boundary checking on the DMA address that comes back from pci_map_single(). This address is what will be passed to the adapter on ppc64 for it to DMA into. It's the address that the adapter sees which will trip erratum 23. The so patched driver passed a quick netperf run and a weekend long stress test. diff -puN drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse drivers/net/e1000-new/e1000_main.c --- linux-2.6.5-7.127/drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse Wed Dec 8 16:55:46 2004 +++ linux-2.6.5-7.127-moilanen/drivers/net/e1000-new/e1000_main.c Thu Dec 9 15:46:04 2004 @@ -2579,6 +2579,29 @@ e1000_alloc_rx_buffers(struct e1000_adap adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + if(adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546) { + /* fix for errata 23, cant cross 64kB boundary */ + begin = (unsigned long)buffer_info->dma; + end = (unsigned long)(adapter->rx_buffer_len) - 1; + + if(!e1000_check_64k_alignment(adapter, begin, end)) { + + DPRINTK(RX_ERR,ERR,"dma align check failed: " + "begin: 0x%lx, end: 0x%lx\n", begin, end); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + 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); From jdmason@us.ibm.com Tue Feb 1 11:35:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:35:15 -0800 (PST) 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 j11JZBd5021959 for ; Tue, 1 Feb 2005 11:35:11 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j11JZ5Bu451188 for ; Tue, 1 Feb 2005 14:35:05 -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 j11JZ5Z6191154 for ; Tue, 1 Feb 2005 12:35:05 -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 j11JZ4P5009923 for ; Tue, 1 Feb 2005 12:35:04 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j11JZ4ZX009900; Tue, 1 Feb 2005 12:35:04 -0700 From: Jon Mason Organization: IBM To: Olaf Hering Subject: Re: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Date: Tue, 1 Feb 2005 13:33:59 -0600 User-Agent: KMail/1.7.2 Cc: Ganesh Venkatesan , netdev@oss.sgi.com, linuxppc64-dev@ozlabs.org References: <20050201192735.GB7433@suse.de> In-Reply-To: <20050201192735.GB7433@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502011333.59262.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev On Tuesday 01 February 2005 01:27 pm, Olaf Hering wrote: > > We have this patch in SLES9 SP1. > I asked google about 'fix for errata 23, cant cross 64kB boundary', and > it shhows such a patch is also part of RH 2.6.9. > It still applies to current Linus tree. > Can you check wether this is still required for the current driver? This patch is still lacking from the latest e1000 driver. Intel has the patch in their queue, so it will be needed until they release their next version of the e1000 driver. From ganesh.venkatesan@intel.com Tue Feb 1 11:36:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:36:45 -0800 (PST) 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 j11JacM3022319 for ; Tue, 1 Feb 2005 11:36:39 -0800 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 j11JaX0q020535; Tue, 1 Feb 2005 19:36:33 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 j11Ja4Dq012823; Tue, 1 Feb 2005 19:36:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005020111363315138 ; Tue, 01 Feb 2005 11:36:33 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 11:36:32 -0800 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] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Date: Tue, 1 Feb 2005 11:36:31 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Thread-Index: AcUIlBtNJPyOId/LRwe3DRCCmZqjywAANlzQ From: "Venkatesan, Ganesh" To: "Olaf Hering" , Cc: , "Ronciak, John" , "Brandeburg, Jesse" X-OriginalArrivalTime: 01 Feb 2005 19:36:32.0975 (UTC) FILETIME=[55A1E5F0:01C50895] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j11JacM3022319 X-archive-position: 1155 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 The patch attached to your mail does not seem to be complete. Did the mail application truncate? In any case, this fix is required in e1000. It is *not* in the latest driver that is released but *is* in the driver that is lined up for release in a couple of weeks. Thanks, Ganesh. >-----Original Message----- >From: Olaf Hering [mailto:olh@suse.de] >Sent: Tuesday, February 01, 2005 11:28 AM >To: Venkatesan, Ganesh; netdev@oss.sgi.com >Cc: linuxppc64-dev@ozlabs.org >Subject: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption >when DMA crosses a 64k boundary > > >We have this patch in SLES9 SP1. >I asked google about 'fix for errata 23, cant cross 64kB boundary', and >it shhows such a patch is also part of RH 2.6.9. >It still applies to current Linus tree. >Can you check wether this is still required for the current driver? > > >References: SUSE48368 LTC12567 > >Need to check 64k boundary on DMA address as well. > >We also need to have 64k boundary checking on the DMA address >that comes back from pci_map_single(). This address is what will >be passed to the adapter on ppc64 for it to DMA into. It's the >address that the adapter sees which will trip erratum 23. > >The so patched driver passed a quick netperf run and a weekend >long stress test. > >diff -puN drivers/net/e1000-new/e1000_main.c~64k-align-check-dma-suse >drivers/net/e1000-new/e1000_main.c >--- linux-2.6.5-7.127/drivers/net/e1000-new/e1000_main.c~64k-align-check- >dma-suse Wed Dec 8 16:55:46 2004 >+++ linux-2.6.5-7.127-moilanen/drivers/net/e1000-new/e1000_main.c Thu Dec >9 15:46:04 2004 >@@ -2579,6 +2579,29 @@ e1000_alloc_rx_buffers(struct e1000_adap > adapter->rx_buffer_len, > PCI_DMA_FROMDEVICE); > >+ if(adapter->hw.mac_type == e1000_82545 || >+ adapter->hw.mac_type == e1000_82546) { >+ /* fix for errata 23, cant cross 64kB boundary */ >+ begin = (unsigned long)buffer_info->dma; >+ end = (unsigned long)(adapter->rx_buffer_len) - 1; >+ >+ if(!e1000_check_64k_alignment(adapter, begin, end)) { >+ >+ DPRINTK(RX_ERR,ERR,"dma align check failed: " >+ "begin: 0x%lx, end: 0x%lx\n", begin, end); >+ >+ dev_kfree_skb(skb); >+ buffer_info->skb = NULL; >+ >+ 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); > From olh@suse.de Tue Feb 1 11:40:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 11:40:22 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11JeHjG022986 for ; Tue, 1 Feb 2005 11:40:18 -0800 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 Cantor.suse.de (Postfix) with ESMTP id 3C26613DD392; Tue, 1 Feb 2005 20:40:11 +0100 (CET) Date: Tue, 1 Feb 2005 20:40:10 +0100 From: Olaf Hering To: "Venkatesan, Ganesh" Cc: netdev@oss.sgi.com, linuxppc64-dev@ozlabs.org, "Ronciak, John" , "Brandeburg, Jesse" Subject: Re: [PATCH] e1000, errata 2{3,4} - possible EEH or memory corruption when DMA crosses a 64k boundary Message-ID: <20050201194010.GA7892@suse.de> References: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <468F3FDA28AA87429AD807992E22D07E041A065B@orsmsx408> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev On Tue, Feb 01, Venkatesan, Ganesh wrote: > In any case, this fix is required in e1000. It is *not* in the latest > driver that is released but *is* in the driver that is lined up for > release in a couple of weeks. Thats good enough, just that things dont get lost. There are probably a few separate patches for each problem found. We are still in the process of sorting out our +2k patch mess. From xose@wanadoo.es Tue Feb 1 12:18:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 12:18:04 -0800 (PST) Received: from smtp2.jazztel.es (smtp2.jazztel.es [62.14.3.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KHxbM024228 for ; Tue, 1 Feb 2005 12:18:00 -0800 Received: from antivirus by smtp2.jazztel.es with antivirus id 1Cw4TW-0007OK-00 Tue, 01 Feb 2005 21:18:14 +0100 Received: from [212.106.207.199] (helo=wanadoo.es) by smtp2.jazztel.es with esmtp id 1Cw4TW-0007Mb-00 Tue, 01 Feb 2005 21:18:14 +0100 Message-ID: <41FFE3EB.5050603@wanadoo.es> Date: Tue, 01 Feb 2005 21:17:47 +0100 From: Xose Vazquez Perez User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.3) Gecko/20041005 X-Accept-Language: gl, es, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: jgarzik@pobox.com Subject: [ PATCH ] 2.6 eepro100: replace and delete duplicate ids References: <3FBA97E4.1060004@wanadoo.es> In-Reply-To: <3FBA97E4.1060004@wanadoo.es> Content-Type: multipart/mixed; boundary="------------040809020605060701090308" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by antivirus X-Virus-Status: Clean X-archive-position: 1157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xose@wanadoo.es Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040809020605060701090308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, - replace PCI_DEVICE_ID_INTEL_82557 and PCI_DEVICE_ID_INTEL_82559ER with theirs hex numbers - PCI_DEVICE_ID_INTEL_82801BA_7 is a duplicate of 0x2449. -thanks- --------------040809020605060701090308 Content-Type: text/plain; name="eepro100_ids.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100_ids.diff" --- linux2/drivers/net/eepro100.c 2005-01-22 19:22:54.000000000 +0100 +++ n/drivers/net/eepro100.c 2005-02-01 21:10:15.000000000 +0100 @@ -2355,12 +2355,8 @@ } static struct pci_device_id eepro100_pci_tbl[] = { - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82557, - PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82559ER, - PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_7, - PCI_ANY_ID, PCI_ANY_ID, }, + { PCI_VENDOR_ID_INTEL, 0x1229, PCI_ANY_ID, PCI_ANY_ID, }, + { PCI_VENDOR_ID_INTEL, 0x1209, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1029, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1030, PCI_ANY_ID, PCI_ANY_ID, }, { PCI_VENDOR_ID_INTEL, 0x1031, PCI_ANY_ID, PCI_ANY_ID, }, --------------040809020605060701090308-- From laurent.deniel@free.fr Tue Feb 1 12:49:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 12:49:33 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KnH2r030126 for ; Tue, 1 Feb 2005 12:49:26 -0800 Received: from [192.168.1.108] (robinson-6-82-224-198-22.fbx.proxad.net [82.224.198.22]) by postfix3-2.free.fr (Postfix) with ESMTP id 03BEDC3A8 for ; Tue, 1 Feb 2005 21:49:14 +0100 (CET) Message-ID: <41FFEB4A.90400@free.fr> Date: Tue, 01 Feb 2005 21:49:14 +0100 From: Laurent Deniel Organization: Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [patch] superfluous CAP_NET_ADMIN required for some ioctl Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@free.fr Precedence: bulk X-list: netdev Hi, It should be possible to obtain bonding information with SIOCBOND[SLAVE]INFOQUERY ioctls without root privilege (like with /proc/net/bonding/bond? or ifconfig). Laurent Signed-off-by: Laurent Deniel --- linux-2.6.9.orig/net/core/dev.c 2005-01-08 17:29:55.000000000 +0100 +++ linux-2.6.9/net/core/dev.c 2005-01-08 18:00:01.000000000 +0100 @@ -2692,8 +2692,6 @@ int dev_ioctl(unsigned int cmd, void __u case SIOCBONDENSLAVE: case SIOCBONDRELEASE: case SIOCBONDSETHWADDR: - case SIOCBONDSLAVEINFOQUERY: - case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: case SIOCBRADDIF: case SIOCBRDELIF: @@ -2705,6 +2703,20 @@ int dev_ioctl(unsigned int cmd, void __u rtnl_unlock(); return ret; + /* + * These ioctl calls: + * - can be done by all. + * - require strict serialization. + * - return a value (but already copied to user) + */ + case SIOCBONDSLAVEINFOQUERY: + case SIOCBONDINFOQUERY: + dev_load(ifr.ifr_name); + rtnl_lock(); + ret = dev_ifsioc(&ifr, cmd); + rtnl_unlock(); + return ret; + case SIOCGIFMEM: /* Get the per device memory space. We can add this but * currently do not support it */ From dcbw@redhat.com Tue Feb 1 13:42:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:42:13 -0800 (PST) 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 j11Lg8v6032467 for ; Tue, 1 Feb 2005 13:42:09 -0800 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 j11Lg7wZ025026; Tue, 1 Feb 2005 16:42:07 -0500 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 j11Lg7O25000; Tue, 1 Feb 2005 16:42:07 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11Lg6QO028445; Tue, 1 Feb 2005 16:42:06 -0500 Subject: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-k4QhFYTzadIYmllFUtUs" Date: Tue, 01 Feb 2005 16:42:06 -0500 Message-Id: <1107294126.17332.16.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-k4QhFYTzadIYmllFUtUs Content-Type: text/plain Content-Transfer-Encoding: 7bit Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct entries in sysfs. Seems like somebody meant to do this but it got lost. atmel_cs.c was previously fixed to pass in the correct struct device * via handle_to_dev() but the driver never actually used it. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; --=-k4QhFYTzadIYmllFUtUs Content-Disposition: attachment; filename=atmel-NETDEV-fix.patch Content-Type: text/x-patch; name=atmel-NETDEV-fix.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; --=-k4QhFYTzadIYmllFUtUs-- From dale@the-martins.org Tue Feb 1 13:56:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:27 -0800 (PST) Received: from smtp3.fuse.net (mail-out3.fuse.net [216.68.8.176]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11LuH1u000747 for ; Tue, 1 Feb 2005 13:56:18 -0800 Received: from gx6.fuse.net ([66.42.247.210]) by smtp3.fuse.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050201215335.QRGY12240.smtp3.fuse.net@gx6.fuse.net> for ; Tue, 1 Feb 2005 16:53:35 -0500 Received: from chinchilla.toadis.porkis ([66.42.247.210]) by gx6.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20050201215302.YRPC26160.gx6.fuse.net@chinchilla.toadis.porkis> for ; Tue, 1 Feb 2005 16:53:02 -0500 Received: from gerbil.toadis.porkis (localhost.localdomain) [192.168.10.2] by chinchilla.toadis.porkis with smtp (Exim 3.35 #1 (Debian)) id 1Cw60F-0000fa-00; Tue, 01 Feb 2005 16:56:07 -0500 Received: by localhost.localdomain (sSMTP sendmail emulation); Tue, 1 Feb 2005 16:56:07 -0500 Date: Tue, 1 Feb 2005 16:56:07 -0500 From: "Dale E. Martin" To: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050201215607.GA8530@gerbil.toadis.porkis> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20050131222342.GB13217@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@the-martins.org Precedence: bulk X-list: netdev --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Typical symptoms: the card works fine until 64 (256) packets are sent > (received) then "Good bye Charlie". Yep, that was it. Recompiled with gcc 3.3 and it seems to be working now, although it looks like the card is only found on cold boots. The irony of this, btw, is that linux/Documentation/Changes still recommends gcc 2.95.3 - even in version 2.6.8, possibly in 2.6.10. (I think I saw it in there but I don't have it handy.) Also, when I first started looking at this, I tried to #define RTL8169_DEBUG but was getting compile errors. Should I file a bug about this? > If it works, I'll gladly welcome an 'lspci -vx' + complete dmesg for my > collection. Attached. The box says "Zonet Gigabit Ethernet 32 bit Adapter" and "Model ZEN3300E". The Linksys card in the lspci output is not connected to anything and I did not load the tulip module that supports it. (I was trying to ease switching back to it since the gigE card kept locking up!) It looks like the poor 1Ghz C3 in this machine is going to be the bottleneck for getting good transfer rates over gigabit ethernet ;-) > Btw, you can test the patch below (on top of 2.4.28, no bad report so far): > http://www.fr.zoreil.com/~romieu/misc/20041209-2.4.28-r8169.c-test.patch What is the intention of this patch? Is it to handle the 2.95.x issue or something else? Thanks for the help! Dale -- Dale E. Martin - dale@the-martins.org http://the-martins.org/~dmartin --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stuff.txt" 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3123 Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, 66Mhz, medium devsel, latency 8 Memory at e0000000 (32-bit, prefetchable) [size=64M] Capabilities: 00: 06 11 23 31 06 00 30 a2 00 00 00 06 00 08 00 00 10: 08 00 00 e0 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 06 11 01 cc 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 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 Memory behind bridge: e8000000-e9ffffff Prefetchable memory behind bridge: e4000000-e7ffffff Capabilities: 00: 06 11 91 b0 07 01 30 a2 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: 00 e8 f0 e9 00 e4 f0 e7 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00 00:08.0 SCSI storage controller: BusLogic Flashpoint LT (rev 01) Flags: bus master, fast devsel, latency 32, IRQ 11 I/O ports at d000 [size=256] Memory at eb000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=32K] 00: 4b 10 30 81 07 00 00 00 01 00 00 01 08 20 00 00 10: 01 d0 00 00 00 00 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 08 08 00:09.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) Subsystem: Linksys: Unknown device 0574 Flags: bus master, medium devsel, latency 32, IRQ 7 I/O ports at d400 [size=256] Memory at eb001000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at [disabled] [size=128K] Capabilities: 00: 17 13 85 09 07 00 90 02 11 00 00 02 08 20 00 00 10: 01 d4 00 00 00 10 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 02 02 00 00 17 13 74 05 30: 00 00 00 00 c0 00 00 00 00 00 00 00 07 01 ff ff 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8169 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8169 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 5 I/O ports at d800 [size=256] Memory at eb002000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=128K] Capabilities: 00: ec 10 69 81 07 00 b0 02 10 00 00 02 08 40 00 00 10: 01 d8 00 00 00 20 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 20 40 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at dc00 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 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 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 7 I/O ports at e000 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e0 00 00 00 00 00 00 00 00 00 00 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 07 02 00 00 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. UHCI USB Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at e400 [size=32] Capabilities: 00: 06 11 38 30 07 00 10 02 80 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e4 00 00 00 00 00 00 00 00 00 00 06 11 38 30 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 03 00 00 00:10.3 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev 82) (prog-if 20) Subsystem: VIA Technologies, Inc.: Unknown device 3104 Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at eb003000 (32-bit, non-prefetchable) [size=256] Capabilities: 00: 06 11 04 31 17 00 10 02 82 20 03 0c 08 20 00 00 10: 00 30 00 eb 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 06 11 04 31 30: 00 00 00 00 80 00 00 00 00 00 00 00 03 04 00 00 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177 Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: 00: 06 11 77 31 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 06 11 01 cc 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc.: Unknown device cc01 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at e800 [size=16] Capabilities: 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 e8 00 00 00 00 00 00 00 00 00 00 06 11 01 cc 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74) Subsystem: VIA Technologies, Inc.: Unknown device 0102 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ec00 [size=256] Memory at eb004000 (32-bit, non-prefetchable) [size=256] Capabilities: 00: 06 11 65 30 07 00 10 02 74 00 00 02 08 20 00 00 10: 01 ec 00 00 00 40 00 eb 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 02 01 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 03 08 01:00.0 VGA compatible controller: VIA Technologies, Inc.: Unknown device 3122 (rev 03) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc.: Unknown device 3122 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e4000000 (32-bit, prefetchable) [size=64M] Memory at e8000000 (32-bit, non-prefetchable) [size=16M] Expansion ROM at [disabled] [size=64K] Capabilities: 00: 06 11 22 31 07 00 10 02 03 00 00 03 00 20 00 00 10: 08 00 00 e4 00 00 00 e8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 22 31 30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 01 02 00 Linux version 2.4.28 (root@chinchilla) (gcc version 3.3 (Debian)) #3 Tue Feb 1 16:24:24 EST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000eff0000 (usable) BIOS-e820: 000000000eff0000 - 000000000eff3000 (ACPI NVS) BIOS-e820: 000000000eff3000 - 000000000f000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 239MB LOWMEM available. On node 0 totalpages: 61424 zone(0): 4096 pages. zone(1): 57328 pages. zone(2): 0 pages. ACPI: RSDP (v000 VT9174 ) @ 0x000f6500 ACPI: RSDT (v001 VT9174 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0eff3000 ACPI: FADT (v001 VT9174 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0eff3040 ACPI: DSDT (v001 VT9174 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 Kernel command line: root=/dev/hdb3 ro vga=792 rootflags=data=journal No local APIC present or hardware disabled Initializing CPU#0 Detected 998.323 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1992.29 BogoMIPS Memory: 239484k/245696k available (1840k kernel code, 5824k reserved, 682k data, 140k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After generic, caps: 00803135 80803035 00000000 00000000 CPU: Common caps: 00803135 80803035 00000000 00000000 CPU: Centaur VIA C3 Ezra stepping 09 Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Level Trigger. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20040326 PCI: PCI BIOS revision 2.10 entry at 0xfb0c0, last bus=1 PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S4 S5) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) 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: Probing PCI hardware ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 3 PCI: Using ACPI for IRQ routing Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 okir@monad.swb.de). ACPI: Power Button (FF) [PWRF] pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled kmod: failed to exec /sbin/modprobe -s -k parport_lowlevel, errno = 2 lp: driver loaded but no devices found Real Time Clock Driver v1.10f Non-volatile memory driver v1.2 ipmi: message handler initialized FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 189M agpgart: Detected Via CLE266 chipset agpgart: AGP aperture is 64M @ 0xe0000000 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe808-0xe80f, BIOS settings: hdc:pio, hdd:pio hda: WDC WD100BA, ATA DISK drive hdb: ST3200822A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: attached ide-disk driver. hda: host protected area => 1 hda: 19541088 sectors (10005 MB) w/2048KiB Cache, CHS=1216/255/63 hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 390721968 sectors (200050 MB) w/8192KiB Cache, CHS=24321/255/63 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 hdb3 SCSI subsystem driver Revision: 1.00 scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-950 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.02, I/O Address: 0xD000, IRQ Channel: 11/Level scsi0: PCI Bus: 0, Device: 8, Address: 0xEB000000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Fast, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: Error Recovery Strategy: Default, SCSI Bus Reset: Enabled scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled scsi0: *** BusLogic BT-950 Initialized Successfully *** scsi0 : BusLogic BT-950 Vendor: SONY Model: SDX-300C Rev: 0404 Type: Sequential-Access ANSI SCSI revision: 02 scsi0: Target 0: Queue Depth 3, Wide Synchronous at 20.0 MB/sec, offset 15 scsi1 : SCSI host adapter emulation for IDE ATAPI devices st: Version 20040102, bufsize 32768, max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0 usb.c: registered new driver usbdevfs usb.c: registered new driver hub ehci_hcd 00:10.3: VIA Technologies, Inc. USB 2.0 ehci_hcd 00:10.3: irq 3, pci mem cf81d000 usb.c: new USB bus registered, assigned bus number 1 ehci_hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29/2.4 hub.c: USB hub found hub.c: 6 ports detected host/uhci.c: USB Universal Host Controller Interface driver v1.1 host/uhci.c: USB UHCI at I/O 0xdc00, IRQ 11 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xe000, IRQ 7 usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected host/uhci.c: USB UHCI at I/O 0xe400, IRQ 5 usb.c: new USB bus registered, assigned bus number 4 hub.c: USB hub found hub.c: 2 ports detected Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) IPv4 over IPv4 tunneling driver ip_conntrack version 2.1 (1919 buckets, 15352 max) - 288 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with journal data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 140k freed hub.c: new USB device 00:10.3-3, assigned address 2 hub.c: USB hub found hub.c: 4 ports detected hub.c: new USB device 00:10.3-3.3, assigned address 3 usb.c: USB device 3 (vend/prod 0x4a9/0x1056) is not claimed by any active driver. hub.c: new USB device 00:10.3-3.4, assigned address 4 usb.c: USB device 4 (vend/prod 0x4f9/0x16) is not claimed by any active driver. Adding Swap: 506036k swap-space (priority -1) EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,67), internal journal usb.c: registered new driver usblp printer.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04A9 pid 0x1056 printer.c: usblp1: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0016 printer.c: v0.13: USB Printer Device Class driver via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xec00, 00:40:63:c4:b6:ca, IRQ 11. eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. r8169 Gigabit Ethernet driver 1.2 loaded eth1: Identified chip type is 'RTL8169s/8110s'. eth1: RTL8169 at 0xcf882000, 00:08:54:23:fd:2b, IRQ 5 eth1: Auto-negotiation Enabled. eth1: 1000Mbps Full-duplex operation. ttyS0: LSR safety check engaged! ttyS0: LSR safety check engaged! ttyS1: LSR safety check engaged! ttyS1: LSR safety check engaged! kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with journal data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with journal data mode. eth0: Setting full-duplex based on MII #1 link partner capability of 45e1. ttyS0: LSR safety check engaged! ttyS1: LSR safety check engaged! blk: queue c03c7f20, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03c805c, I/O limit 4095Mb (mask 0xffffffff) Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:63:c4:b6:ca:00:e0:d0:00:b7:f2:08:00 SRC=222.88.173.5 DST=10.192.151.130 LEN=666 TOS=0x00 PREC=0x00 TTL=105 ID=34014 PROTO=UDP SPT=14668 DPT=1026 LEN=646 --tThc/1wpZn/ma/RB-- From dcbw@redhat.com Tue Feb 1 13:56:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:46 -0800 (PST) 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 j11Lue4B000842 for ; Tue, 1 Feb 2005 13:56:40 -0800 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 j11LudKV028943; Tue, 1 Feb 2005 16:56:39 -0500 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 j11LudO29074; Tue, 1 Feb 2005 16:56:39 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11LucQO029438; Tue, 1 Feb 2005 16:56:38 -0500 Subject: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-L/8SggFIwD8pPmkcRnGZ" Date: Tue, 01 Feb 2005 16:56:38 -0500 Message-Id: <1107294998.17332.30.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-L/8SggFIwD8pPmkcRnGZ Content-Type: text/plain Content-Transfer-Encoding: 7bit Identify different firmware by enums, not strings, as we need to have some integral firmware identifier for choosing maximum rssi values for each different firmware type. Consolidate the information about firmware filenames and capabilities in the atmel module, not in atmel_cs or atmel_pci. Move common prototypes and firmware enum into new atmel.h file. The atmel_cs driver also thought that init_atmel_card() took "int irq" as the first parameter, this is now fixed to be "unsigned short irq". Signed-off-by: Dan Williams --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + 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 software 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 Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table [fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName- revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName- revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020- V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502% s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e% s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table [card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; --=-L/8SggFIwD8pPmkcRnGZ Content-Disposition: attachment; filename=1.atmel-fw-load-cleanup.patch Content-Type: text/x-patch; name=1.atmel-fw-load-cleanup.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + 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 software 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 Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table[fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName-revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName-revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020-V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502%s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e%s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table[card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; --=-L/8SggFIwD8pPmkcRnGZ-- From dcbw@redhat.com Tue Feb 1 13:56:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 13:56:54 -0800 (PST) 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 j11LunrI000916 for ; Tue, 1 Feb 2005 13:56:50 -0800 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 j11LunqY029065; Tue, 1 Feb 2005 16:56:49 -0500 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 j11LunO29141; Tue, 1 Feb 2005 16:56:49 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j11LunQO029445; Tue, 1 Feb 2005 16:56:49 -0500 Subject: [PATCH 2.6.11-rc2 2/2] wireless: WEXT quality cleanups + max rssi level fix for at76c502e From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: multipart/mixed; boundary="=-8QNotCicUS/LDXwth6Ty" Date: Tue, 01 Feb 2005 16:56:48 -0500 Message-Id: <1107295008.17332.32.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev --=-8QNotCicUS/LDXwth6Ty Content-Type: text/plain Content-Transfer-Encoding: 7bit Use correct maximum rssi level for at76c502e-type cards, and correct values in the qual.updated field to more closely match the current Wireless Extensions API. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv- >wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) --=-8QNotCicUS/LDXwth6Ty Content-Disposition: attachment; filename=2.atmel-502e-quality-fix.patch Content-Type: text/x-patch; name=2.atmel-502e-quality-fix.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv->wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) --=-8QNotCicUS/LDXwth6Ty-- From romieu@fr.zoreil.com Tue Feb 1 14:34:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 14:34:30 -0800 (PST) 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 j11MYMlc002905 for ; Tue, 1 Feb 2005 14:34:23 -0800 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 j11MVJOX007747; Tue, 1 Feb 2005 23:31:19 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j11MV9Oq007746; Tue, 1 Feb 2005 23:31:09 +0100 Date: Tue, 1 Feb 2005 23:31:09 +0100 From: Francois Romieu To: "Dale E. Martin" Cc: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050201223109.GA2957@electric-eye.fr.zoreil.com> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> <20050201215607.GA8530@gerbil.toadis.porkis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201215607.GA8530@gerbil.toadis.porkis> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1163 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 Dale E. Martin : [...] > although it looks like the card is only found on cold boots. Can you send (or put on a webpage) the same dmesg and lspci -vx when it happens ? > The irony of this, btw, is that linux/Documentation/Changes still > recommends gcc 2.95.3 - even in version 2.6.8, possibly in 2.6.10. (I > think I saw it in there but I don't have it handy.) You saw it there. No comment. > Also, when I first started looking at this, I tried to #define > RTL8169_DEBUG but was getting compile errors. Should I file a bug about > this ? I lost this one. Re-added to the queue. Don't bother with a PR for it. [...] > It looks like the poor 1Ghz C3 in this machine is going to be the > bottleneck for getting good transfer rates over gigabit ethernet ;-) It depends on the kind of transfer. A bigger MTU really helps. So does TSO and checksumming but it is really dependant on the kind of load. This is the content of the patch against 2.4.28. [...] > What is the intention of this patch? Is it to handle the 2.95.x issue or > something else ? See above. Can you: - send me discretly the .o built from the r8169 sources with 2.95.3 ? - pest me until you have a 2.95.3 compiled r8169 module which does not lock up any more ? -- Ueimor From tgraf@suug.ch Tue Feb 1 14:44:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 14:44:25 -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 j11MiIM3003709 for ; Tue, 1 Feb 2005 14:44:19 -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 DE0B882; Tue, 1 Feb 2005 23:43:54 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 7FD4C1C0EA; Tue, 1 Feb 2005 23:44:36 +0100 (CET) Date: Tue, 1 Feb 2005 23:44:36 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050201224436.GO31837@postel.suug.ch> References: <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107263612.1095.598.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1164 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 > Let the meta action do that. Just set the skb->tc_classid in my opinion; > recall we can change classid now .. True, I don't really care but it's already quite confusing. The priority of the packet is described in viarous field depeding on which qdisc/cls being used, we have skb->priority with sch_prio, tc_index for dsmark and cls_tcindex and now tc_classid directly. Some even use u32 to match on DSCP and set a nfmark. I can already feel the perfect confusion once we open up access for rt_classid, realm and other routing fields. I'm always aiming for easy to understand solutions, this doesn't mean it to be simple. Why is nfmark so heavly used? Because it's damn simple to undertand, you can set and read it and that's it. The only thing one has to care about is to make sure that is actually gets set before it being read and to make sure all userspace apps read it in the same base ;-> (This is basically one of the issue in usability, the lack of clearliness in what base number are read the displayed. Often they get displayed in hex without a 0x prefix but are read with strtol(...,0) resulting in a decimal reading if no prefix is specified) Long rant short statement, I'm pleading for a generic way to transfer such things between a classifier and a qdisc because it's simply easier to explain and use. ... eaction meta set tc_index ip_saddr_proto_hash ... qdisc sfq tcindex-hash where ip_saddr_proto_hash is not a variable but rather a special meta value calulated in the kernel. > You can let the user define that via tc but have a default; > eg: > tc dev eth0 add sfq ematch > tc dev eth0 set sfq pertub xxx > > match u32 ... > ematch sfq > ematch meta classid 1:2 > eaction meta set tcindex 101 > eaction meta set fwmark .. I think we're on the same road or at least going into the same direction. However I'm not sure whether it's a good to have ematches return some values besides true/false. I'd rather like to see an eaction store it in the skb and the sfq catching it up again. Of course we can have the userspace part be configured within the sfq. From davem@davemloft.net Tue Feb 1 15:10:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 15:10:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11NAYUq004892 for ; Tue, 1 Feb 2005 15:10:35 -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 1Cw74R-0005gg-00; Tue, 01 Feb 2005 15:04:31 -0800 Date: Tue, 1 Feb 2005 15:04:30 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: design for TSO performance fix Message-Id: <20050201150430.309978b6.davem@davemloft.net> In-Reply-To: <20050128015751.GT31837@postel.suug.ch> References: <20050127163146.33b01e95.davem@davemloft.net> <20050128015751.GT31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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: multipart/mixed; boundary="Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1165 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 This is a multi-part message in MIME format. --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 28 Jan 2005 02:57:51 +0100 Thomas Graf wrote: > > static inline int tcp_skb_data_all_paged(struct sk_buff *skb) > > { > > return (skb->len == skb->data_len); > > } > > You could also define this as (skb_headlen(skb) == 0) Good point, I'll do it that way. > I assume the case when reroute changes oif to a device no > longer capable of SG+CSUM stays the same and the skb remains > paged until dev_queue_xmit? That's correct. The only difference is that the TSO building path of send queue transmit will not be executed. I'm slowly piecing together an implementation. The most non- trivial aspect is the frame pushing logic. While building the queue from userspace, we wish to defer until either 1) the user will not supply more data or 2) there is enough in the send queue for an optimally sized TSO frame to be built. For the curious, there is attached my current state of implementation. It's very raw, but it starts to give the basic ideas. The first attachment are the design notes I've been jotting down casually while thinking about this, and the second is the rough beginnings of a patch. The patch implements the tp->tso_goal calculations, and the TSO segmentizer, but nothing else. The missing pieces are: 1) the push-pending-frames logic, it requires the most thought 1.5) the code in tcp_write_xmit() that tries to call the TSO segmenter with groups of SKBs to send 2) killing of tp->mss_cache_std, use tp->mss_cache for everything 3) kill all the code disabling TSO during packet drops 4) kill all the pcount stuff I'll continue trying to make more progress with this thing. --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: text/plain; name="tcp_tso.txt" Content-Disposition: attachment; filename="tcp_tso.txt" Content-Transfer-Encoding: 7bit Maintain some "TSO potential" state during segmentation at sendmsg()/sendpage() time. Use this at push-pending-frames time to defer tcp_write_xmit() calls and control it's behavior. Add tcp_flush_queue() which doesn't try to optimize TSO, it is invoked when getting packets out is more important than producing larger TSO chunks. These two cases are: 1) At end of sendmsg()/sendpage() call without MSG_MORE, indicating that we have no way to know for sure if the user will queue up more TCP data to send. 2) When sleeping within sendmsg()/sendpage() waiting for memory. Pushing out packets and receiving the ACKs may very well be the event that will free up send queue space for us. (Must consider interactions with Nagle and Minshall rules) Consider tcp_opt state which keeps a "TSO goal", it must be in sync with tcp_opt MSS state. Initially define "TSO goal" using tcp_tso_win_divisor and the current congestion window. Formally this is: max(1U, CWND / TCP_TSO_WIN_DIVISOR) We could either maintain this lazily, costing us a divide each time it is recalculated. Or, we can update it incrementally each time snd_cwnd is updated. To save some state testing during output decisions, define "TSO goal" as one for non-TSO flows. Possible send test logic: if (no new data possibly coming from user) send_now(); if (sending due to ACK queue advancement) send_now(); send_tso_goal_sized_chunks(); --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9 Content-Type: application/octet-stream; name="diff" Content-Disposition: attachment; filename="diff" Content-Transfer-Encoding: base64 PT09PT0gaW5jbHVkZS9saW51eC90Y3AuaCAxLjM0IHZzIGVkaXRlZCA9PT09PQotLS0gMS4zNC9p bmNsdWRlL2xpbnV4L3RjcC5oCTIwMDUtMDEtMTcgMTQ6MDk6MzMgLTA4OjAwCisrKyBlZGl0ZWQv aW5jbHVkZS9saW51eC90Y3AuaAkyMDA1LTAxLTMxIDE2OjAzOjMyIC0wODowMApAQCAtMjYyLDYg KzI2Miw3IEBACiAJX191MzIJcG10dV9jb29raWU7CS8qIExhc3QgcG10dSBzZWVuIGJ5IHNvY2tl dAkJKi8KIAlfX3UzMgltc3NfY2FjaGU7CS8qIENhY2hlZCBlZmZlY3RpdmUgbXNzLCBub3QgaW5j bHVkaW5nIFNBQ0tTICovCiAJX191MTYJbXNzX2NhY2hlX3N0ZDsJLyogTGlrZSBtc3NfY2FjaGUs IGJ1dCB3aXRob3V0IFRTTyAqLworCV9fdTE2CXRzb19nb2FsOwkvKiBUU08gcGFja2V0IGNvdW50 IGdvYWwsIDEgdy9ub24tVFNPIHBhdGhzICovCiAJX191MTYJbXNzX2NsYW1wOwkvKiBNYXhpbWFs IG1zcywgbmVnb3RpYXRlZCBhdCBjb25uZWN0aW9uIHNldHVwICovCiAJX191MTYJZXh0X2hlYWRl cl9sZW47CS8qIE5ldHdvcmsgcHJvdG9jb2wgb3ZlcmhlYWQgKElQL0lQdjYgb3B0aW9ucykgKi8K IAlfX3UxNglleHQyX2hlYWRlcl9sZW47LyogT3B0aW9ucyBkZXBlbmRpbmcgb24gcm91dGUgKi8K PT09PT0gbmV0L2lwdjQvdGNwX291dHB1dC5jIDEuNzcgdnMgZWRpdGVkID09PT09Ci0tLSAxLjc3 L25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA1LTAxLTE4IDEyOjIzOjM2IC0wODowMAorKysgZWRp dGVkL25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA1LTAyLTAxIDE0OjMyOjQ2IC0wODowMApAQCAt NzA3LDE1ICs3MDcsMTAzIEBACiAJCWlmIChmYWN0b3IgPiBsaW1pdCkKIAkJCWZhY3RvciA9IGxp bWl0OwogCi0JCXRwLT5tc3NfY2FjaGUgPSBtc3Nfbm93ICogZmFjdG9yOworCQkvKiBJZiB0aGlz IGV2ZXIgdHJpZ2dlcnMsIGNoYW5nZSB0cC0+dHNvX2dvYWwgdG8KKwkJICogYSBsYXJnZXIgdHlw ZSBhbmQgdXBkYXRlIHRoaXMgYnVnIGNoZWNrLgorCQkgKi8KKwkJQlVHX09OKGZhY3RvciA+IDY1 NTM1KTsKIAotCQltc3Nfbm93ID0gdHAtPm1zc19jYWNoZTsKLQl9CisJCXRwLT50c29fZ29hbCA9 IGZhY3RvcjsKKwl9IGVsc2UKKwkJdHAtPnRzb19nb2FsID0gMTsKIAogCWlmICh0cC0+ZWZmX3Nh Y2tzKQogCQltc3Nfbm93IC09IChUQ1BPTEVOX1NBQ0tfQkFTRV9BTElHTkVEICsKIAkJCSAgICAo dHAtPmVmZl9zYWNrcyAqIFRDUE9MRU5fU0FDS19QRVJCTE9DSykpOwogCXJldHVybiBtc3Nfbm93 OworfQorCitzdGF0aWMgaW5saW5lIGludCB0Y3Bfc2tiX2RhdGFfYWxsX3BhZ2VkKHN0cnVjdCBz a19idWZmICpza2IpCit7CisJcmV0dXJuIHNrYl9oZWFkbGVuKHNrYikgPT0gMDsKK30KKworLyog SWYgcG9zc2libGUsIGFwcGVuZCBwYWdlZCBkYXRhIG9mIFNSQ19TS0Igb250byB0aGUKKyAqIHRh aWwgb2YgRFNUX1NLQi4KKyAqLworc3RhdGljIGludCBza2JfYXBwZW5kX3BhZ2VzKHN0cnVjdCBz a19idWZmICpkc3Rfc2tiLCBzdHJ1Y3Qgc2tfYnVmZiAqc3JjX3NrYikKK3sKKwlpbnQgaTsKKwor CWlmICghdGNwX3NrYl9kYXRhX2FsbF9wYWdlZChzcmNfc2tiKSkKKwkJcmV0dXJuIC1FSU5WQUw7 CisKKwlmb3IgKGkgPSAwOyBpIDwgc2tiX3NoaW5mbyhzcmNfc2tiKS0+bnJfZnJhZ3M7IGkrKykg eworCQlza2JfZnJhZ190ICpzcmNfZnJhZyA9ICZza2Jfc2hpbmZvKHNyY19za2IpLT5mcmFnc1tp XTsKKwkJc2tiX2ZyYWdfdCAqZHN0X2ZyYWc7CisJCWludCBkc3RfZnJhZ19pZHg7CisKKwkJZHN0 X2ZyYWdfaWR4ID0gc2tiX3NoaW5mbyhkc3Rfc2tiKS0+bnJfZnJhZ3M7CisKKwkJaWYgKHNrYl9j YW5fY29hbGVzY2UoZHN0X3NrYiwgZHN0X2ZyYWdfaWR4LAorCQkJCSAgICAgc3JjX2ZyYWctPnBh Z2UsIHNyY19mcmFnLT5wYWdlX29mZnNldCkpIHsKKwkJCWRzdF9mcmFnID0gJnNrYl9zaGluZm8o ZHN0X3NrYiktPmZyYWdzW2RzdF9mcmFnX2lkeC0xXTsKKwkJCWRzdF9mcmFnLT5zaXplICs9IHNy Y19mcmFnLT5zaXplOworCQl9IGVsc2UgeworCQkJaWYgKGRzdF9mcmFnX2lkeCA+PSBNQVhfU0tC X0ZSQUdTKQorCQkJCXJldHVybiAtRU1TR1NJWkU7CisKKwkJCWRzdF9mcmFnID0gJnNrYl9zaGlu Zm8oZHN0X3NrYiktPmZyYWdzW2RzdF9mcmFnX2lkeF07CisJCQlza2Jfc2hpbmZvKGRzdF9za2Ip LT5ucl9mcmFncyA9IGRzdF9mcmFnX2lkeCArIDE7CisKKwkJCWRzdF9mcmFnLT5wYWdlID0gc3Jj X2ZyYWctPnBhZ2U7CisJCQlnZXRfcGFnZShzcmNfZnJhZy0+cGFnZSk7CisKKwkJCWRzdF9mcmFn LT5wYWdlX29mZnNldCA9IHNyY19mcmFnLT5wYWdlX29mZnNldDsKKwkJCWRzdF9mcmFnLT5zaXpl ID0gc3JjX2ZyYWctPnNpemU7CisJCX0KKwkJZHN0X3NrYi0+ZGF0YV9sZW4gKz0gc3JjX2ZyYWct PnNpemU7CisJfQorCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBzdHJ1Y3Qgc2tfYnVmZiAqdGNw X3Rzb19idWlsZChzdHJ1Y3Qgc2tfYnVmZiAqaGVhZCwgaW50IG1zcywgaW50IG51bSkKK3sKKwlz dHJ1Y3Qgc2tfYnVmZiAqc2tiOworCXN0cnVjdCBzb2NrICpzazsKKwlpbnQgZXJyOworCisJc2sg PSBoZWFkLT5zazsKKwlza2IgPSBhbGxvY19za2Ioc2stPnNrX3Byb3QtPm1heF9oZWFkZXIsIEdG UF9BVE9NSUMpOworCWVyciA9IC1FTk9NRU07CisJaWYgKCFza2IpCisJCWdvdG8gZmFpbDsKKwor CWVyciA9IDA7CisJc2tiX3NoaW5mbyhza2IpLT50c29fc2l6ZSA9IG1zczsKKwlza2Jfc2hpbmZv KHNrYiktPnRzb19zZWdzID0gbnVtOworCXdoaWxlIChudW0tLSkgeworCQllcnIgPSBza2JfYXBw ZW5kX3BhZ2VzKHNrYiwgaGVhZCk7CisJCWlmIChlcnIpCisJCQlnb3RvIGZhaWw7CisKKwkJaGVh ZCA9IGhlYWQtPm5leHQ7CisJfQorCXJldHVybiBza2I7CisKK2ZhaWw6CisJaWYgKHNrYikgewor CQlpbnQgaTsKKworCQlmb3IgKGkgPSAwOyBpIDwgc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFnczsg aSsrKSB7CisJCQlza2JfZnJhZ190ICpmcmFnID0gJnNrYl9zaGluZm8oc2tiKS0+ZnJhZ3NbaV07 CisKKwkJCXB1dF9wYWdlKGZyYWctPnBhZ2UpOworCQl9CisKKwkJa2ZyZWVfc2tiKHNrYik7CisJ fQorCXJldHVybiBOVUxMOwogfQogCiAvKiBUaGlzIHJvdXRpbmUgd3JpdGVzIHBhY2tldHMgdG8g dGhlIG5ldHdvcmsuICBJdCBhZHZhbmNlcyB0aGUK --Multipart=_Tue__1_Feb_2005_15_04_30_-0800_ObOyiQ/wBWaZ/9U9-- From oxymoron@waste.org Tue Feb 1 15:23:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 15:23:05 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11NN16q005580 for ; Tue, 1 Feb 2005 15:23:01 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j11NMkAl024732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 17:22:46 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j11NMjD0024728; Tue, 1 Feb 2005 17:22:45 -0600 Date: Tue, 1 Feb 2005 15:22:45 -0800 From: Matt Mackall To: Lorenzo Hern?ndez Garc?a-Hierro Cc: Valdis.Kletnieks@vt.edu, Adrian Bunk , Arjan van de Ven , Stephen Hemminger , "linux-kernel@vger.kernel.org" , Chris Wright , netdev@oss.sgi.com, Hank Leininger Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050201232245.GB17460@waste.org> References: <1106932637.3778.92.camel@localhost.localdomain> <20050128100229.5c0e4ea1@dxpl.pdx.osdl.net> <1106937110.3864.5.camel@localhost.localdomain> <20050128105217.1dc5ef42@dxpl.pdx.osdl.net> <1106944492.3864.30.camel@localhost.localdomain> <1106945266.7776.41.camel@laptopd505.fenrus.org> <200501290915.j0T9FkVY012948@turing-police.cc.vt.edu> <20050131165025.GN18316@stusta.de> <200501311942.j0VJgIYs016952@turing-police.cc.vt.edu> <1107201800.3754.125.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107201800.3754.125.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Mon, Jan 31, 2005 at 09:03:19PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote: > Arjan, I will give it a further look, is there anything you want to > comment about it before I start? > > I will re-code it to put the helper functions in random.c. Do it against -mm, please, there are something like 30 patches against random.c there already. And please cc: me on any changes there. -- Mathematics is the supreme nostalgia of our time. From jgarzik@pobox.com Tue Feb 1 17:34:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:34:28 -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 j121YNK3013297 for ; Tue, 1 Feb 2005 17:34:24 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9PR-00056C-8c; Wed, 02 Feb 2005 01:34:21 +0000 Message-ID: <42002E00.6000101@pobox.com> Date: Tue, 01 Feb 2005 20:33:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> In-Reply-To: <1107294126.17332.16.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Dan Williams wrote: > Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct > entries in sysfs. Seems like somebody meant to do this but it got lost. > atmel_cs.c was previously fixed to pass in the correct struct device * > via handle_to_dev() but the driver never actually used it. > > Signed-off-by: Dan Williams > > --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 > +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 > @@ -1579,6 +1579,8 @@ > dev->irq = irq; > dev->base_addr = port; > > + SET_NETDEV_DEV(dev, sys_dev); > + > if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { > printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); > goto err_out_free; > > Can you please resend all your patches with _just_ the patch inline, rather than both inline and attached? Your emails break my scripts, since the scripts try to apply both. Jeff From dcbw@redhat.com Tue Feb 1 17:41:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:41:08 -0800 (PST) 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 j121f43q013859 for ; Tue, 1 Feb 2005 17:41:04 -0800 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 j121f3VY020117; Tue, 1 Feb 2005 20:41:03 -0500 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 j121f3O25367; Tue, 1 Feb 2005 20:41:03 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j121f2QO012134; Tue, 1 Feb 2005 20:41:02 -0500 Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: Jeff Garzik Cc: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk In-Reply-To: <42002E00.6000101@pobox.com> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> Content-Type: text/plain Date: Tue, 01 Feb 2005 20:41:02 -0500 Message-Id: <1107308462.20243.1.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev And both evolution and pine screw up the patches inline and break the line at odd places... at least, that's what I see... you don't mind if you have to do a little surgery here and there? Dan On Tue, 2005-02-01 at 20:33 -0500, Jeff Garzik wrote: > Dan Williams wrote: > > Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct > > entries in sysfs. Seems like somebody meant to do this but it got lost. > > atmel_cs.c was previously fixed to pass in the correct struct device * > > via handle_to_dev() but the driver never actually used it. > > > > Signed-off-by: Dan Williams > > > > --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 > > +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 > > @@ -1579,6 +1579,8 @@ > > dev->irq = irq; > > dev->base_addr = port; > > > > + SET_NETDEV_DEV(dev, sys_dev); > > + > > if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { > > printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); > > goto err_out_free; > > > > > > Can you please resend all your patches with _just_ the patch inline, > rather than both inline and attached? > > Your emails break my scripts, since the scripts try to apply both. > > Jeff > > > From jgarzik@pobox.com Tue Feb 1 17:48:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:48:52 -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 j121mluT017006 for ; Tue, 1 Feb 2005 17:48:48 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9dN-0005oA-E6; Wed, 02 Feb 2005 01:48:45 +0000 Message-ID: <4200316F.7030401@pobox.com> Date: Tue, 01 Feb 2005 20:48:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: orinoco-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [0/8] orinoco driver updates References: <20050112052352.GA30426@localhost.localdomain> In-Reply-To: <20050112052352.GA30426@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David Gibson wrote: > Following are a bunch of patches which make a few more steps towards > the long overdue merge of the CVS orinoco driver into mainline. These > do make behavioural changes to the driver, but they should all be > trivial and largely cosmetic. OK, the changes look good, but I was waiting for the previous stuff you submitted to land in upstream. Could I convince you to rediff and resend against the latest 2.6.x snapshot? At the time you sent these, they conflicted with a previous cleanup you had sent, and that I had applied. Jeff From jgarzik@pobox.com Tue Feb 1 17:53:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 17:53:06 -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 j121r1Fg018855 for ; Tue, 1 Feb 2005 17:53:02 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1Cw9hS-000666-NA; Wed, 02 Feb 2005 01:52:58 +0000 Message-ID: <4200326D.2000801@pobox.com> Date: Tue, 01 Feb 2005 20:52:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> In-Reply-To: <1107308462.20243.1.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Dan Williams wrote: > And both evolution and pine screw up the patches inline and break the > line at odd places... at least, that's what I see... you don't mind if > you have to do a little surgery here and there? This is why we have request a common patch format -- because otherwise, everybody would request just-a-little-surgery-here-and-there. It's much easier in the long run to get people to find solutions (pine+vi or mutt or Mozilla Mail) that work, than to hope that a maintainer will know and fix up each submittor's mailer's eccentricities. Jeff From dave@thedillows.org Tue Feb 1 18:56:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 18:57:03 -0800 (PST) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j122uqcV019656 for ; Tue, 1 Feb 2005 18:56:57 -0800 Received: (qmail 16152 invoked by uid 0); 2 Feb 2005 02:56:51 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp7.knology.net with SMTP; 2 Feb 2005 02:56:51 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j122v0Mh005963; Tue, 1 Feb 2005 21:57:01 -0500 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j122v0js005962; Tue, 1 Feb 2005 21:57:00 -0500 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: David Dillow To: Dan Williams Cc: Jeff Garzik , Netdev , jgarzik@redhat.com, simon@thekelleys.org.uk In-Reply-To: <1107308462.20243.1.camel@dcbw.boston.redhat.com> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 01 Feb 2005 21:57:00 -0500 Message-Id: <1107313020.5888.1.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 20:41 -0500, Dan Williams wrote: > And both evolution and pine screw up the patches inline and break the > line at odd places... at least, that's what I see... you don't mind if > you have to do a little surgery here and there? Have you tried setting the format to "Preformat", and using Insert->Insert File... ? This is a really long line entered in "preformat" mode, and notice it doesn't wrap (if you look at it in text.) -- David Dillow From jgarzik@pobox.com Tue Feb 1 21:29:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:29:48 -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 j125TfjQ029387 for ; Tue, 1 Feb 2005 21:29:42 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwD59-0000Ud-M7; Wed, 02 Feb 2005 05:29:39 +0000 Message-ID: <42006535.4020309@pobox.com> Date: Wed, 02 Feb 2005 00:29:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sfeldma@pobox.com CC: netdev@oss.sgi.com, lunz@falooley.org Subject: Re: [PATCH 2.6] e100: remove reference to NAPI config option References: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> In-Reply-To: <1107220952.3366.4.camel@sfeldma-mobl.dsl-verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Feb 1 21:29:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:29:54 -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 j125TnFc029400 for ; Tue, 1 Feb 2005 21:29:50 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwD5F-0000Uj-US; Wed, 02 Feb 2005 05:29:46 +0000 Message-ID: <4200653B.5040302@pobox.com> Date: Wed, 02 Feb 2005 00:29:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Porter CC: akpm@osdl.org, netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: Re: [PATCH][NET] Add PPC440SP support to IBM EMAC driver References: <20050131171009.F25809@cox.net> In-Reply-To: <20050131171009.F25809@cox.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Feb 1 21:35:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Feb 2005 21:35:51 -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 j125Zb1b030403 for ; Tue, 1 Feb 2005 21:35:45 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwDAt-0000ol-AT; Wed, 02 Feb 2005 05:35:35 +0000 Message-ID: <42006699.3040508@pobox.com> Date: Wed, 02 Feb 2005 00:35:21 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com, corey@world.std.com Subject: Re: [PATCH 2/2] ray_cs: reduce stack usage (sockaddr) References: <41FAB900.5020502@osdl.org> In-Reply-To: <41FAB900.5020502@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From SRS0+18c37aa9fd0904e0caa1+528+infradead.org+hch@pentafluge.srs.infradead.org Wed Feb 2 01:38:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 01:38:16 -0800 (PST) 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 j129cB3Q006816 for ; Wed, 2 Feb 2005 01:38:12 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1CwGxb-0003Nb-RJ; Wed, 02 Feb 2005 09:38:07 +0000 Date: Wed, 2 Feb 2005 09:38:07 +0000 From: Christoph Hellwig To: Jeff Garzik Cc: Dan Williams , netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV Message-ID: <20050202093807.GA12946@infradead.org> References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> <4200326D.2000801@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4200326D.2000801@pobox.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 version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Tue, Feb 01, 2005 at 08:52:45PM -0500, Jeff Garzik wrote: > It's much easier in the long run to get people to find solutions > (pine+vi or mutt or Mozilla Mail) that work, than to hope that a > maintainer will know and fix up each submittor's mailer's eccentricities. Mozilla Mail is fucked up for sending patches aswell. From jgarzik@pobox.com Wed Feb 2 01:59:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 01:59:21 -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 j129xGYk007602 for ; Wed, 2 Feb 2005 01:59:16 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwHI2-0005H0-RV; Wed, 02 Feb 2005 09:59:14 +0000 Message-ID: <4200A465.9090100@pobox.com> Date: Wed, 02 Feb 2005 04:59:01 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Dan Williams , netdev@oss.sgi.com, jgarzik@redhat.com, simon@thekelleys.org.uk Subject: Re: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV References: <1107294126.17332.16.camel@dcbw.boston.redhat.com> <42002E00.6000101@pobox.com> <1107308462.20243.1.camel@dcbw.boston.redhat.com> <4200326D.2000801@pobox.com> <20050202093807.GA12946@infradead.org> In-Reply-To: <20050202093807.GA12946@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Christoph Hellwig wrote: > On Tue, Feb 01, 2005 at 08:52:45PM -0500, Jeff Garzik wrote: > >>It's much easier in the long run to get people to find solutions >>(pine+vi or mutt or Mozilla Mail) that work, than to hope that a >>maintainer will know and fix up each submittor's mailer's eccentricities. > > > Mozilla Mail is fucked up for sending patches aswell. Works for me. Jeff From adobriyan@mail.ru Wed Feb 2 02:35:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 02:35:09 -0800 (PST) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12AZ222009237 for ; Wed, 2 Feb 2005 02:35:03 -0800 Received: from [217.10.38.130] (port=41316 helo=mipter.zuzino.mipt.ru) by mx1.mail.ru with esmtp id 1CwHqb-000C3s-00; Wed, 02 Feb 2005 13:34:57 +0300 From: Alexey Dobriyan To: prism54-private@prism54.org Subject: [PATCH] prism54: use initialized current_time in debug_code Date: Wed, 2 Feb 2005 13:34:41 +0200 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200502021334.41648.adobriyan@mail.ru> X-Spam: Not detected X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@mail.ru Precedence: bulk X-list: netdev Otherwise gcc 4 complains: drivers/net/wireless/prism54/isl_38xx.c: In function ‘isl38xx_trigger_device’: drivers/net/wireless/prism54/isl_38xx.c:131: warning: ‘current_time.tv_sec’ is used uninitialized in this function drivers/net/wireless/prism54/isl_38xx.c:131: warning: ‘current_time.tv_usec’ is used uninitialized in this function Signed-off-by: Alexey Dobriyan --- linux-2.6.11-rc2-bk10/drivers/net/wireless/prism54/isl_38xx.c.orig 2005-02-02 13:20:57.000000000 +0200 +++ linux-2.6.11-rc2-bk10/drivers/net/wireless/prism54/isl_38xx.c 2005-02-02 13:24:25.000000000 +0200 @@ -112,7 +112,9 @@ isl38xx_handle_wakeup(isl38xx_control_bl void isl38xx_trigger_device(int asleep, void __iomem *device_base) { +#if VERBOSE > SHOW_ERROR_MESSAGES struct timeval current_time; +#endif u32 reg, counter = 0; #if VERBOSE > SHOW_ERROR_MESSAGES @@ -126,11 +128,10 @@ isl38xx_trigger_device(int asleep, void do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", current_time.tv_sec, current_time.tv_usec); -#endif - DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", current_time.tv_sec, current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); reg = readl(device_base + ISL38XX_INT_IDENT_REG); @@ -148,10 +149,13 @@ isl38xx_trigger_device(int asleep, void counter++; } +#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, readl(device_base + ISL38XX_CTRL_STAT_REG)); +#endif udelay(ISL38XX_WRITEIO_DELAY); #if VERBOSE > SHOW_ERROR_MESSAGES From tgraf@suug.ch Wed Feb 2 05:27:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 05:28:07 -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 j12DRvN1021710 for ; Wed, 2 Feb 2005 05:27:58 -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 5978182; Wed, 2 Feb 2005 14:27:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id A5C4C1C0EA; Wed, 2 Feb 2005 14:28:16 +0100 (CET) Date: Wed, 2 Feb 2005 14:28:16 +0100 From: Thomas Graf To: Andy Furniss Cc: jamal , netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202132816.GP31837@postel.suug.ch> References: <1107123123.8021.80.camel@jzny.localdomain> <20050131135810.GC31837@postel.suug.ch> <1107181169.7840.184.camel@jzny.localdomain> <20050131151532.GE31837@postel.suug.ch> <41FED514.7060702@dsl.pipex.com> <20050201133138.GM31837@postel.suug.ch> <41FF9A55.4080005@dsl.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FF9A55.4080005@dsl.pipex.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > >>WRT policers I never figured out where you would put the effects of > >>playing with the burst size parameter and it's effects with few/many > >>connections and any burstiness caused into an equasion like that. > > > > > >A burst buffer has impact on R on later packets, it can "smooth" R > >and X and thus results in more stable rates. Depending on the actual > >burst, it can avoid retransmits which stabilizes the rate as well. > > But it's not a real rate limiting buffer in the policer case is it? Abstractly speaking, burst specifies the maximum amount of time allowed for a single packet to sit in the burst buffer. Although the burst is configured as the size of the buffer it is transformed into a time delta before providing it to the kernel. Because the policer doesn't enqueue things the packet simply gets dropped if it would exceed that time. It's not _exactly_ like this but it gives you an idea what happens, net/sched/police.c isn't that big so one coffee should do it. > Nice - are you planning to add anything to tweak things for the wrong > end of the bottleneck problems? I hope so, once I figured out an acceptable compromise between a good result and simplicity. Currently it would be way to expensive and hard to use. From olh@suse.de Wed Feb 2 05:38:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 05:39:03 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12DcvqQ022468 for ; Wed, 2 Feb 2005 05:38:58 -0800 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 Cantor.suse.de (Postfix) with ESMTP id ED7A713F052B for ; Wed, 2 Feb 2005 14:38:51 +0100 (CET) Date: Wed, 2 Feb 2005 14:38:51 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: limited number if iptable rules on 64bit hosts Message-ID: <20050202133851.GA9680@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev What buffer or sysctrl value has to change to allow more than 3445 rules like this (on a 64bit host with 64bit iptables)? iptables -A FORWARD -j ACCEPT setsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524368) = -1 ENOMEM (Cannot allocate memory) I see this with 2.6.5 and 2.6.11. From hadi@cyberus.ca Wed Feb 2 06:05:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 06:05:29 -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 j12E5MNd023594 for ; Wed, 2 Feb 2005 06:05:22 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CwL8A-0002jG-0E for netdev@oss.sgi.com; Wed, 02 Feb 2005 09:05:18 -0500 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 1CwL81-0000TH-M9; Wed, 02 Feb 2005 09:05:09 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <41FF97E9.7040501@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> <41FF97E9.7040501@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107353106.1098.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Feb 2005 09:05:06 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 09:53, Andy Furniss wrote: > jamal wrote: > > I know for a while the Bart howto was mislabeling the meaning of > > policing - not sure about shaping. > > Shaping has a precise definition that involves a queue and a > > non-working-conserving scheduler in order to rate control. This doesnt > > matter where it happens (egress or ingress). Policing on the other hand > > is work conserving etc. > > Ok, but shaping to LARTC posters means being able to classify traffic > and set up sharing/priorotising of classes. > > This is the reason most need > to be able to queue - they want to use htb/hfsc for complicated setups Close - but you are missing the rate control requirement. You can do the above with prio qdisc for example but that does not equate to shaping. Understood about Lartc users definitions. However, note that they are influenced by what people tell them or what people write in docs. Help in making sure the redefinition doesnt propagate. Theres a very precise meaning to shaping and it is _exactly_ the way i described it above. Clue people who ask questions. > and until now were not aware that it was even possible to replicate this > in policers I am sure i have written about 50 emails on this topic over the last 5 years;-> look at the archives. I even joked about it here: http://www.cyberus.ca/~hadi/patches/action/README over 2 years ago. look at the text reading "it must be the summer heat again; weve had someone doing that every year around summer" Unfortunately people who are writting docs havent picked it up for whatever reasons. I am hoping we finaly get this documented somewhere. Can you help fix this? > and if it becomes feasable it will probably appear daunting > to do compared with HTB and all the existing docs/scripts. > >From a usability perspective i agree with you. Its still doable is all i can say ;-> (but you are correct in that it may not be for the weak hearts) As a reminder of some of the big discussions on shared and hierachical policing - look at the many many discussions I had with devik on this topic a few years back. It resulted in the birth of HTB (which is essentially a hierachy of the same token bucket meters used in policers; hierachical shared policers are doable - look at iproute2/examples/diffserv). HTB otoh has proven useful due to simplicty - so it stands on its own merit now. I think there may be peculiar occasions where you may need to have queues to shape traffic to a local app - but thats peculiar. > For me, I think queuing and dropping is better than just dropping, you > can affect tcp by delaying eg. 1 ack per packet rather than delayed acks > and clocking out the packets helps smooth burstiness, True - but i question the usefulness of localy terminating TCP packets being shaped. For packets being forwarded, the shaping happens on egress. > which hurts > latency if you are doing traffic control from the wrong end of the > bottleneck. > Not sure i followed the latency connection. > As long as I could use netfilter to mark/classify connections then I > think I can sort my setup, don't know about others. > > Great. yes, you can. > > Are pre/post routing sufficient as netfilter hooks for your case? > > Yes but depends on where in pre/postrouting. For me after/before nat, as > I say above though I could workaround if I classify connections with > netfilter. For others as long as they can filter on a mark/classify set > in forward, then I think it will be OK for them. > You can mark in netfilter or even in tc and use those marks in both places. > I am not sure what exactly can can't be done in your example: > > ># redirect all IP packets arriving in eth0 to dummy0 > ># use mark 1 --> puts them onto class 1:1 > >$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > >match u32 0 0 flowid 1:1 \ > > What I can do here depends where it hooks packets. > > >action ipt -j MARK --set-mark 1 \ > > I don't know what table I am using - may be OK as long as I can test for > a mark I made earlier in the egress dummy case or test connmark/state I > set for that connection in the ingress case. > That would be doable. Thanks for taking the time Andy. cheers, jamal From hadi@cyberus.ca Wed Feb 2 06:25:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 06:25: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 j12EP40r024788 for ; Wed, 2 Feb 2005 06:25:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CwLRE-0007c5-Ox for netdev@oss.sgi.com; Wed, 02 Feb 2005 09:25:00 -0500 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 1CwLR9-0003wg-PL; Wed, 02 Feb 2005 09:24:56 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <20050201224436.GO31837@postel.suug.ch> References: <20050131151532.GE31837@postel.suug.ch> <1107186044.1076.11.camel@jzny.localdomain> <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107354293.1105.85.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Feb 2005 09:24:53 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-02-01 at 17:44, Thomas Graf wrote: > > Let the meta action do that. Just set the skb->tc_classid in my opinion; > > recall we can change classid now .. > > True, I don't really care but it's already quite confusing. The priority > of the packet is described in viarous field depeding on which qdisc/cls > being used, we have skb->priority with sch_prio, tc_index for dsmark > and cls_tcindex and now tc_classid directly. Some even use u32 to > match on DSCP and set a nfmark. I can already feel the perfect confusion > once we open up access for rt_classid, realm and other routing fields. > I'm always aiming for easy to understand solutions, this doesn't mean > it to be simple. Why is nfmark so heavly used? Because it's damn simple > to undertand, you can set and read it and that's it. The only thing one > has to care about is to make sure that is actually gets set before it being > read and to make sure all userspace apps read it in the same base ;-> > (This is basically one of the issue in usability, the lack of clearliness > in what base number are read the displayed. Often they get displayed in > hex without a 0x prefix but are read with strtol(...,0) resulting in > a decimal reading if no prefix is specified) So let me put it this way: You cant avoid passing around metadata between the different blocks. Whether the metadata is set by the admin or by some other block along the packet path is way of life. All of the metadata defined and attached around skbs so far has a standalone semantical meaning whic unfortunately cant just be hidden from the user. Its the unfortunate consequence of giving someone a weapon )they may shoot their toe off). As an example: People have been setting flowid/classid for years via the classifiers to stamp session a flow belongs to. All we are doing with skb->tc_classid is giving more power to them. i.e before you get to the queue given certain computation/state you may decide to belong to a different session. sfq as a matter of setting the hash is computing what flow you belong to and thats why i suggested tc_classid (in this case not set by the admin, rather by a smart stateful classifier). > Long rant short statement, I'm pleading for a generic way to transfer > such things between a classifier and a qdisc because it's simply > easier to explain and use. > ... eaction meta set tc_index ip_saddr_proto_hash > ... qdisc sfq tcindex-hash > where ip_saddr_proto_hash is not a variable but rather a special meta > value calulated in the kernel. > Let me see if i understood correctly: Instead of giving static values (such as 0x10) you want to assign a variable(ip_saddr_proto_hash) which is computed at runtime to tcindex? Thats a parallel issue though but indeed useful . > > You can let the user define that via tc but have a default; > > eg: > > tc dev eth0 add sfq ematch > > tc dev eth0 set sfq pertub xxx > > > > match u32 ... > > ematch sfq > > ematch meta classid 1:2 > > eaction meta set tcindex 101 > > eaction meta set fwmark .. > > I think we're on the same road or at least going into the same direction. > However I'm not sure whether it's a good to have ematches return > some values besides true/false. I'd rather like to see an eaction store > it in the skb and the sfq catching it up again. Of course we can have the > userspace part be configured within the sfq. A classifier is allowed to select/set the class/flow/sessionID. The sfq hash result should at least set/map to the minor value of the classid cheers, jamal From dcbw@redhat.com Wed Feb 2 07:17:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:17:07 -0800 (PST) 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 j12FH20l028790 for ; Wed, 2 Feb 2005 07:17:03 -0800 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 j12FH1Rc016588; Wed, 2 Feb 2005 10:17:01 -0500 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 j12FGuO27035; Wed, 2 Feb 2005 10:16:56 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FGtQO027375; Wed, 2 Feb 2005 10:16:55 -0500 Subject: [PATCH 2.6.11-rc2] wireless: Make Atmel driver use SET_NETDEV_DEV From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:16:55 -0500 Message-Id: <1107357415.27197.4.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Make the Atmel wireless driver use SET_NETDEV_DEV to get the correct entries in sysfs. Seems like somebody meant to do this but it got lost. atmel_cs.c was previously fixed to pass in the correct struct device * via handle_to_dev() but the driver never actually used it. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-01-27 20:26:46.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 @@ -1579,6 +1579,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; From dcbw@redhat.com Wed Feb 2 07:17:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:17:58 -0800 (PST) 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 j12FHrR1029031 for ; Wed, 2 Feb 2005 07:17:53 -0800 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 j12FHrlr016803; Wed, 2 Feb 2005 10:17:53 -0500 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 j12FHqO27330; Wed, 2 Feb 2005 10:17:52 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FHqQO027443; Wed, 2 Feb 2005 10:17:52 -0500 Subject: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:17:52 -0500 Message-Id: <1107357472.27197.5.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev (resend) Identify different firmware by enums, not strings, as we need to have some integral firmware identifier for choosing maximum rssi values for each different firmware type. Consolidate the information about firmware filenames and capabilities in the atmel module, not in atmel_cs or atmel_pci. Move common prototypes and firmware enum into new atmel.h file. The atmel_cs driver also thought that init_atmel_card() took "int irq" as the first parameter, this is now fixed to be "unsigned short irq". Signed-off-by: Dan Williams --- /dev/null 2005-02-01 04:17:36.619366448 -0500 +++ b/drivers/net/wireless/atmel.h 2005-01-30 18:33:31.000000000 -0500 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + 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 software 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 Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif --- a/drivers/net/wireless/atmel.c 2005-02-01 16:15:55.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:22:26.000000000 -0500 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1482,7 +1500,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1525,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -3613,8 +3629,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3629,24 +3645,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table[fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; --- a/drivers/net/wireless/atmel_cs.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_cs.c 2005-01-30 14:05:08.000000000 -0500 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,28 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName-revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName-revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020-V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502%s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e%s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" } }; static void atmel_config(dev_link_t *link) @@ -520,7 +516,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table[card_index].firmware, &handle_to_dev(handle), card_present, link); --- a/drivers/net/wireless/atmel_pci.c 2005-02-01 16:15:24.000000000 -0500 +++ b/drivers/net/wireless/atmel_pci.c 2005-01-30 14:05:30.000000000 -0500 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; From dcbw@redhat.com Wed Feb 2 07:18:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:18:59 -0800 (PST) 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 j12FIsd8029613 for ; Wed, 2 Feb 2005 07:18:55 -0800 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 j12FIsuj017044; Wed, 2 Feb 2005 10:18:54 -0500 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 j12FIsO27711; Wed, 2 Feb 2005 10:18:54 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12FIrQO027508; Wed, 2 Feb 2005 10:18:53 -0500 Subject: [PATCH 2.6.11-rc2 2/2] wireless: WEXT quality cleanups + max rssi level fix for at76c502e From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 10:18:53 -0500 Message-Id: <1107357533.27197.7.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev (resend) Use correct maximum rssi level for at76c502e-type cards, and correct values in the qual.updated field to more closely match the current Wireless Extensions API. Signed-off-by: Dan Williams --- a/drivers/net/wireless/atmel.c 2005-02-01 16:25:38.000000000 -0500 +++ b/drivers/net/wireless/atmel.c 2005-02-01 16:25:53.000000000 -0500 @@ -1311,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -2236,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2265,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3043,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3065,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv->wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) From tgraf@suug.ch Wed Feb 2 07:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:40:30 -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 j12FeNGq030657 for ; Wed, 2 Feb 2005 07:40: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 095ED82; Wed, 2 Feb 2005 16:39:58 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 3C0041C0EA; Wed, 2 Feb 2005 16:40:41 +0100 (CET) Date: Wed, 2 Feb 2005 16:40:41 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202154041.GQ31837@postel.suug.ch> References: <20050131155929.GF31837@postel.suug.ch> <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> <1107354293.1105.85.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107354293.1105.85.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev First of all, sorry for the massive amount of typos in my last post. I could barely see anything due to the sun shining onto my display. > You cant avoid passing around metadata between the different blocks. > Whether the metadata is set by the admin or by some other block along > the packet path is way of life. Agreed. > All of the metadata defined and attached around skbs so far has a > standalone semantical meaning whic unfortunately cant just be hidden > from the user. Its the unfortunate consequence of giving someone a > weapon )they may shoot their toe off). Agreed, I'm just trying avoid further confusion. I think my country has one of highest if not the higest density of fully automatic assault weapons (because everyone liable to miltary service needs to have one at home), everyone owning one is forced to practice once a year and shooting is a common sport. OTOH, we have one of the lowest crime rates. Why's that? Because almost everyone is well educated in terms of weapon saftey, so I think this should be our way as well. So yes, we can definitely add more complexity but we should try to make it easy to understand and use. > sfq as a matter of setting the hash is computing what flow you belong to > and thats why i suggested tc_classid (in this case not set by the admin, > rather by a smart stateful classifier). If the value for tc_classid is directly set by the user then I agree. What I want to avoid is having hidden uses of parameters which can also be modified by the user. It results in a backward compatibility hell later on because we can't just add another use for it without possibily breaking scripts. > Let me see if i understood correctly: Instead of giving static values > (such as 0x10) you want to assign a variable(ip_saddr_proto_hash) which > is computed at runtime to tcindex? > Thats a parallel issue though but indeed useful . OK, so basically we weren't talking of exactly the same thing. In a user setting only context your argumentation makes sense. Let me follow on this thought a little further, what I basically want is a generic way to influence various qdiscs, be it a hashing index for sfq, a priority value for priority band based qdiscs, etc. tc_classid isn't a bad choice but it gets complex once we want a classful qdiscs to be able to use this input parameter. Summarizing what we currently have: tc_index: May contain a dscp value if dsmark is told to fetch the dscp field, the minor part of priority if dsmark is told to map priority values via handle values, or the minor part of the classid in a classifier result via ingress classification or a classifier attached to a dsmark. cls_tcindex, gred, and meta ematch use it as input value. nf_mark: cls_fw map to classids, meta ematch may read it, meta eaction may set it. tc_classid: Actions may set it to overwrite the result of a classifer, meta ematch may read it and I guess meta eaction may write to it. tc_verd: Set early in net stack, used to track location and tc relevant flags. tclassid: Set withing routing db, may be read via meta ematch. At the moment all of them can be described properly and it should be easy to understand if the relations are outlined properly. Assuming we allow setting tc_classid to overwrite the sfq internal hash we introduce a not so obvious double use because tc_classid is assumed to at least partly point to a class. We can redefine tc_classid as being a generic flow/session descriptor but then it should be moved out of being used to overwrite the classid within actions. Assuming I have a classifier which normally classifies into a child class but sometimes I want the traffic to go into a leaf sfq qdisc by using the action to overwrite the result. It will then be impossible to overwrite the sfq hash because I would no longer be able to overwrite the classifier result. It's probably possible to find some working solution by having the minor part being the sfq input or vice versa but it gets really nasty. Therefore I think we should make a difference between the current use of tc_classid to overwrite the classifier result and giving qdiscs some kind of input not directly related to their handle. Thoughts? From tgraf@suug.ch Wed Feb 2 07:55:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 07:55:27 -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 j12FtN50031417 for ; Wed, 2 Feb 2005 07:55:24 -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 791A382; Wed, 2 Feb 2005 16:55:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BE6FC1C0EA; Wed, 2 Feb 2005 16:55:43 +0100 (CET) Date: Wed, 2 Feb 2005 16:55:43 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto Subject: Re: dummy as IMQ replacement Message-ID: <20050202155543.GR31837@postel.suug.ch> References: <1107189625.1076.77.camel@jzny.localdomain> <20050131181553.GG31837@postel.suug.ch> <1107202715.1075.559.camel@jzny.localdomain> <20050131225328.GI31837@postel.suug.ch> <1107259361.1095.584.camel@jzny.localdomain> <20050201125147.GK31837@postel.suug.ch> <1107263612.1095.598.camel@jzny.localdomain> <20050201224436.GO31837@postel.suug.ch> <1107354293.1105.85.camel@jzny.localdomain> <20050202154041.GQ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202154041.GQ31837@postel.suug.ch> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev > tc_index: May contain a dscp value if dsmark is told to fetch the dscp > field, the minor part of priority if dsmark is told to map > priority values via handle values, or the minor part of the > classid in a classifier result via ingress classification or > a classifier attached to a dsmark. cls_tcindex, gred, and > meta ematch use it as input value. Assuming we use tc_index to provide the hash... - we don't need to worry about any definitions. tc_index already stands for some kind of index grouping together various packets. - we can directly use sfq to do fair queueing on dscp values and skb priority including specialized map with a underlying dsmark or cls_tcindex. From linux@horizon.com Wed Feb 2 09:17:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 09:17:17 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12HH8U2006003 for ; Wed, 2 Feb 2005 09:17:09 -0800 Received: (qmail 24524 invoked by uid 1000); 2 Feb 2005 17:17:02 -0000 Date: 2 Feb 2005 17:17:02 -0000 Message-ID: <20050202171702.24523.qmail@science.horizon.com> From: linux@horizon.com To: lorenzo@gnu.org, mingo@elte.hu Subject: Re: [PATCH] OpenBSD Networking-related randomization port Cc: arjan@infradead.org, bunk@stusta.de, chrisw@osdl.org, davem@redhat.com, hlein@progressive-comp.com, linux-kernel@vger.kernel.org, linux@horizon.com, netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu In-Reply-To: <20050131201141.GA4879@elte.hu> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: linux@horizon.com Precedence: bulk X-list: netdev *Sigh*. This thread is heading into the weeds. I have things I should be doing instead, but since nobody seems to actually be looking at what the patch *does*, I guess I'll have to dig into it a bit more... Yes, licensing issues need to be resolved before a patch can go in. Yes, code style standards needs to be kept up. And yes, SMP-locking issues need to be looked at. (And yes, ipv6 needs to be looked at, too!) But before getting sidetracked into the fine details, could folks please take a step back from the trees and look at the forest? Several people have asked (especially when the first patch came out), but I haven't seen any answers to the Big Questions: 1) Does this patch improve Linux's networking behaviour in any way? 2) Are the techniques in this patch a good way to achieve those improvements? Let's look at the various parts of the change: - Increases the default random pool size. Opinion: whatever. No real cost, except memory. Increases the maximum amount that can be read from /dev/random without blocking. Note that this is already adjustable at run time, so the question is why put it in the kernel config. If you want this, I'd suggest instead an option under CONFIG_EMBEDDED to shrink the pools and possibly get rid of the run-time changing code, then you could increase the default with less concern. - Changes the TCP ISN generation algorithm. I have't seen any good side to this. The current algorithm can be used for OS fingerprinting based on starting two TCP connections from different sources (ports or IPs) and noticing that the ISNs only differ in the low 24 bits, but is that a serious issue? If it is, there are better ways to deal with it that still preserve the valuable timer property. I point out that the entire reason for the cryptographically marginal half_md4_transform oprtation was that a full MD5 was a very noticeable performance bottleneck; the hash was only justified by the significant real-world attacks. obsd_get_random uses two calls to half_md4_transform. Which is the same cost as a full MD4 call. Frankly, they could just change half_md4_transform to return 64 bits instead of 32 and make do with one call. - Changes to the IP ID generation algorithm. All it actually does is change the way the initial inet->id is initialized for the inet_opt structure associated with the TCP socket. And if you look at ip_output.c:ip_push_pending_frames(), you'll see that, if DF is set (as is usual for a TCP connection), iph->id (the actual IP header ID) is set to htons(inet->id++). So it's still an incrementing sequence. This is in fact (see the comment in ip.h:ip_select_ident()) a workaround for a Microsoft VJ compression bug. The fix was added in 2.4.4 (via DaveM's zerocopy-beta-3 patch); before that, Linux 2.4 sent a constant zero as the IP ID of DF packets. See discussion at http://www.postel.org/pipermail/end2end-interest/2001-May/thread.html http://tcp-impl.lerc.nasa.gov/tcp-impl/list/archive/2378.html I'm not finding the diagnosis of the problem. I saw one report at http://oss.sgi.com/projects/netdev/archive/2001-01/msg00006.html and Dave Miller is pretty much on top of it when he posts http://marc.theaimsgroup.com/?l=linux-kernel&m=98275316400452&w=2 but I haven't found the actual debugging leading to the conclusion. This also led to some discussion of the OpenBSD IP ID algorithm that I haven't fully waded through at http://mail-index.netbsd.org/tech-net/2003/11/ If the packet is fragmentable (the only time the IP ID is really needed by the receiver), it's done by route.c:__ip_select_ident(). Wherein the system uses inet_getid to assign p->ip_id_count++ based on the route cache's struct inet_peer *p. (If the route cache is OOM, the system falls back on random IP ID assignment.) This latter technique nicely prevents the sort of stealth port scanning that was mentioned earlier in this thread, and prevents a person at address A from guessing the IP ID range I'm using to talk to address B. So note that the boast about "Randomized IP IDs" in the grsecurity description at http://www.gentoo.org/proj/en/hardened/grsecurity.xml is, as far as I can tell from a quick look at the code, simply false. As for the algorithm itself, it's described at http://www.usenix.org/events/usenix99/full_papers/deraadt/deraadt_html/node18.html but it's not obvious to me that it'd be hard to cryptanalyze given a stream of consecutive IDs. You need to recover: - The n value for each inter-ID gap, - The LCRNG state ru_a, ru_x, ru_b, - The 15-bit XOR masks ru_seed and ru_seed2, and - The discrete log generator ru_j (ru_g = 2^ru_j mod RU_N). Which is actually just a multiplier (mod RU_N-1 = 32748) on the input to the pmod() operation. So the IP ID generation can be summarized as: ru_x = (ru_a * ru_x + ru_b) % 31104; /* Repeated 1..4 times */ exp = ((ru_x ^ ru_seed2) + ru_j) % 32748; return ru_seed ^ pmod(2, exp, 32749); Now, if you can guess ru_seed, then the pmod() operation is simply a bijection that can be looked up in a table, and then it's just a matter of untangling a slightly elaborated LCRNG. - Changes the sun RPC XID allocation algorithm. Note that each connection is already initialized with a secure random number; the only change is whether the IDs used are simply incrementing from there or randomized each time one is needed. First of all and very importantly, obsd_get_random_long() does indeed generate a *random* number, which could be the *same* number as the last one. This could be VERY BAD for RPC XIDs, which have to be unique so the client can match the reply with the request. Note that Theo de Raadt knows better than do do that: http://www.usenix.org/events/usenix99/full_papers/deraadt/deraadt_html/node18.html Looking at the OpenBSD code at http://www.openbsd.org/cgi-bin/cvsweb/src/sys/nfs/ you can see that the NFS code in nfs_subs.c:nfsm_rpchead() generates a random starting xid and increments it by a random number 1..255 each time. The more general RPC code in krpc_subr.c:krpc_call() generates a fully random XID, constrained only to differ from the previous one. This is because the call is synchronous and does not permit more than one outstanding request at a time. Anyway, if you wanted to do this, you'd have to add some checking to ensure that a request with that ID isn't already on the rq_list. Also, there appear to be some retransmit issues that mitigate against recycling them too fast (which is why OpenBSD forbids adjacent duplicates), but I haven't studied that in detail. So in summary: - Random pool: Few security issues, but on the other hand, why bother? It's run-time tunable already. - TCP ISN: Proposed patch increases chance of TPC ISN reuse by breaking timer-based design specified in TCP RFC. It doesn't appear to have any more cryptographic security. - IP ID: Doesn't change the uses where it matters (DF flag clear). Doesn't change the fact that the IDs are still consecutive. What's the freaking point? And all that modular exponentiation that OpenBSD does is a pretty dubious security improvement. - RPC XID: Broken; don't use. And what's wrong with incrementing from a random start? If an attacker can see your requests, he can generate a fake reply no matter what algorithm you use, and if he can't, then the random start is all you need to limit his chances. The only thing a fully random sequence prevents against is that if an attacker can somehow tell when they've succeeded, an incrementing sequence lets them spoof furter replies easily. You could apply a first level of protection by incrementing them by a random odd number rather than 1, but even then, why bother? And, of ocurse, all of this has performance implications. Linux is justifiably proud of keeping down performance bloat by not wasting cycles on fast paths if it can possibly be helped. If we *do* find something to improve, we should look at the goals and design the fastest way possible to achieve that. It's not at all clear that the current code patch is the right implementation even if it *did* do something useful. Before worrying about the small stuff, could we take a good look at the Big Stuff? I like to try to be polite to people contributing patches. It's a lot of work and I don't want to dishearten someone just starting. I'd like to be polite and encouraging when rejecting patches. But everyone is so busy ignoring the elephant in the kitchen that I shall have to forego politeness and shout a little. It doesn't matter what the license is or whether it's against the Linus tree or -mm or how the functions are names. ********************************************** ************************************************ ***** ***** **** THIS PATCH DOESN'T FREAKING WORK!!!! **** ***** ***** ************************************************ ********************************************** Ignoring all the *implementation* brokenness, it breaks the network protocols, doesn't do what it claims to do, and what it tries to do isn't of any benefit over the existing code. It's not resting, it's not stunned, and it's not pining for the fjords. It just plain doesn't work. If there are any claimed benefits that you want, the first thing to do is throw it away, go back to square one, and come up with an algorithm that actually achieves that benefit. I keep hearing people boast about how the many eyes reviewing open source code improves the code quality and makes it harder to insert back doors into the system. If something this bad can get this many comments without anyone pointing out the emperor's clothing arrangements, the situation is pretty pitiful. There *are* things in OpenBSD, like randomized port assignment (as opposed to the linear scan in tcp_v4_get_port()) that would be worth emulating. Maybe worry about that first? From lorenzo@gnu.org Wed Feb 2 09:39:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 09:39:17 -0800 (PST) Received: from vds-320151.amen-pro.com (vds-320151.amen-pro.com [62.193.204.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Hd9IE010909 for ; Wed, 2 Feb 2005 09:39:09 -0800 Received: (qmail 9473 invoked from network); 2 Feb 2005 17:39:11 -0000 Received: from 67.red-80-25-56.pooles.rima-tde.net (HELO estila) (80.25.56.67) by vds-320151.amen-pro.com with RC4-MD5 encrypted SMTP; 2 Feb 2005 17:39:11 -0000 Subject: Re: [PATCH] OpenBSD Networking-related randomization port From: Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= To: linux@horizon.com Cc: mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, shemminger@osdl.org, Valdis.Kletnieks@vt.edu, spender@grsecurity.net In-Reply-To: <20050202171702.24523.qmail@science.horizon.com> References: <20050202171702.24523.qmail@science.horizon.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JOyczWpX46u3ytv/yRYL" Date: Wed, 02 Feb 2005 18:38:37 +0100 Message-Id: <1107365917.3754.155.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: lorenzo@gnu.org Precedence: bulk X-list: netdev --=-JOyczWpX46u3ytv/yRYL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El mi=E9, 02-02-2005 a las 17:17 +0000, linux@horizon.com escribi=F3: > There *are* things in OpenBSD, like randomized port assignment (as oppose= d > to the linear scan in tcp_v4_get_port()) that would be worth emulating. > Maybe worry about that first? >=20 Completely agreed with you, I was just trying to help with split up patches, but, as your analysis shows, it's more a weak implementation than a real security improvement. All I can say, just ignore the patch.I will work on other (worthy) issues that are in a bigger need. Maybe I would work something out on randomized source ports, as soon as I get time for it. Note also that Brad fixed obsd_rand.c code this week, I've added him to the CC list because there are things that may concern grSecurity he should be able to comment further on it and discuss whatever concerns *his* work (which is, BTW, a good thing (tm) to have in mind even if he didn't send split up patches for each feature, which I really don't know). I've just ported it out of grsecurity. Thanks for your meaningful comments, Cheers. --=20 Lorenzo Hern=E1ndez Garc=EDa-Hierro =20 [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] --=-JOyczWpX46u3ytv/yRYL Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQBCARAdDcEopW8rLewRAk/FAJwO9z7+G3+j67CGEDEDy/CJ5NnnKACY3VxJ 3SkgAMBcW3GKrhQGvVNXFg== =yQ6v -----END PGP SIGNATURE----- --=-JOyczWpX46u3ytv/yRYL-- From br33d@yahoo.com Wed Feb 2 10:00:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:00:07 -0800 (PST) Received: from web51506.mail.yahoo.com (web51506.mail.yahoo.com [206.190.38.198]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12I00Bl013885 for ; Wed, 2 Feb 2005 10:00:01 -0800 Received: (qmail 4707 invoked by uid 60001); 2 Feb 2005 17:59:55 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=J8DWZwdT6EXKwIXj39YF8/w3TvC/hlE5tpLn2XxwBGM7WAJwzdLProy5rbDduMiTAuJVOfdu+J6H/cdrb0uvJ5c2sEXCkYy8E4f9CWv4Xq/q/+JC+IXWu/Nnar0GT3L0S/D2RWRNZ6ff4D9KPN2yFdqIEUpR+zpbLzVi4bh042o= ; Message-ID: <20050202175955.4705.qmail@web51506.mail.yahoo.com> Received: from [198.4.83.52] by web51506.mail.yahoo.com via HTTP; Wed, 02 Feb 2005 09:59:54 PST Date: Wed, 2 Feb 2005 09:59:54 -0800 (PST) From: Benjamin Reed Subject: [PATCH] Dynamic airo.c patch for 2.6.10 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-765586789-1107367194=:3794" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: br33d@yahoo.com Precedence: bulk X-list: netdev --0-765586789-1107367194=:3794 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Here is a patch for the 2.6.10 aironet driver that will enable dynamic wep keying without resetting the MAC. It allows us to use xsupplicant with the driver. There are two lines of ugliness (the ones with the 0 &&) where I ignore the flag that says wether we are setting a permanent or a temporary key since xsupplicant doesn't use the IW_ENCODE_TEMP flag. --0-765586789-1107367194=:3794 Content-Type: text/x-diff; name="airo-dynkey.patch" Content-Description: airo-dynkey.patch Content-Disposition: inline; filename="airo-dynkey.patch" --- /usr/src/kernel-source-2.6.10/drivers/net/wireless/airo.c 2004-12-24 13:33:59.000000000 -0800 +++ airo.c 2005-02-01 09:23:36.000000000 -0800 @@ -1739,9 +1739,12 @@ rc = PC4500_writerid(ai, RID_WEP_TEMP, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) printk(KERN_ERR "airo: WEP_TEMP set %x\n", rc); if (perm) { + // We make these messages debug. They really should be error, + // but no one seems to use the TEMP flag and writing a PERM key + // with the MAC disable throws this error rc = PC4500_writerid(ai, RID_WEP_PERM, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) { - printk(KERN_ERR "airo: WEP_PERM set %x\n", rc); + printk(KERN_DEBUG "airo: WEP_PERM set %x\n", rc); } } return rc; @@ -3815,11 +3818,14 @@ pRsp->rsp1 = IN4500(ai, RESP1); pRsp->rsp2 = IN4500(ai, RESP2); if ((pRsp->status & 0xff00)!=0 && pCmd->cmd != CMD_SOFTRESET) { - printk (KERN_ERR "airo: cmd= %x\n", pCmd->cmd); - printk (KERN_ERR "airo: status= %x\n", pRsp->status); - printk (KERN_ERR "airo: Rsp0= %x\n", pRsp->rsp0); - printk (KERN_ERR "airo: Rsp1= %x\n", pRsp->rsp1); - printk (KERN_ERR "airo: Rsp2= %x\n", pRsp->rsp2); + /* These really should be error, but supplicants don't seem + * to use the TEMP flag when setting the keys, so this + * error is common */ + printk (KERN_DEBUG "airo: cmd= %x\n", pCmd->cmd); + printk (KERN_DEBUG "airo: status= %x\n", pRsp->status); + printk (KERN_DEBUG "airo: Rsp0= %x\n", pRsp->rsp0); + printk (KERN_DEBUG "airo: Rsp1= %x\n", pRsp->rsp1); + printk (KERN_DEBUG "airo: Rsp2= %x\n", pRsp->rsp2); } // clear stuck command busy if necessary @@ -4048,10 +4054,12 @@ Cmd cmd; Resp rsp; +#if 0 /* This check is to catch bugs, not needed for WepRid with temp key */ if (test_bit(FLAG_ENABLED, &ai->flags)) printk(KERN_ERR "%s: MAC should be disabled (rid=%04x)\n", __FUNCTION__, rid); +#endif memset(&cmd, 0, sizeof(cmd)); memset(&rsp, 0, sizeof(rsp)); @@ -5096,7 +5104,7 @@ wkr.len = sizeof(wkr); wkr.kindex = 0xffff; wkr.mac[0] = (char)index; - if (perm) printk(KERN_INFO "Setting transmit key to %d\n", index); + if (perm) printk(KERN_DEBUG "Setting transmit key to %d\n", index); if (perm) ai->defindex = (char)index; } else { // We are actually setting the key @@ -5105,12 +5113,16 @@ wkr.klen = keylen; memcpy( wkr.key, key, keylen ); memcpy( wkr.mac, macaddr, ETH_ALEN ); - printk(KERN_INFO "Setting key %d\n", index); } - disable_MAC(ai, lock); + //We are supposed to disable MACs before we write Rids, + //but the WEP Key rid seems to be the exception when temporary. + //unfortunately, no one uses the temporary flag, so until then + //an error is going to get thrown... (remove the 0 && when the + //flag comes into use. + if (0 && perm) disable_MAC(ai, lock); writeWepKeyRid(ai, &wkr, perm, lock); - enable_MAC(ai, &rsp, lock); + if (0 && perm) enable_MAC(ai, &rsp, lock); return 0; } @@ -5564,9 +5576,9 @@ } #ifdef CONFIG_PCI - printk( KERN_INFO "airo: Probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Probing for PCI adapters\n" ); pci_register_driver(&airo_driver); - printk( KERN_INFO "airo: Finished probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Finished probing for PCI adapters\n" ); #endif /* Always exit with success, as we are a library module @@ -5578,7 +5590,7 @@ static void __exit airo_cleanup_module( void ) { while( airo_devices ) { - printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name ); + printk( KERN_DEBUG "airo: Unregistering %s\n", airo_devices->dev->name ); stop_airo_card( airo_devices->dev, 1 ); } #ifdef CONFIG_PCI @@ -6168,6 +6180,7 @@ { struct airo_info *local = dev->priv; CapabilityRid cap_rid; /* Card capability info */ + u16 oldAuthType; /* Is WEP supported ? */ readCapabilityRid(local, &cap_rid, 1); @@ -6210,7 +6223,8 @@ /* Copy the key in the driver */ memcpy(key.key, extra, dwrq->length); /* Send the key to the card */ - set_wep_key(local, index, key.key, key.len, 1, 1); + set_wep_key(local, index, key.key, key.len, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } /* WE specify that if a valid key is set, encryption * should be enabled (user may turn it off later) @@ -6224,13 +6238,15 @@ /* Do we want to just set the transmit key index ? */ int index = (dwrq->flags & IW_ENCODE_INDEX) - 1; if ((index >= 0) && (index < ((cap_rid.softCap & 0x80)?4:1))) { - set_wep_key(local, index, NULL, 0, 1, 1); + set_wep_key(local, index, NULL, 0, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } else /* Don't complain if only change the mode */ if(!dwrq->flags & IW_ENCODE_MODE) { return -EINVAL; } } + oldAuthType = local->config.authType; /* Read the flags */ if(dwrq->flags & IW_ENCODE_DISABLED) local->config.authType = AUTH_OPEN; // disable encryption @@ -6239,7 +6255,7 @@ if(dwrq->flags & IW_ENCODE_OPEN) local->config.authType = AUTH_ENCRYPT; // Only Wep /* Commit the changes to flags if needed */ - if(dwrq->flags & IW_ENCODE_MODE) + if(oldAuthType != local->config.authType) set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } --0-765586789-1107367194=:3794-- From asimshankar@gmail.com Wed Feb 2 10:05:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:05:24 -0800 (PST) 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 j12I5GUR014557 for ; Wed, 2 Feb 2005 10:05:17 -0800 Received: by wproxy.gmail.com with SMTP id 71so134870wra for ; Wed, 02 Feb 2005 10:04:38 -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=U7R7Tt3Ax6KHJ9+m995Opl8A6PkQ582XT+Oduw0wR5kSa8eSUnjpkJYBZH9R4d5/B+hHejIhY2d6/F1KLIHyVKeQAe15b+0Ib7fgmuLegQTUnZjoAuknTbAEzAUoN3rOQf0m+tGgsOtsAc9yIxzZsFT1pa55xT52v/2uLL/IkZA= Received: by 10.54.24.77 with SMTP id 77mr82734wrx; Wed, 02 Feb 2005 10:04:38 -0800 (PST) Received: by 10.54.24.29 with HTTP; Wed, 2 Feb 2005 10:04:38 -0800 (PST) Message-ID: <7bca1cb5050202100475279073@mail.gmail.com> Date: Wed, 2 Feb 2005 12:04:38 -0600 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: netif_rx_schedule_prep() returning false? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: asimshankar@gmail.com Precedence: bulk X-list: netdev Hi, In NAPI related drivers, is it expected that netif_rx_schedule_prep() will return false? Does the fact that it returns false mean something is wrong? Specifically, in e1000 driver, when loaded with TxIntDelay=0, RxIntDelay=0, InterruptThrottleRate=0 (i.e., no hardware interrupt-coalescing), I've observed that the call to netif_rx_schedule_prep() in the interrupt handler (e1000_intr()) ocassionally returns false. Further investigation shows that this is because the __LINK_STATE_RX_SCHED bit of the struct net_device's state is already set (netif_running(dev) is always true). I also checked the interrupt cause register (ICR) in the interrupt handler and it seems the interrupts were caused by packet receives (ICR == E1000_ICR_RXT0, no other bits in the ICR register were set), which by my understanding should have not been possible. In other words, it seems the device is already scheduled for polling when a receive-related interrupt is received and handled. Is this behavior normal? Thanks, -- Asim From nacc@us.ibm.com Wed Feb 2 10:11:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:11:47 -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 j12IBbMd015191 for ; Wed, 2 Feb 2005 10:11:43 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12IBVm4382610 for ; Wed, 2 Feb 2005 13:11:31 -0500 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 j12IBV8D456120 for ; Wed, 2 Feb 2005 11:11:31 -0700 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 j12IBUiP017847 for ; Wed, 2 Feb 2005 11:11:31 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IBUu7017828; Wed, 2 Feb 2005 11:11:30 -0700 Received: by joust (Postfix, from userid 1000) id 6B24D4F9C9; Wed, 2 Feb 2005 10:11:29 -0800 (PST) Date: Wed, 2 Feb 2005 10:11:29 -0800 From: Nishanth Aravamudan To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 3/20] net/8139too: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202181129.GD2546@us.ibm.com> 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 version 0.81, clamav-milter version 0.81b 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: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, Please consider applying. One thing I would have preferred using here is use wait_event*(), but there is no condition. However, try_to_freeze(PF_FREEZE) could be used as one, if the return condition matters -- it can return 0 or 1, from what I understand. If the intent is to loop until the task is "frozen," then I can revise the patch to use wait_event_interruptible_timeout(). Description: Replace deprecated interruptible_sleep_on_timeout() function calls with direct wait-queue usage. I did not find the direct wake_up_interruptible() function call in this file for the wait-queue, but that may not be an issue. Patch is compile-tested. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/drivers/net/8139too.c 2005-01-24 09:34:08.000000000 -0800 +++ 2.6.11-rc2-kj/drivers/net/8139too.c 2005-01-27 11:22:19.000000000 -0800 @@ -108,6 +108,7 @@ #include #include #include +#include #include #include #include @@ -1612,6 +1613,7 @@ static inline void rtl8139_thread_iter ( static int rtl8139_thread (void *data) { + DEFINE_WAIT(wait); struct net_device *dev = data; struct rtl8139_private *tp = dev->priv; unsigned long timeout; @@ -1622,7 +1624,9 @@ static int rtl8139_thread (void *data) while (1) { timeout = next_tick; do { - timeout = interruptible_sleep_on_timeout (&tp->thr_wait, timeout); + prepare_to_wait(&tp->thr_wait, &wait, TASK_INTERRUPTIBLE); + timeout = schedule_timeout(timeout); + finish_wait(&tp->thr_wait, &wait); /* make swsusp happy with our thread */ try_to_freeze(PF_FREEZE); } while (!signal_pending (current) && (timeout > 0)); From nacc@us.ibm.com Wed Feb 2 10:19:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:19:08 -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 j12IJ2iE015750 for ; Wed, 2 Feb 2005 10:19:02 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12IIrm4397822 for ; Wed, 2 Feb 2005 13:18:53 -0500 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 j12IIr8D458056 for ; Wed, 2 Feb 2005 11:18:53 -0700 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 j12IIqRe004920 for ; Wed, 2 Feb 2005 11:18:53 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IIqo0004901; Wed, 2 Feb 2005 11:18:52 -0700 Received: by joust (Postfix, from userid 1000) id EFC534F9C9; Wed, 2 Feb 2005 10:18:50 -0800 (PST) Date: Wed, 2 Feb 2005 10:18:50 -0800 From: Nishanth Aravamudan To: Peter.Deschrijver@linux.cc.kuleuven.ac.be, mikep@linuxtr.net, sullivan@us.ibm.com Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 4/20] net/ibmtr: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202181850.GE2546@us.ibm.com> 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 version 0.81, clamav-milter version 0.81b 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: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, Please consider applying. This patch supersedes the recent patch "net/ibmtr: remove sleep_on*() usage" Description: Replace deprecated sleep_on*() function calls with direct wait-queue usage. Patch is compile-tested. The patch also fixes a potentially racy conditional in tok_open(), whereby msleep_interruptible() could receive a signal within the last jiffy, thus returning 0, but signal_pending(current) would be true. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/drivers/net/tokenring/ibmtr.c 2005-01-26 11:19:04.000000000 -0800 +++ 2.6.11-rc2-kj/drivers/net/tokenring/ibmtr.c 2005-02-02 10:16:56.000000000 -0800 @@ -109,6 +109,7 @@ in the event that chatty debug messages #include #include +#include #ifdef PCMCIA /* required for ibmtr_cs.c to build */ #undef MODULE /* yes, really */ @@ -847,6 +848,7 @@ static int __devinit trdev_init(struct n static int tok_init_card(struct net_device *dev) { + DEFINE_WAIT(wait); struct tok_info *ti; short PIOaddr; unsigned long i; @@ -867,13 +869,16 @@ static int tok_init_card(struct net_devi writeb(SRPR_ENABLE_PAGING,ti->mmio+ACA_OFFSET+ACA_RW+SRPR_EVEN); #endif writeb(INT_ENABLE, ti->mmio + ACA_OFFSET + ACA_SET + ISRP_EVEN); - i = sleep_on_timeout(&ti->wait_for_reset, 4 * HZ); + prepare_to_wait(&ti->wait_for_reset, &wait, TASK_UNINTERRUPTIBLE); + i = schedule_timeout(4*HZ); + finish_wait(&ti->wait_for_reset, &wait); return i? 0 : -EAGAIN; } /*****************************************************************************/ static int tok_open(struct net_device *dev) { + DEFINE_WAIT(wait); struct tok_info *ti = (struct tok_info *) dev->priv; int i; @@ -903,7 +908,9 @@ static int tok_open(struct net_device *d while (1){ tok_open_adapter((unsigned long) dev); - i= interruptible_sleep_on_timeout(&ti->wait_for_reset, 25 * HZ); + prepare_to_wait(&ti->wait_for_reset, &wait, TASK_INTERRUPTIBLE); + i = schedule_timeout(25 * HZ); + finish_wait(&ti->wait_for_reset, &wait); /* sig catch: estimate opening adapter takes more than .5 sec*/ if (i>(245*HZ)/10) break; /* fancier than if (i==25*HZ) */ if (i==0) break; @@ -912,7 +919,8 @@ static int tok_open(struct net_device *d DPRINTK("Adapter is up and running\n"); return 0; } - if(msleep_interruptible(jiffies_to_msecs(TR_RETRY_INTERVAL))) + msleep_interruptible(jiffies_to_msecs(TR_RETRY_INTERVAL)); + if (signal_pending(current)) break; /*prob. a signal, like the i>24*HZ case above */ } outb(0, dev->base_addr + ADAPTRESET);/* kill pending interrupts*/ From jt@hpl.hp.com Wed Feb 2 10:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:35:32 -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 j12IZSWh016591 for ; Wed, 2 Feb 2005 10:35:29 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 95827189A; Wed, 2 Feb 2005 10:35:26 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA13957; Wed, 2 Feb 2005 10:37:38 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwPLZ-0003cE-00; Wed, 02 Feb 2005 10:35:25 -0800 Date: Wed, 2 Feb 2005 10:35:25 -0800 To: Benjamin Reed , Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 Message-ID: <20050202183525.GA13881@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jt@hpl.hp.com Precedence: bulk X-list: netdev Benjamin Reed wrote : > > Here is a patch for the 2.6.10 aironet driver that > will enable dynamic wep keying without resetting the > MAC. It allows us to use xsupplicant with the driver. > > There are two lines of ugliness (the ones with the 0 > &&) where I ignore the flag that says wether we are > setting a permanent or a temporary key since > xsupplicant doesn't use the IW_ENCODE_TEMP flag. The IW_ENCODE_TEMP flag only make sense for the Aironet driver, as for all other hardware the WEP keys are volatile. So, don't expect this flag to be widespread. I would suggest you send a nice little patch to the maintainer of xsupplicant (and wpa_supplicant as well) explaining the situation. Enabling this flag should not affect other drivers, and might actually be a good idea in general. Have fun... Jean From nacc@us.ibm.com Wed Feb 2 10:58:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 10:58:44 -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 j12IwXYK018275 for ; Wed, 2 Feb 2005 10:58:40 -0800 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 j12IwRCZ660510 for ; Wed, 2 Feb 2005 13:58:27 -0500 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 j12IwPqv317714 for ; Wed, 2 Feb 2005 11:58:25 -0700 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 j12IwPRs022876 for ; Wed, 2 Feb 2005 11:58:25 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12IwO3N022829; Wed, 2 Feb 2005 11:58:24 -0700 Received: by joust (Postfix, from userid 1000) id 751634F9C9; Wed, 2 Feb 2005 10:58:23 -0800 (PST) Date: Wed, 2 Feb 2005 10:58:23 -0800 From: Nishanth Aravamudan To: robert.olsson@its.uu.se Cc: netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 5/20] net/pktgen: remove interruptible_sleep_on_timeout() usage Message-ID: <20050202185823.GG2546@us.ibm.com> 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 version 0.81, clamav-milter version 0.81b 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: nacc@us.ibm.com Precedence: bulk X-list: netdev Hello, The first and last replacements in the following patch were slightly confusing to me, as I have not used wait-queues that much myself. I did not exactly understand how a locally defined wait-queue could be slept on, especially since there are no wake_up() calls in pktgen.c. I was tempted to make the first sleep a msleep_interruptible(100), but decided to patch for the same code before I did that. Description: Replace deprecated interruptible_sleep_on_timeout() with direct wait-queue usage or wait_event_interruptible_timeout() as appropriate. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/net/core/pktgen.c 2005-01-24 09:34:21.000000000 -0800 +++ 2.6.11-rc2-kj/net/core/pktgen.c 2005-02-02 10:57:02.000000000 -0800 @@ -135,6 +135,7 @@ #include #include #include +#include #include #include #include @@ -2409,16 +2410,18 @@ static int running(struct pktgen_thread static int pktgen_wait_thread_run(struct pktgen_thread *t ) { - wait_queue_head_t queue; - - init_waitqueue_head(&queue); - + DEFINE_WAIT(wait); + wait_queue_head_t queue; + init_waitqueue_head(&queue); + if_lock(t); while(running(t)) { if_unlock(t); - - interruptible_sleep_on_timeout(&queue, HZ/10); + + prepare_to_wait(&queue, &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&queue, &wait); if (signal_pending(current)) goto signal; if_lock(t); @@ -2738,6 +2741,7 @@ __inline__ void pktgen_xmit(struct pktge static void pktgen_thread_worker(struct pktgen_thread *t) { + DEFINE_WAIT(wait); struct pktgen_dev *pkt_dev = NULL; int cpu = t->cpu; sigset_t tmpsig; @@ -2805,9 +2809,11 @@ static void pktgen_thread_worker(struct do_softirq(); tx_since_softirq = 0; } + } else { + prepare_to_wait(&(t->queue), &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&(t->queue), &wait); } - else - interruptible_sleep_on_timeout(&(t->queue), HZ/10); /* * Back from sleep, either due to the timeout or signal. @@ -3118,8 +3124,7 @@ static void __exit pg_cleanup(void) struct pktgen_thread *t = pktgen_threads; pktgen_threads->control |= (T_TERMINATE); - while( t == pktgen_threads) - interruptible_sleep_on_timeout(&queue, HZ); + wait_event_interruptible_timeout(queue, (t != pktgen_threads), HZ); } /* Un-register us from receiving netdevice events */ From sfeldma@pobox.com Wed Feb 2 11:14:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:15:04 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12JEwcD019200 for ; Wed, 2 Feb 2005 11:14:59 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 187E08F; Wed, 2 Feb 2005 14:14:58 -0500 (EST) Received: from [192.168.0.3] (wbar2.sea1-4-5-062-153.sea1.dsl-verizon.net [4.5.62.153]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 79ABD89; Wed, 2 Feb 2005 14:14:56 -0500 (EST) Subject: Re: netif_rx_schedule_prep() returning false? From: Scott Feldman Reply-To: sfeldma@pobox.com To: Asim Shankar Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb5050202100475279073@mail.gmail.com> References: <7bca1cb5050202100475279073@mail.gmail.com> Content-Type: text/plain Message-Id: <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 02 Feb 2005 11:16:32 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: sfeldma@pobox.com Precedence: bulk X-list: netdev On Wed, 2005-02-02 at 10:04, Asim Shankar wrote: > Specifically, in e1000 driver, when loaded with TxIntDelay=0, > RxIntDelay=0, InterruptThrottleRate=0 (i.e., no hardware > interrupt-coalescing), I've observed that the call to > netif_rx_schedule_prep() in the interrupt handler (e1000_intr()) > ocassionally returns false. Further investigation shows that this is > because the __LINK_STATE_RX_SCHED bit of the struct net_device's state > is already set (netif_running(dev) is always true). I also checked the > interrupt cause register (ICR) in the interrupt handler and it seems > the interrupts were caused by packet receives (ICR == E1000_ICR_RXT0, > no other bits in the ICR register were set), which by my understanding > should have not been possible. I'm running the same setup with delays turned off and I'm not seeing what you're seeing. What e1000 controller are you using? Send lspci -n. -scott From breed@almaden.ibm.com Wed Feb 2 11:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:16:08 -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 j12JG4cR019606 for ; Wed, 2 Feb 2005 11:16:04 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12JFxm4284284 for ; Wed, 2 Feb 2005 14:15:59 -0500 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 j12JFw8D436190 for ; Wed, 2 Feb 2005 12:15:58 -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 j12JFwMR028077 for ; Wed, 2 Feb 2005 12:15:58 -0700 Received: from mailhub.almaden.ibm.com (mailhub.almaden.ibm.com [9.1.45.57]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12JFvEH028047; Wed, 2 Feb 2005 12:15:58 -0700 Received: from [9.1.57.1] (dyn-9-1-57-1.almaden.ibm.com [9.1.57.1]) by mailhub.almaden.ibm.com (AIX5.2/8.11.6p2/8.11.0) with ESMTP id j12JFvN31904; Wed, 2 Feb 2005 11:15:57 -0800 Message-ID: <420126FB.3000007@almaden.ibm.com> Date: Wed, 02 Feb 2005 11:16:11 -0800 From: Benjamin Reed User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 References: <20050202183525.GA13881@bougret.hpl.hp.com> In-Reply-To: <20050202183525.GA13881@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: breed@almaden.ibm.com Precedence: bulk X-list: netdev I'm wondering if it would be possible to change IW_ENCODE_TEMP to IW_ENCODE_PERM. I realize that would not be backward compatible, but as you point out, the default assumption is that the keys are volatile. ben Jean Tourrilhes wrote: >Benjamin Reed wrote : > > >>Here is a patch for the 2.6.10 aironet driver that >>will enable dynamic wep keying without resetting the >>MAC. It allows us to use xsupplicant with the driver. >> >>There are two lines of ugliness (the ones with the 0 >>&&) where I ignore the flag that says wether we are >>setting a permanent or a temporary key since >>xsupplicant doesn't use the IW_ENCODE_TEMP flag. >> >> > > The IW_ENCODE_TEMP flag only make sense for the Aironet >driver, as for all other hardware the WEP keys are volatile. So, don't >expect this flag to be widespread. > I would suggest you send a nice little patch to the maintainer >of xsupplicant (and wpa_supplicant as well) explaining the >situation. Enabling this flag should not affect other drivers, and >might actually be a good idea in general. > Have fun... > > Jean > > From jt@hpl.hp.com Wed Feb 2 11:22:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:22:58 -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 j12JMsiI020369 for ; Wed, 2 Feb 2005 11:22:54 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 36DEC20C41; Wed, 2 Feb 2005 11:22:08 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id LAA15220; Wed, 2 Feb 2005 11:24:21 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwQ4m-0003zd-00; Wed, 02 Feb 2005 11:22:08 -0800 Date: Wed, 2 Feb 2005 11:22:08 -0800 To: Benjamin Reed Cc: Javier Achirica , netdev@oss.sgi.com Subject: Re: [PATCH] Dynamic airo.c patch for 2.6.10 Message-ID: <20050202192208.GA15344@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20050202183525.GA13881@bougret.hpl.hp.com> <420126FB.3000007@almaden.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420126FB.3000007@almaden.ibm.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jt@hpl.hp.com Precedence: bulk X-list: netdev On Wed, Feb 02, 2005 at 11:16:11AM -0800, Benjamin Reed wrote: > I'm wondering if it would be possible to change IW_ENCODE_TEMP to > IW_ENCODE_PERM. I realize that would not be backward compatible, but as > you point out, the default assumption is that the keys are volatile. > > ben Then you would have to change all other wireless tools (mine, NetworkManager, KWiFi). By default, those tools will send you a WEP key without any flag. My assumption is that if a user set a WEP key explicitely with those tools, you want it to be permanent. I think it's easier to fix the only two tools that make use of dynamic keys. Have fun... Jean From bunk@stusta.de Wed Feb 2 11:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 11:52:34 -0800 (PST) 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 j12JqRVR021710 for ; Wed, 2 Feb 2005 11:52:28 -0800 Received: (qmail 18980 invoked from network); 2 Feb 2005 19:52:21 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 Feb 2005 19:52:21 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 306A2BB62A; Wed, 2 Feb 2005 20:52:21 +0100 (CET) Date: Wed, 2 Feb 2005 20:52:21 +0100 From: Adrian Bunk To: Andrew Morton Cc: Margit Schubert-While , prism54-private@prism54.org, netdev@oss.sgi.com, jgarzik@pobox.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [2.6 patch] prism54: misc cleanups Message-ID: <20050202195221.GE3313@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 version 0.81, clamav-milter version 0.81b 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: bunk@stusta.de Precedence: bulk X-list: netdev This patch makes some functions in prism54 that are only required locally static. As a side effect it turned out that the mgt_unlatch_all function was completely unused, and it's therefore #if 0'ed. I also considered moving display_buffer as static inline into islpci_mgt.h, but I wasn't 100% sure and therefore left it. Signed-off-by: Adrian Bunk --- This patch was already sent on: - 20 Dec 2004 drivers/net/wireless/prism54/isl_ioctl.c | 32 +++++++++++------- drivers/net/wireless/prism54/isl_ioctl.h | 5 -- drivers/net/wireless/prism54/islpci_dev.c | 5 +- drivers/net/wireless/prism54/islpci_dev.h | 2 - drivers/net/wireless/prism54/islpci_mgt.c | 2 + drivers/net/wireless/prism54/oid_mgt.c | 38 +--------------------- drivers/net/wireless/prism54/oid_mgt.h | 4 -- 7 files changed, 28 insertions(+), 60 deletions(-) --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h.old 2004-10-30 06:52:18.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h 2004-10-30 07:02:58.000000000 +0200 @@ -41,15 +41,10 @@ void prism54_wpa_ie_init(islpci_private *priv); void prism54_wpa_ie_clean(islpci_private *priv); -void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, - u8 *wpa_ie, size_t wpa_ie_len); -size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); int prism54_set_mac_address(struct net_device *, void *); int prism54_ioctl(struct net_device *, struct ifreq *, int); -int prism54_set_wpa(struct net_device *, struct iw_request_info *, - __u32 *, char *); extern const struct iw_handler_def prism54_handler_def; --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c.old 2004-10-30 06:43:10.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c 2004-10-30 07:11:26.000000000 +0200 @@ -36,6 +36,14 @@ #include /* New driver API */ + +static void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, + u8 *wpa_ie, size_t wpa_ie_len); +static size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie); +static int prism54_set_wpa(struct net_device *, struct iw_request_info *, + __u32 *, char *); + + /** * prism54_mib_mode_helper - MIB change mode helper function * @mib: the &struct islpci_mib object to modify @@ -47,7 +55,7 @@ * Wireless API modes to Device firmware modes. It also checks for * correct valid Linux wireless modes. */ -int +static int prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode) { u32 config = INL_CONFIG_MANUALRUN; @@ -647,7 +655,7 @@ return current_ev; } -int +static int prism54_get_scan(struct net_device *ndev, struct iw_request_info *info, struct iw_point *dwrq, char *extra) { @@ -1582,7 +1590,7 @@ #define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5] #define MACSTR "%02x:%02x:%02x:%02x:%02x:%02x" -void +static void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid, u8 *wpa_ie, size_t wpa_ie_len) { @@ -1649,7 +1657,7 @@ up(&priv->wpa_sem); } -size_t +static size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie) { struct list_head *ptr; @@ -1736,7 +1744,7 @@ } } -int +static int prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid, char *data) { @@ -2314,7 +2322,7 @@ return ret; } -int +static int prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2358,7 +2366,7 @@ return 0; } -int +static int prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2367,7 +2375,7 @@ return 0; } -int +static int prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2380,7 +2388,7 @@ return 0; } -int +static int prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2389,7 +2397,7 @@ return 0; } -int +static int prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { @@ -2401,7 +2409,7 @@ return 0; } -int +static int prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *info, struct iw_point *data, char *extra) { @@ -2437,7 +2445,7 @@ return ret; } -int +static int prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *info, struct iw_point *data, char *extra) { --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.h.old 2004-10-30 06:58:23.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.h 2004-10-30 07:04:02.000000000 +0200 @@ -211,8 +211,6 @@ priv->device_base); } -struct net_device_stats *islpci_statistics(struct net_device *); - int islpci_free_memory(islpci_private *); struct net_device *islpci_setup(struct pci_dev *); #endif /* _ISLPCI_DEV_H */ --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.c.old 2004-10-30 06:46:08.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.c 2004-10-30 07:12:13.000000000 +0200 @@ -44,6 +44,7 @@ static int prism54_bring_down(islpci_private *); static int islpci_alloc_memory(islpci_private *); +static struct net_device_stats *islpci_statistics(struct net_device *); /* Temporary dummy MAC address to use until firmware is loaded. * The idea there is that some tools (such as nameif) may query @@ -52,7 +53,7 @@ * Of course, this is not the final/real MAC address. It doesn't * matter, as you are suppose to be able to change it anytime via * ndev->set_mac_address. Jean II */ -const unsigned char dummy_mac[6] = { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 }; +static const unsigned char dummy_mac[6] = { 0x00, 0x30, 0xB4, 0x00, 0x00, 0x00 }; static int isl_upload_firmware(islpci_private *priv) @@ -607,7 +608,7 @@ return rc; } -struct net_device_stats * +static struct net_device_stats * islpci_statistics(struct net_device *ndev) { islpci_private *priv = netdev_priv(ndev); --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_mgt.c.old 2004-10-30 06:46:45.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_mgt.c 2004-10-30 07:15:39.000000000 +0200 @@ -44,6 +44,7 @@ /****************************************************************************** Driver general functions ******************************************************************************/ +#if VERBOSE > SHOW_ERROR_MESSAGES void display_buffer(char *buffer, int length) { @@ -58,6 +59,7 @@ printk("\n"); } +#endif /***************************************************************************** Queue handling for management frames --- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/oid_mgt.h.old 2004-10-30 07:05:55.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/oid_mgt.h 2004-10-30 07:42:02.000000000 +0200 @@ -28,8 +28,7 @@ void mgt_clean(islpci_private *); -/* I don't know where to put these 3 */ -extern const int frequency_list_bg[]; +/* I don't know where to put these 2 */ extern const int frequency_list_a[]; int channel_of_freq(int); @@ -49,7 +48,6 @@ void mgt_get(islpci_private *, enum oid_num_t, void *); int mgt_commit(islpci_private *); -void mgt_unlatch_all(islpci_private *); int mgt_mlme_answer(islpci_private *); --- linux-2.6.10-rc3-mm1-full/drivers/net/wireless/prism54/oid_mgt.c.old 2004-12-20 01:03:44.000000000 +0100 +++ linux-2.6.10-rc3-mm1-full/drivers/net/wireless/prism54/oid_mgt.c 2004-12-20 01:05:31.000000000 +0100 @@ -24,8 +24,8 @@ #include "isl_ioctl.h" /* to convert between channel and freq */ -const int frequency_list_bg[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442, - 2447, 2452, 2457, 2462, 2467, 2472, 2484 +static const int frequency_list_bg[] = { 2412, 2417, 2422, 2427, 2432, + 2437, 2442, 2447, 2452, 2457, 2462, 2467, 2472, 2484 }; int @@ -730,6 +730,7 @@ * * The way to do this is to set ESSID. Note though that they may get * unlatch before though by setting another OID. */ +#if 0 void mgt_unlatch_all(islpci_private *priv) { @@ -756,6 +757,7 @@ if (rvalue) printk(KERN_DEBUG "%s: Unlatching OIDs failed\n", priv->ndev->name); } +#endif /* This will tell you if you are allowed to answer a mlme(ex) request .*/ From dcbw@redhat.com Wed Feb 2 12:17:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:17:10 -0800 (PST) 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 j12KH5c0023018 for ; Wed, 2 Feb 2005 12:17:06 -0800 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 j12KH55h012552; Wed, 2 Feb 2005 15:17:05 -0500 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 j12KH4O04510; Wed, 2 Feb 2005 15:17:04 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j12KH4QO020417; Wed, 2 Feb 2005 15:17:04 -0500 Subject: [PATCH 2.6.11-rc2 ] wireless: Hook up Atmel scan quality information From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@redhat.com, simon@thekelleys.org.uk Content-Type: text/plain Date: Wed, 02 Feb 2005 15:17:04 -0500 Message-Id: <1107375424.18721.1.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: dcbw@redhat.com Precedence: bulk X-list: netdev Actually return quality information for scanned access points. Signed-off-by: Dan Williams --- atmel.c.scan-qual 2005-02-02 14:53:40.000000000 -0500 +++ atmel.c 2005-02-02 15:10:46.000000000 -0500 @@ -639,6 +639,7 @@ static int reset_atmel_card(struct net_device *dev ); static void atmel_enter_state(struct atmel_private *priv, int new_state); int atmel_open (struct net_device *dev); +static u8 get_rssi_percentage (struct atmel_private *priv, u8 rssi); static inline u16 atmel_hi(struct atmel_private *priv, u16 offset) { @@ -2187,6 +2188,15 @@ iwe.u.mode = priv->BSSinfo[i].BSStype; current_ev = iwe_stream_add_event(current_ev, extra + IW_SCAN_MAX_DATA, &iwe, IW_EV_UINT_LEN); + iwe.cmd = IWEVQUAL; + iwe.u.qual.level = get_rssi_percentage (priv, priv->BSSinfo[i].RSSI); + iwe.u.qual.noise = 0; + iwe.u.qual.qual = iwe.u.qual.level; + iwe.u.qual.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_QUAL_UPDATED + | IW_QUAL_NOISE_INVALID; /* Don't know noise or quality */ + current_ev = iwe_stream_add_event(current_ev, extra + IW_SCAN_MAX_DATA, &iwe, IW_EV_QUAL_LEN); + iwe.cmd = SIOCGIWFREQ; iwe.u.freq.m = priv->BSSinfo[i].channel; iwe.u.freq.e = 0; @@ -3048,9 +3058,8 @@ } } -static void smooth_rssi(struct atmel_private *priv, u8 rssi) +static u8 get_rssi_percentage (struct atmel_private *priv, u8 rssi) { - u8 old = priv->wstats.qual.level; u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ switch (priv->firmware_type) { @@ -3061,7 +3070,14 @@ break; } - rssi = rssi * 100 / max_rssi; + return (rssi * 100 / max_rssi); +} + +static void smooth_rssi(struct atmel_private *priv, u8 rssi) +{ + u8 old = priv->wstats.qual.level; + + rssi = get_rssi_percentage (priv, rssi); if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else From simon@thekelleys.org.uk Wed Feb 2 12:39:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:39:24 -0800 (PST) Received: from thekelleys.org.uk (cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com [81.108.205.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12KdJW1027365 for ; Wed, 2 Feb 2005 12:39:20 -0800 Received: from desk.thekelleys.org.uk ([192.168.0.3] helo=thekelleys.org.uk) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1CwRHM-0005dM-00; Wed, 02 Feb 2005 20:39:12 +0000 Message-ID: <42013A72.1080209@thekelleys.org.uk> Date: Wed, 02 Feb 2005 20:39:14 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Dan Williams CC: netdev@oss.sgi.com, jgarzik@redhat.com Subject: Re: [PATCH 2.6.11-rc2 1/2] wireless: Clean up firmware loading in Atmel driver References: <1107357472.27197.5.camel@dcbw.boston.redhat.com> In-Reply-To: <1107357472.27197.5.camel@dcbw.boston.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: simon@thekelleys.org.uk Precedence: bulk X-list: netdev All Dans patches look good, in principle, to me. There's one more entry to go in the device table which has been floating around for a month or two, but doesn't seem to have made it in yet, in the new format: {0, 0," LG/LW2100N", ATMEL_FW_TYPE_502E, "LG LW2100N 11Mbps WLAN PCMCIA Card" } Dan, if you make another version of your patch maybe you could add that, otherwise I'll submit it as a follow-on once your changes have gone in. Cheers, Simon. From asimshankar@gmail.com Wed Feb 2 12:42:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 12:42:31 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12KgRcY027885 for ; Wed, 2 Feb 2005 12:42:28 -0800 Received: by wproxy.gmail.com with SMTP id 71so165632wra for ; Wed, 02 Feb 2005 12:42:22 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Y9J+1oLMbmvqR7hu9Bf+6qobqdmVANvgM4sjueXI9xtIIMQPduRgEU1cX+ez0GMVjtGBIkH9554uZbpmbl2u74Dg7kOfR4egonhLDOj9Iv8P7hXfu4WsW7f8s3uLkI5eyCoqOL/Atf5TJGW2G/mQkIxIi+Hx16rhnlwBtiA77W4= Received: by 10.54.24.77 with SMTP id 77mr184462wrx; Wed, 02 Feb 2005 12:42:14 -0800 (PST) Received: by 10.54.24.29 with HTTP; Wed, 2 Feb 2005 12:41:59 -0800 (PST) Message-ID: <7bca1cb5050202124149bd7f04@mail.gmail.com> Date: Wed, 2 Feb 2005 14:41:59 -0600 From: Asim Shankar Reply-To: Asim Shankar To: sfeldma@pobox.com Subject: Re: netif_rx_schedule_prep() returning false? Cc: netdev@oss.sgi.com In-Reply-To: <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7bca1cb5050202100475279073@mail.gmail.com> <1107371791.3366.126.camel@sfeldma-mobl.dsl-verizon.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev > I'm running the same setup with delays turned off and I'm not seeing > what you're seeing. What e1000 controller are you using? Send lspci > -n. lspci -n: 00:00.0 Class 0600: 8086:7190 (rev 03) 00:01.0 Class 0604: 8086:7191 (rev 03) 00:07.0 Class 0601: 8086:7110 (rev 02) 00:07.1 Class 0101: 8086:7111 (rev 01) 00:07.2 Class 0c03: 8086:7112 (rev 01) 00:07.3 Class 0680: 8086:7113 (rev 02) 00:10.0 Class 0200: 8086:1076 00:11.0 Class 0200: 10b7:9055 00:13.0 Class 0604: 1011:0024 (rev 03) 01:00.0 Class 0300: 10de:0028 (rev 11) This happens when a more "powerful" machine sends to a less powerful one and not the reverse. My setup is so: Machine A: Dual Xeon 2.8Ghz, 1GB RAM Dell PowerEdge 1800 Machine B: Dual P-III 500Mhz, 512MB RAM, old Dell Precision 410 I'm using netperf, so B is running a "netserver" and the netperf client application is started on A. "lspci" shown above is from "B". When reversed, B sending TO A, then machine A doesn't complain at all. Machine A also has the same card: Intel PRO/1000 MT Desktop Adapter - Class 0200: 8086:1076. Thanks, Regards, -- Asim P.S. Changes to e1000_intr() in order to check this: o Added "int rx_sched = test_bit(__LINK_STATE_RX_SCHED, &netdev->state); o Later, added an "else" to the "if (likely(netif_rx_schedule_prep(nedev))" block where I do a printk() From davem@davemloft.net Wed Feb 2 13:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 13:14:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12LE6BQ029106 for ; Wed, 2 Feb 2005 13:14:06 -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 1CwRiy-00027M-00; Wed, 02 Feb 2005 13:07:44 -0800 Date: Wed, 2 Feb 2005 13:07:43 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets when using netfilter hooks Message-Id: <20050202130743.065bc627.davem@davemloft.net> In-Reply-To: <20050131184827.GH31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 19:48:27 +0100 Thomas Graf wrote: > Jamal, close your eyes please. :-) > Fixes the ingress qdisc to pick up IPv6 packets when using the old > style netfilter hooks, i.e. when CONFIG_NET_CLS_ACT is not enabled. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Wed Feb 2 13:15:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 13:16:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12LFvu7029576 for ; Wed, 2 Feb 2005 13:15:57 -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 1CwRkm-00028H-00; Wed, 02 Feb 2005 13:09:36 -0800 Date: Wed, 2 Feb 2005 13:09:36 -0800 From: "David S. Miller" To: Robert Olsson Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: [PATCH] gc_min_interval in milleseconds via /proc (fwd) Message-Id: <20050202130936.4b3b8895.davem@davemloft.net> In-Reply-To: <16894.29281.293401.832567@robur.slu.se> References: <16888.56016.608929.340640@robur.slu.se> <20050130225627.4feecd2e.davem@davemloft.net> <16894.29281.293401.832567@robur.slu.se> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 19:01:05 +0100 Robert Olsson wrote: > David S. Miller writes: > > > We must pick a new sysctl number too, for sysctl() system call. > > If the only access possible were through /proc then yes your > > change would be valid, but due to sysctl() system call the > > .ctl_name defines that dimension of the sysctl namespace. > > Ok! > NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS was added last in list to avoid > renumbering. Feel free to change. Applied, thanks Robert. From romieu@fr.zoreil.com Wed Feb 2 14:14:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:14:36 -0800 (PST) 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 j12MERs6031672 for ; Wed, 2 Feb 2005 14:14:28 -0800 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 j12MDdRn026719; Wed, 2 Feb 2005 23:13:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j12MDYMc026718; Wed, 2 Feb 2005 23:13:34 +0100 Date: Wed, 2 Feb 2005 23:13:33 +0100 From: Francois Romieu To: "Dale E. Martin" Cc: netdev@oss.sgi.com Subject: Re: where is the proper place for r8169 bug reports? Message-ID: <20050202221333.GA24020@electric-eye.fr.zoreil.com> References: <20050131181508.GA15908@gerbil.toadis.porkis> <20050131214951.GA13217@electric-eye.fr.zoreil.com> <20050131215948.GA23289@gerbil.toadis.porkis> <20050131222342.GB13217@electric-eye.fr.zoreil.com> <20050201215607.GA8530@gerbil.toadis.porkis> <20050201223109.GA2957@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201223109.GA2957@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Re, - the 2.4.x backport has been rediffed against 2.4.29 (mostly harmless conflict in drivers/net/Config.in); - the driver compiles again when RTL8169_DEBUG is defined; - endianness fix in the Rx checksumming path. A test report with your 2.95.3 compiler would be welcome. If it breaks, the r8169.o file and an estimate of the transmitted/received packets count will help. If none is available, the number of interrupts processed can help too. Patch against 2.4.29 (md5: 444748e3c6c56382cb02adea4d16b5cf) http://www.fr.zoreil.com/~romieu/misc/20050202-2.4.29-r8169.c-test.patch Same thing a la patch-script: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.29/r8169/ Patch-script in a single file: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.29/r8169-blob.tar.bz2 -- Ueimor From olh@suse.de Wed Feb 2 14:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:25:27 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12MPMvE032433 for ; Wed, 2 Feb 2005 14:25:23 -0800 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 Cantor.suse.de (Postfix) with ESMTP id E23DD13F4B4B for ; Wed, 2 Feb 2005 23:25:16 +0100 (CET) Date: Wed, 2 Feb 2005 23:25:16 +0100 From: Olaf Hering To: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202222516.GA15440@suse.de> References: <20050202133851.GA9680@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050202133851.GA9680@suse.de> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: olh@suse.de Precedence: bulk X-list: netdev On Wed, Feb 02, Olaf Hering wrote: > > What buffer or sysctrl value has to change to allow more than 3445 rules > like this (on a 64bit host with 64bit iptables)? > > iptables -A FORWARD -j ACCEPT > > setsockopt(3, SOL_IP, 0x40 /* IP_??? */, > "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524368) = > -1 ENOMEM (Cannot allocate memory) it triggers the first -ENOMEM in net/ipv4/netfilter/ip_tables.c:do_replace sizeof(struct ipt_table_info)+SMP_ALIGN(tmp.size)*NR_CPUS == 67108992 bytes 128+524288*128==67108992 (sizeof(struct ipt_table_info) + (((tmp.size) + (1 << 7)-1) & ~((1 << 7)-1)) * 128) hmm, no braces missing. From tgraf@suug.ch Wed Feb 2 14:36:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:36:17 -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 j12MaBuG000632 for ; Wed, 2 Feb 2005 14:36:12 -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 C0AA682; Wed, 2 Feb 2005 23:35:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 059BF1C0EA; Wed, 2 Feb 2005 23:36:30 +0100 (CET) Date: Wed, 2 Feb 2005 23:36:29 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.4] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets Message-ID: <20050202223629.GS31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> <20050202130743.065bc627.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202130743.065bc627.davem@davemloft.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev Signed-off-by: Thomas Graf --- linux-2.4.29-bk8.orig/net/sched/sch_ingress.c 2005-02-02 22:32:51.000000000 +0100 +++ linux-2.4.29-bk8/net/sched/sch_ingress.c 2005-02-02 22:56:33.000000000 +0100 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -241,6 +242,15 @@ NF_IP_PRI_FILTER + 1 }; +static struct nf_hook_ops ing6_ops = +{ + { NULL, NULL}, + ing_hook, + PF_INET6, + NF_IP6_PRE_ROUTING, + NF_IP6_PRI_FILTER + 1 +}; + int ingress_init(struct Qdisc *sch,struct rtattr *opt) { struct ingress_qdisc_data *p = PRIV(sch); @@ -249,8 +259,13 @@ if (nf_register_hook(&ing_ops) < 0) { printk("ingress qdisc registration error \n"); goto error; - } + } nf_registered++; + if (nf_register_hook(&ing6_ops) < 0) { + printk("IPv6 ingress qdisc registration error, " \ + "disabling IPv6 support.\n"); + } else + nf_registered++; } DPRINTK("ingress_init(sch %p,[qdisc %p],opt %p)\n",sch,p,opt); @@ -374,8 +389,11 @@ void cleanup_module(void) { unregister_qdisc(&ingress_qdisc_ops); - if (nf_registered) + if (nf_registered) { nf_unregister_hook(&ing_ops); + if (nf_registered > 1) + nf_unregister_hook(&ing6_ops); + } } #endif MODULE_LICENSE("GPL"); From davem@davemloft.net Wed Feb 2 14:37:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:37:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mb1Tm000886 for ; Wed, 2 Feb 2005 14:37:01 -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 1CwT1D-0002Yt-00; Wed, 02 Feb 2005 14:30:39 -0800 Date: Wed, 2 Feb 2005 14:30:38 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4] PKT_SCHED: Fix ingress qdisc to pick up IPv6 packets Message-Id: <20050202143038.0e0e5dbc.davem@davemloft.net> In-Reply-To: <20050202223629.GS31837@postel.suug.ch> References: <20050131184827.GH31837@postel.suug.ch> <20050202130743.065bc627.davem@davemloft.net> <20050202223629.GS31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 2 Feb 2005 23:36:29 +0100 Thomas Graf wrote: > Signed-off-by: Thomas Graf Applied, thanks Thomas. From rugolsky@telemetry-investments.com Wed Feb 2 14:39:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:39:04 -0800 (PST) Received: from ti41.telemetry-investments.com (209-166-240-202.cust.walrus.com [209.166.240.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mcx0K001751 for ; Wed, 2 Feb 2005 14:39:00 -0800 Received: from ti64.telemetry-investments.com (ti64 [192.168.8.64]) by ti41.telemetry-investments.com (Postfix) with ESMTP id E75EB10101; Wed, 2 Feb 2005 17:38:53 -0500 (EST) Received: by ti64.telemetry-investments.com (Postfix, from userid 343) id E1A38FF2C; Wed, 2 Feb 2005 17:38:53 -0500 (EST) Date: Wed, 2 Feb 2005 17:38:53 -0500 From: "Bill Rugolsky Jr." To: Olaf Hering Cc: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202223853.GA29237@ti64.telemetry-investments.com> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202222516.GA15440@suse.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: brugolsky@telemetry-investments.com Precedence: bulk X-list: netdev On Wed, Feb 02, 2005 at 11:25:16PM +0100, Olaf Hering wrote: > it triggers the first -ENOMEM in > net/ipv4/netfilter/ip_tables.c:do_replace > > sizeof(struct ipt_table_info)+SMP_ALIGN(tmp.size)*NR_CPUS == 67108992 bytes > > 128+524288*128==67108992 > > (sizeof(struct ipt_table_info) + (((tmp.size) + (1 << 7)-1) & ~((1 << 7)-1)) * 128) > > hmm, no braces missing. I don't have time to look now [I'm running for the door], but that's possibly the vmalloc() limit of 64M (67108864) ? Regards, Bill Rugolsky From olh@suse.de Wed Feb 2 14:53:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 14:53:09 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12Mr3kI002813 for ; Wed, 2 Feb 2005 14:53:04 -0800 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 Cantor.suse.de (Postfix) with ESMTP id 4DF6C13F53A1; Wed, 2 Feb 2005 23:52:58 +0100 (CET) Date: Wed, 2 Feb 2005 23:52:58 +0100 From: Olaf Hering To: "Bill Rugolsky Jr." Cc: netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050202225258.GA15563@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050202223853.GA29237@ti64.telemetry-investments.com> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: olh@suse.de Precedence: bulk X-list: netdev On Wed, Feb 02, Bill Rugolsky Jr. wrote: > I don't have time to look now [I'm running for the door], > but that's possibly the vmalloc() limit of 64M (67108864) ? maybe. ->size is a userprovided value, havent looked closely at iptables source. It seems we have to live with this limitation. From davem@davemloft.net Wed Feb 2 16:15:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 16:15:20 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j130FDB5011276 for ; Wed, 2 Feb 2005 16:15:14 -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 1CwUYF-000304-00; Wed, 02 Feb 2005 16:08:51 -0800 Date: Wed, 2 Feb 2005 16:08:51 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.10] tg3: 5704 serdes fixes Message-Id: <20050202160851.27e532f6.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 27 Jan 2005 14:43:34 -0800 "Michael Chan" wrote: > Some 5704S and related fixes: > > - Fix capacitive coupling detection by reading the correct offset in sram > - Add support for different signal pre-emphasis on 5704S (used in some blade > servers) > - Improve 5704S link parallel detection. When autonegotiation fails, we only > detect link-up if we have PCS_SYNC and we are not receiving config code > words. This will prevent false link-up when only the rx cable is attached. Applied, thanks Michael. From davem@davemloft.net Wed Feb 2 16:27:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 16:27:39 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j130RV2c015319 for ; Wed, 2 Feb 2005 16:27:33 -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 1CwUjP-00031T-00; Wed, 02 Feb 2005 16:20:23 -0800 Date: Wed, 2 Feb 2005 16:20:23 -0800 From: "David S. Miller" To: Herbert Xu Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050202162023.075015d4.davem@davemloft.net> In-Reply-To: References: <20050131102920.GC4170@suse.de> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 31 Jan 2005 22:33:26 +1100 Herbert Xu wrote: > We're using atomic integers to signal that we're done with an object. > The object is usually represented by a piece of memory. > > The problem is that in most of the places where we do this (and that's > not just in the networking systems), there are no memory barriers between > the last reference to that object and the decrease on the atomic counter. I agree. > if (atomic_read(&skb->users) != 1) { > smp_mb__before_atomic_dec(); > if (!atomic_dec_and_test(&skb->users)) > return; > } > __kfree_skb(skb); This looks good. Olaf can you possibly ask the reproducer if this patch makes the ARP problem go away? # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/02 15:53:55-08:00 herbert@gondor.apana.org.au # [NET]: Add missing memory barrier to SKB release. # # Here, we are using atomic counters to signal that we are done # with an object. The object is usually represented by a piece # of memory. # # The problem is that in most of the places we do this, there are # no memory barriers between the last reference to that object # and the decrease on the atomic counter. # # Based upon a race spotted in arp_queue handling by Olaf Kirch. # # Signed-off-by: David S. Miller # # include/linux/skbuff.h # 2005/02/02 15:51:57-08:00 herbert@gondor.apana.org.au +6 -2 # [NET]: Add missing memory barrier to SKB release. # diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h --- a/include/linux/skbuff.h 2005-02-02 15:54:13 -08:00 +++ b/include/linux/skbuff.h 2005-02-02 15:54:13 -08:00 @@ -353,8 +353,12 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); + if (atomic_read(&skb->users) != 1) { + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + } + __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ From davem@davemloft.net Wed Feb 2 17:23:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 17:23:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j131NSRf017686 for ; Wed, 2 Feb 2005 17:23:28 -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 1CwVcD-0003Gg-00; Wed, 02 Feb 2005 17:17:01 -0800 Date: Wed, 2 Feb 2005 17:17:01 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 1/2] ipv4 routing: splitting of ip_route_[in|out]put_slow, 2.6.10-rc3 Message-Id: <20050202171701.18a81a6a.davem@davemloft.net> In-Reply-To: <41C6B3D4.6060207@einar-lueck.de> References: <41C6B3D4.6060207@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j131NSRf017686 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 Mon, 20 Dec 2004 12:13:24 +0100 Einar Lück wrote: > This patch splits up ip_route_[in|out]put_slow in inlined functions. > Basic idea: > * improve overall comprehensibility > * allow for an easier application of patch for improved multipath > support Patch applied to my 2.6.12 pending tree. Thanks a lot Einar. One minor comment is that there are some minor cases where excessing in_dev get/put can be eliminated. For example, in __mkroute_output() we really only need to do the in_dev_get(dev_out) once, yet we do it twice due to how the return path of this function always puts the reference even in the non-error case. From davem@davemloft.net Wed Feb 2 17:30:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 17:30:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j131U4im018252 for ; Wed, 2 Feb 2005 17:30:05 -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 1CwViX-0003JH-00; Wed, 02 Feb 2005 17:23:33 -0800 Date: Wed, 2 Feb 2005 17:23:33 -0800 From: "David S. Miller" To: Einar =?ISO-8859-1?Q?L=FCck?= Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Message-Id: <20050202172333.4d0ad5f0.davem@davemloft.net> In-Reply-To: <41C6B54F.2020604@einar-lueck.de> References: <41C6B54F.2020604@einar-lueck.de> X-Mailer: Sylpheed version 1.0.0 (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=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j131U4im018252 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 Mon, 20 Dec 2004 12:19:43 +0100 Einar Lück wrote: > This patch is an approach towards solving some problems with the > current multipath implementation: > * routing cache allows only one route to be cached for a certain > search key > * a mulitpath/load balancing decision is only made in case a > corresponding route is not yet cached > In the scenarios, that are relevant to us (high amount of outgoing > connection requests), this is a serious problem. I agree that per-connection attempt a new multipath decision should be made, but within a flow I disagree. This needs to be flow based. Can you describe more precisely "the scenerios, that are relevant to us"? If you are only interested in more precise multipathing when TCP connections on the local system are made, this we can implement via a flag to the ipv4 routing cache which forces a new multipath decision when TCP sockets have their identity established. We have a precise interface that is invoked at this time, called ip_route_connect(). So that is where we would pass in some flag to indicate that we desire the new multipath behavior. If you want this behavior on a router, you will need to mark the packets using something like firewall marking on the SKB, then this mark would be used at route cache lookup time to determine what kind of multipath decisions to make. There is no way we can enable the new behavior for every routing cache lookup. From webmaster@rapidforum.com Wed Feb 2 20:07:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 20:07:49 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1347iix022816 for ; Wed, 2 Feb 2005 20:07:45 -0800 Received: (qmail 2179 invoked by uid 1004); 3 Feb 2005 04:07:42 -0000 Received: from p3ee04c23.dip0.t-ipconnect.de (HELO ?62.224.76.35?) (62.224.76.35) by www.rapidforum.com with SMTP; 3 Feb 2005 04:07:42 -0000 Message-ID: <4201A382.1020208@rapidforum.com> Date: Thu, 03 Feb 2005 05:07:30 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: TCP-Protection is really a pain... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev Hi. Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell me a way how to disable it. Thank you. Best regards, Christian Schmid From shemminger@osdl.org Wed Feb 2 20:54:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 20:54: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 j134sg5Q028359 for ; Wed, 2 Feb 2005 20:54:43 -0800 Received: from localhost.localdomain (m810f36d0.tmodns.net [208.54.15.129]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j134sYuN024883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Feb 2005 20:54:36 -0800 Date: Wed, 2 Feb 2005 20:54:37 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050202205437.571a702b@localhost.localdomain> In-Reply-To: <4201A382.1020208@rapidforum.com> References: <4201A382.1020208@rapidforum.com> X-Mailer: Sylpheed-Claws 0.9.13 (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.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 05:07:30 +0100 Christian Schmid wrote: > Hi. > > Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell > me a way how to disable it. sysctl -w net.ipv4.tcp_wmem="4096 8192 16384" Your single stream will be slower, but the memory footprint will be smaller. From webmaster@rapidforum.com Wed Feb 2 21:22:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 21:22:29 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j135MMlp029340 for ; Wed, 2 Feb 2005 21:22:23 -0800 Received: (qmail 4401 invoked by uid 1004); 3 Feb 2005 05:22:22 -0000 Received: from p3ee04c23.dip0.t-ipconnect.de (HELO ?62.224.76.35?) (62.224.76.35) by www.rapidforum.com with SMTP; 3 Feb 2005 05:22:22 -0000 Message-ID: <4201B4EA.2030101@rapidforum.com> Date: Thu, 03 Feb 2005 06:21:46 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> In-Reply-To: <20050202205437.571a702b@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every second now... *sigh* well maybe you might just want to add a /proc file in order to configure this behaviour. btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue is completely full (checked with a grep in netstat). This looks like as if the receiver is just too slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty pipe but linux doesn't send. What could this be? Stephen Hemminger wrote: > On Thu, 03 Feb 2005 05:07:30 +0100 > Christian Schmid wrote: > > >>Hi. >> >>Your new dynamically adjusted socket-buffer in 2.6.10 is really a pain for big servers. PLEASE tell >>me a way how to disable it. > > > sysctl -w net.ipv4.tcp_wmem="4096 8192 16384" > > Your single stream will be slower, but the memory footprint will be smaller. > > From jgarzik@pobox.com Wed Feb 2 22:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Feb 2005 22:51:08 -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 j136p33C032313 for ; Wed, 2 Feb 2005 22:51:04 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwapR-0006BP-Qj; Thu, 03 Feb 2005 06:51:02 +0000 Message-ID: <4201C9C5.1060002@pobox.com> Date: Thu, 03 Feb 2005 01:50:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> In-Reply-To: <4201B4EA.2030101@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jgarzik@pobox.com Precedence: bulk X-list: netdev Christian Schmid wrote: > btw: Another problem I am experiencing is that downloads suddenly break > in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they stall > completely. But the interesting part is, that the send-queue is > completely full (checked with a grep in netstat). This looks like as if > the receiver is just too slow. But this is not the case. That makes it > rather funny. The receiver is waiting with an empty pipe but linux > doesn't send. What could this be? With recent kernels, I've noticed that my browser progress bar will download about 98% of a page, then stall for several seconds, then complete. Very strange. Haven't investigated it at all, though. Jeff From herbert@gondor.apana.org.au Thu Feb 3 03:13:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 03:13:35 -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 j13BDQGo012879 for ; Thu, 3 Feb 2005 03:13: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 1Cweuy-0008Jl-00; Thu, 03 Feb 2005 22:13:00 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CweuO-0000xa-00; Thu, 03 Feb 2005 22:12:24 +1100 Date: Thu, 3 Feb 2005 22:12:24 +1100 To: "David S. Miller" Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203111224.GA3267@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050202162023.075015d4.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20050202162023.075015d4.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 02, 2005 at 04:20:23PM -0800, David S. Miller wrote: > > > if (atomic_read(&skb->users) != 1) { > > smp_mb__before_atomic_dec(); > > if (!atomic_dec_and_test(&skb->users)) > > return; > > } > > __kfree_skb(skb); > > This looks good. Olaf can you possibly ask the reproducer if > this patch makes the ARP problem go away? Not so hasty Dave :) That was only meant to be an example of what we might do to insert a write barrier in kfree_skb(). It doesn't solve Olaf's problem because a write barrier is usually not sufficient by itself. In most cases you'll need a read barrier as well. So if we're going for a solution that only involves kfree_skb() then we'll need the following patch. I got rid of the atomic_read optimisation since it would've needed an additional smp_rmb() to be safe. I thought about preserving that optimisation through something like skb->cloned. However, it turns out that most skb's will be shared at least once so it doesn't buy us much. Signed-off-by: Herbert Xu What I hoped to do though was to bring your collective attention to the problem in general. kfree_skb() is certainly not the only place where we free an object after the counter hits zero. This paradigm is repeated throughout the kernel. I bet the same race can be found in a lot of those places. So we really need to sit down and audit them one by one or else come up with a magical solution apart from disabling SMP :) 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 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-03 21:57:26 +11:00 @@ -353,15 +353,21 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + smp_mb__after_atomic_dec(); + __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ static inline void kfree_skb_fast(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - kfree_skbmem(skb); + smp_mb__before_atomic_dec(); + if (!atomic_dec_and_test(&skb->users)) + return; + smp_mb__after_atomic_dec(); + kfree_skbmem(skb); } /** --fdj2RfSjLxBAspz7-- From okir@suse.de Thu Feb 3 03:19:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 03:19:56 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13BJnLW013506 for ; Thu, 3 Feb 2005 03:19:50 -0800 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 Cantor.suse.de (Postfix) with ESMTP id 0C48A13FA6DF; Thu, 3 Feb 2005 12:19:44 +0100 (CET) Date: Thu, 3 Feb 2005 12:19:39 +0100 From: Olaf Kirch To: Olaf Hering Cc: "Bill Rugolsky Jr." , netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203111939.GI31570@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202225258.GA15563@suse.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: okir@suse.de Precedence: bulk X-list: netdev On Wed, Feb 02, 2005 at 11:52:58PM +0100, Olaf Hering wrote: > > I don't have time to look now [I'm running for the door], > > but that's possibly the vmalloc() limit of 64M (67108864) ? > > maybe. > ->size is a userprovided value, havent looked closely at iptables > source. It seems we have to live with this limitation. The problem is two-fold. netfilter tries to allocate some data per-CPU and does vmalloc(sizeof(struct ipt_table_info) + SMP_ALIGN(tmp.size) * NR_CPUS); At 3445 rules, tmp.size is 524272 (why does it want that much memory? I would expect the only data that's per-CPU is the packet and byte counters). In some of our kernel configurations, NR_CPUS is 128 or even more, and we run into a vmalloc limit here. vmalloc wants to allocate an arrays of struct page pointers, and on a 64bit platform this means you're limited to 131072 / 8 = 16384 pages, or 67108864 bytes. In the example Olaf H posted, we fail at 128 + 524272 * 128 = 67108992 bytes, i.e. 16385 pages. So I guess it all boils down to why netfilter needs 150-odd bytes per rule and CPU. 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 cranium.2003@gmail.com Thu Feb 3 05:18:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 05:18:25 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DIKYY020288 for ; Thu, 3 Feb 2005 05:18:20 -0800 Received: by rproxy.gmail.com with SMTP id b11so189718rne for ; Thu, 03 Feb 2005 05:18:19 -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=D26WPYq1HfHPFVC6sKeCtv2ndcC5/3hW4Xr50EGfPn4QHNsTrn27tcSNlJtOkRML2r+gTarck0HzutUtQ691pqv/9yAFQyP6Strd4+9rkzmCHSJiBBGIn3s89dzvt4D6rc0cHVZG5meFqN3XbkUocdzmhm3HRDnjlp6fhVPtp2k= Received: by 10.38.71.60 with SMTP id t60mr71870rna; Thu, 03 Feb 2005 05:18:19 -0800 (PST) Received: by 10.38.81.57 with HTTP; Thu, 3 Feb 2005 05:18:19 -0800 (PST) Message-ID: <1d55641b05020305182d423c57@mail.gmail.com> Date: Thu, 3 Feb 2005 18:48:19 +0530 From: cranium 2003 Reply-To: cranium 2003 To: netdev@oss.sgi.com, kernelnewbies Subject: Which function at link layer sends packet? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: cranium.2003@gmail.com Precedence: bulk X-list: netdev Hello, In a LAN i have 2 pcs host1 with 10.0.2.10 and host2 with eth0:10.0.0.100 and eth1:192.168.1.1 Both are connected to switch. what i observe that when i ping from 10.0.2.10 to 192.168.1.1 then packet is sent through dev_queue_xmit_nit. In that function it goes upto ptype->func(skb2, skb->dev, ptype); and then i am not getting which functions get called but then i found call goes to ethernet driver to NIC card. Does that mean above statement calls hard_start_xmit? Then i reboot my linux RH9 with 2.4.24 kernel PC and again ping to 192.168.1.1 and found that packet transmission is not going through dev_queu_xmit_nit but from dev_queue_xmit to hard_start_xmit. regards, cranium. From cranium.2003@gmail.com Thu Feb 3 05:21:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 05:21:34 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DLUKZ020791 for ; Thu, 3 Feb 2005 05:21:31 -0800 Received: by rproxy.gmail.com with SMTP id b11so190121rne for ; Thu, 03 Feb 2005 05:21:30 -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=J2V4ai+DvBHX6Cle350DoAMudmZclGsOGkd7PVPG8CvcuxL3O+gJFVMo9+mjChjRxWGYbplo6ugLBf4luGNhaQpMy0JcpYnVYSgmPMDCSD5a/w4ovQ6qFkwb/xj8arY5/siL9cxGB3qpH16VHMJj7XhqNfzxJYj26S/KPM23S/M= Received: by 10.38.98.76 with SMTP id v76mr61186rnb; Thu, 03 Feb 2005 05:21:30 -0800 (PST) Received: by 10.38.81.57 with HTTP; Thu, 3 Feb 2005 05:21:30 -0800 (PST) Message-ID: <1d55641b050203052150cbbea3@mail.gmail.com> Date: Thu, 3 Feb 2005 18:51:30 +0530 From: cranium 2003 Reply-To: cranium 2003 To: netdev@oss.sgi.com, linux-net@vger.linux.org Subject: How much ARP requests need to single IP address? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: cranium.2003@gmail.com Precedence: bulk X-list: netdev Hello, In Linux kernel by adding debug statement i observe that if i ping to host 10.0.0.5 with 10 packets then first i know network stack require to resolve hosts IP to its Hardware ID by sending ARP on Ethernet LAN. But then what i get that if i again ping for another 10 packets to 10.0.0.5 then ARP routine is called. Why? Why linux kernel is not caching it. Infact its caching i check it in debug statements then why network stack require to resolve 10.0.0.5 host to send packets to it? Also i want to know once eth_header_cache called then all successive packet to that cache host goes directly from hh->hh_output(skb) to hard_start_xmit? regards, cranium From anton@ozlabs.org Thu Feb 3 06:30:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 06:30:05 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13EU1xa023484 for ; Thu, 3 Feb 2005 06:30:01 -0800 Received: by ozlabs.org (Postfix, from userid 1010) id 5210667A5D; Fri, 4 Feb 2005 01:29:55 +1100 (EST) Date: Fri, 4 Feb 2005 01:27:05 +1100 From: Anton Blanchard To: Herbert Xu Cc: Olaf Kirch , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: anton@samba.org Precedence: bulk X-list: netdev Hi, > For example, in this particular case, a more sinister (but probably > impossible for sk_buff objects) problem would be for the list removal > itself to be delayed until after the the kfree_skb. This could > potentially mean that we're reading/writing memory that's already > been freed. > > Perhaps we should always add a barrier to such operations. So > kfree_skb would become > > if (atomic_read(&skb->users) != 1) { > smp_mb__before_atomic_dec(); > if (!atomic_dec_and_test(&skb->users)) > return; > } > __kfree_skb(skb); Architectures should guarantee that any of the atomics and bitops that return values order in both directions. So you dont need the smp_mb__before_atomic_dec here. It is, however, required on the atomics and bitops that dont return values. Its difficult stuff, everyone gets it wrong and Andrew keeps hassling me to write up a document explaining it. Anton From Robert.Olsson@data.slu.se Thu Feb 3 07:24:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 07:25:05 -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 j13FOwx0026211 for ; Thu, 3 Feb 2005 07:24:59 -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 j13FOswY010556; Thu, 3 Feb 2005 16:24:54 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 49C33EE2A4; Thu, 3 Feb 2005 16:24:54 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16898.16966.272116.431070@robur.slu.se> Date: Thu, 3 Feb 2005 16:24:54 +0100 To: Nishanth Aravamudan Cc: davem@davemloft.net, robert.olsson@its.uu.se, netdev@oss.sgi.com, kernel-janitors@lists.osdl.org Subject: [PATCH 5/20] net/pktgen: remove interruptible_sleep_on_timeout() usage In-Reply-To: <20050202185823.GG2546@us.ibm.com> References: <20050202185823.GG2546@us.ibm.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Nishanth Aravamudan writes: > The first and last replacements in the following patch were slightly confusing > to me, as I have not used wait-queues that much myself. I did not exactly > understand how a locally defined wait-queue could be slept on, especially since > there are no wake_up() calls in pktgen.c. I was tempted to make the first sleep > a msleep_interruptible(100), but decided to patch for the same code before I did > that. > > Description: Replace deprecated interruptible_sleep_on_timeout() with direct > wait-queue usage or wait_event_interruptible_timeout() as appropriate. Tbanks! I've tested the patch w. msleep_interruptible(). It seems fine. Dave. This is on top of a patch I sent some days ago.. --ro --- net/core/pktgen.c.050201 2005-02-03 14:38:33.337577424 +0100 +++ net/core/pktgen.c 2005-02-03 15:44:22.959143680 +0100 @@ -104,6 +104,8 @@ * Corrections from Nikolai Malykh (nmalykh@bilim.com) * Removed unused flags F_SET_SRCMAC & F_SET_SRCIP 041230 * + * interruptible_sleep_on_timeout() replaced Nishanth Aravamudan + * 050103 */ #include #include @@ -135,6 +137,7 @@ #include #include #include +#include #include #include #include @@ -148,7 +151,7 @@ #include -#define VERSION "pktgen v2.56: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.57: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -2402,16 +2405,14 @@ static int pktgen_wait_thread_run(struct pktgen_thread *t ) { - wait_queue_head_t queue; - - init_waitqueue_head(&queue); - if_lock(t); while(thread_is_running(t)) { + if_unlock(t); - - interruptible_sleep_on_timeout(&queue, HZ/10); + + msleep_interruptible(100); + if (signal_pending(current)) goto signal; if_lock(t); @@ -2733,6 +2734,7 @@ static void pktgen_thread_worker(struct pktgen_thread *t) { + DEFINE_WAIT(wait); struct pktgen_dev *pkt_dev = NULL; int cpu = t->cpu; sigset_t tmpsig; @@ -2800,9 +2802,11 @@ do_softirq(); tx_since_softirq = 0; } + } else { + prepare_to_wait(&(t->queue), &wait, TASK_INTERRUPTIBLE); + schedule_timeout(HZ/10); + finish_wait(&(t->queue), &wait); } - else - interruptible_sleep_on_timeout(&(t->queue), HZ/10); /* * Back from sleep, either due to the timeout or signal. @@ -3112,8 +3116,7 @@ struct pktgen_thread *t = pktgen_threads; pktgen_threads->control |= (T_TERMINATE); - while( t == pktgen_threads) - interruptible_sleep_on_timeout(&queue, HZ); + wait_event_interruptible_timeout(queue, (t != pktgen_threads), HZ); } /* Un-register us from receiving netdevice events */ From abreu@datacom-telematica.com.br Thu Feb 3 08:51:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 08:51:05 -0800 (PST) Received: from eserver.datacom-telematica.com.br (radio-112-3.poa.terraempresas.com.br [200.176.112.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Gp0uf001120 for ; Thu, 3 Feb 2005 08:51:00 -0800 Received: (qmail 20815 invoked by uid 89); 3 Feb 2005 16:50:52 -0000 Received: from abreu@datacom-telematica.com.br by eserver by uid 89 with qmail-scanner-1.22 (clamdscan: 0.70. spamassassin: 2.55. Clear:RC:1(192.168.11.35):. Processed in 0.035529 secs); 03 Feb 2005 16:50:52 -0000 Received: from unknown (HELO abreu.local) (abreu@192.168.11.35) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Feb 2005 16:50:52 -0000 Date: Thu, 3 Feb 2005 14:51:10 -0200 From: DataCom - Abreu To: netdev@oss.sgi.com Subject: 8139too interframe gap Message-Id: <20050203145110.06fa5ca6.abreu@datacom-telematica.com.br> Organization: DataCom 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 version 0.81, clamav-milter version 0.81b 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: abreu@datacom-telematica.com.br Precedence: bulk X-list: netdev Hi, The driver 8139too configures interframe gap with the shortest possible interval. This behaviour was commited by Jeff on version 0.9.4.1. From changelog: * Do not set Interfame Gap (IFG) bits in TxConfig The chip spec, though, says that these bits must be set in order to conform to 802.3. There is a comment on the code that says exactly the opposite. I would like to know why the configuration is set this way. I have a problem where an external device inserts VLAN tags in frames, thus reducing the gap more yet. After that, too close frames (except the first one) are not recognized by a switch. I have set these bits and my problem disappears. My patch follows: --- linux-2.6.10/drivers/net/8139too.c 2004-12-24 19:33:47.000000000 -0200 +++ linux-2.6.10-mod/drivers/net/8139too.c 2005-02-03 13:47:15.000000000 -0200 @@ -391,7 +391,7 @@ /* Bits in TxConfig. */ enum tx_config_bits { TxIFG1 = (1 << 25), /* Interframe Gap Time */ - TxIFG0 = (1 << 24), /* Enabling these bits violates IEEE 802.3 */ + TxIFG0 = (1 << 24), /* Disabling any of these bits violates IEEE 802.3 */ TxLoopBack = (1 << 18) | (1 << 17), /* enable loopback test mode */ TxCRC = (1 << 16), /* DISABLE appending CRC to end of Tx packets */ TxClearAbt = (1 << 0), /* Clear abort (WO) */ @@ -723,7 +723,7 @@ #endif static const unsigned int rtl8139_tx_config = - (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); + TxIFG1 | TxIFG0 | (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); static void __rtl8139_cleanup_dev (struct net_device *dev) { Thanks. Marcelo Abreu From webmaster@rapidforum.com Thu Feb 3 09:04:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 09:04:43 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13H4cup002148 for ; Thu, 3 Feb 2005 09:04:39 -0800 Received: (qmail 2347 invoked by uid 1004); 3 Feb 2005 17:04:37 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 17:04:37 -0000 Message-ID: <42025998.5070704@rapidforum.com> Date: Thu, 03 Feb 2005 18:04:24 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <4201C9C5.1060002@pobox.com> In-Reply-To: <4201C9C5.1060002@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev Several users complain about downloads stalling at 99% as well... I was unable to solve this issue. Jeff Garzik wrote: > Christian Schmid wrote: > >> btw: Another problem I am experiencing is that downloads suddenly >> break in speed from 360 kb/sec to 8-12 kb/sec. 5 seconds later they >> stall completely. But the interesting part is, that the send-queue is >> completely full (checked with a grep in netstat). This looks like as >> if the receiver is just too slow. But this is not the case. That makes >> it rather funny. The receiver is waiting with an empty pipe but linux >> doesn't send. What could this be? > > > > With recent kernels, I've noticed that my browser progress bar will > download about 98% of a page, then stall for several seconds, then > complete. > > Very strange. Haven't investigated it at all, though. > > Jeff > > > > From davem@davemloft.net Thu Feb 3 10:21:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:21:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13ILdYe004754 for ; Thu, 3 Feb 2005 10:21:40 -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 1CwlUj-0007BL-00; Thu, 03 Feb 2005 10:14:21 -0800 Date: Thu, 3 Feb 2005 10:14:20 -0800 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203101420.468c1607.davem@davemloft.net> In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 01:27:05 +1100 Anton Blanchard wrote: > Architectures should guarantee that any of the atomics and bitops that > return values order in both directions. So you dont need the > smp_mb__before_atomic_dec here. > > It is, however, required on the atomics and bitops that dont return > values. Its difficult stuff, everyone gets it wrong and Andrew keeps > hassling me to write up a document explaining it. Sparc64 happens to order the atomic we use in the bitops and atomic_t ops, so sparc64 gets this right by accident. I had no idea about this requirement before reading your email. If IBM is seeing race this on ppc64, then I'm even more confused. If Anton understands the requirements, then ppc64 should have the return value atomic's implemented with the proper barriers. From davem@davemloft.net Thu Feb 3 10:55:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:55:10 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13It5hV005957 for ; Thu, 3 Feb 2005 10:55:06 -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 1Cwm1e-0007JB-00; Thu, 03 Feb 2005 10:48:22 -0800 Date: Thu, 3 Feb 2005 10:48:22 -0800 From: "David S. Miller" To: Olaf Kirch Cc: olh@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-Id: <20050203104822.05be3281.davem@davemloft.net> In-Reply-To: <20050203111939.GI31570@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 3 Feb 2005 12:19:39 +0100 Olaf Kirch wrote: > At 3445 rules, tmp.size is 524272 (why does it want that much memory? I > would expect the only data that's per-CPU is the packet and byte > counters). The rule itself is replicated per-cpu as well to keep L2 cache accesses local per cpu on SMP systems. From olh@suse.de Thu Feb 3 10:59:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 10:59:45 -0800 (PST) Received: from Cantor.suse.de (news.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Ixdtn006456 for ; Thu, 3 Feb 2005 10:59:39 -0800 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 Cantor.suse.de (Postfix) with ESMTP id 317B113FE6A8; Thu, 3 Feb 2005 19:59:33 +0100 (CET) Date: Thu, 3 Feb 2005 19:59:28 +0100 From: Olaf Hering To: "David S. Miller" Cc: Olaf Kirch , brugolsky@telemetry-investments.com, netdev@oss.sgi.com Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203185928.GA22832@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050203104822.05be3281.davem@davemloft.net> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: olh@suse.de Precedence: bulk X-list: netdev On Thu, Feb 03, David S. Miller wrote: > On Thu, 3 Feb 2005 12:19:39 +0100 > Olaf Kirch wrote: > > > At 3445 rules, tmp.size is 524272 (why does it want that much memory? I > > would expect the only data that's per-CPU is the packet and byte > > counters). > > The rule itself is replicated per-cpu as well to keep L2 cache > accesses local per cpu on SMP systems. Andy made this change, which helped on a dual box. diff -u linux-2.6.5/net/ipv4/netfilter/ip_tables.c-o linux-2.6.5/net/ipv4/netfilter/ip_tables.c --- linux-2.6.5/net/ipv4/netfilter/ip_tables.c-o 2005-02-03 08:06:33.000000000 +0100 +++ linux-2.6.5/net/ipv4/netfilter/ip_tables.c 2005-02-03 13:06:32.163182472 +0100 @@ -29,6 +29,12 @@ #include +#ifdef CONFIG_HOTPLUG_CPU +#define NF_NR_CPUS NR_CPUS +#else +#define NF_NR_CPUS num_online_cpus() +#endif + MODULE_LICENSE("GPL"); MODULE_AUTHOR("Netfilter Core Team "); MODULE_DESCRIPTION("IPv4 packet filter"); @@ -860,7 +866,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < NF_NR_CPUS; i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -882,7 +888,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < NF_NR_CPUS; i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -929,7 +935,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < NF_NR_CPUS; cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1067,7 +1073,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * NF_NR_CPUS); if (!newinfo) return -ENOMEM; @@ -1380,7 +1386,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(table->table->size) * NR_CPUS); + + SMP_ALIGN(table->table->size) * NF_NR_CPUS); if (!newinfo) return -ENOMEM; diff -u linux-2.6.5/mm/vmalloc.c-o linux-2.6.5/mm/vmalloc.c --- linux-2.6.5/mm/vmalloc.c-o 2005-02-03 08:06:50.000000000 +0100 +++ linux-2.6.5/mm/vmalloc.c 2005-02-03 13:07:44.162236952 +0100 @@ -310,7 +310,10 @@ __free_page(area->pages[i]); } - kfree(area->pages); + if (area->nr_pages * sizeof(struct page *) >= 4*PAGE_SIZE) + vfree(area->pages); + else + kfree(area->pages); } kfree(area); @@ -414,7 +417,11 @@ array_size = (nr_pages * sizeof(struct page *)); area->nr_pages = nr_pages; - area->pages = pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM)); + + if (array_size >= 4*PAGE_SIZE) + area->pages = pages = __vmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM), PAGE_KERNEL); + else + area->pages = pages = kmalloc(array_size, (gfp_mask & ~__GFP_HIGHMEM)); if (!area->pages) { remove_vm_area(area->addr); kfree(area); From davem@davemloft.net Thu Feb 3 11:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:07:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13J7X8Z007051 for ; Thu, 3 Feb 2005 11:07:33 -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 1CwmDh-0007Ne-00; Thu, 03 Feb 2005 11:00:49 -0800 Date: Thu, 3 Feb 2005 11:00:49 -0800 From: "David S. Miller" To: Olaf Hering Cc: okir@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: limited number if iptable rules on 64bit hosts Message-Id: <20050203110049.6b2d9c64.davem@davemloft.net> In-Reply-To: <20050203185928.GA22832@suse.de> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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 Thu, 3 Feb 2005 19:59:28 +0100 Olaf Hering wrote: > On Thu, Feb 03, David S. Miller wrote: > > > The rule itself is replicated per-cpu as well to keep L2 cache > > accesses local per cpu on SMP systems. > > Andy made this change, which helped on a dual box. It might not help for Olaf's 128 cpu box though :-) I think reconsider the idea of replicating the rule itself per-cpu. Also, this thread should have begun with netfilter-devel at least on the CC:, added. From bdschuym@pandora.be Thu Feb 3 11:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:27:47 -0800 (PST) Received: from asia.telenet-ops.be (asia.telenet-ops.be [195.130.132.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JRghW007851 for ; Thu, 3 Feb 2005 11:27:43 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id 9BCCC22413B; Thu, 3 Feb 2005 20:27:41 +0100 (MET) Received: from 192.168.0.138 (dD5763CA9.access.telenet.be [213.118.60.169]) by asia.telenet-ops.be (Postfix) with ESMTP id 0F0AF224085; Thu, 3 Feb 2005 20:27:41 +0100 (MET) Subject: Re: limited number if iptable rules on 64bit hosts From: Bart De Schuymer To: "David S. Miller" Cc: Olaf Hering , okir@suse.de, brugolsky@telemetry-investments.com, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org In-Reply-To: <20050203110049.6b2d9c64.davem@davemloft.net> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> <20050203110049.6b2d9c64.davem@davemloft.net> Content-Type: text/plain Date: Thu, 03 Feb 2005 20:33:51 +0100 Message-Id: <1107459231.3381.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean 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: bdschuym@pandora.be Precedence: bulk X-list: netdev Op do, 03-02-2005 te 11:00 -0800, schreef David S. Miller: > On Thu, 3 Feb 2005 19:59:28 +0100 > Olaf Hering wrote: > > > On Thu, Feb 03, David S. Miller wrote: > > > > > The rule itself is replicated per-cpu as well to keep L2 cache > > > accesses local per cpu on SMP systems. > > > > Andy made this change, which helped on a dual box. > > It might not help for Olaf's 128 cpu box though :-) > > I think reconsider the idea of replicating the rule itself per-cpu. > Also, this thread should have begun with netfilter-devel at least on > the CC:, added. Note that ebtables only has per-cpu counters. I wonder what limits are seen on such systems for ebtables. cheers, Bart From shemminger@osdl.org Thu Feb 3 11:33:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:33:50 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JXgZW008383 for ; Thu, 3 Feb 2005 11:33:43 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13JXPl11349; Thu, 3 Feb 2005 11:33:26 -0800 Date: Thu, 3 Feb 2005 11:33:35 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050203113335.46396c11@dxpl.pdx.osdl.net> In-Reply-To: <4201B4EA.2030101@rapidforum.com> References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 06:21:46 +0100 Christian Schmid wrote: > Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was > very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every > second now... *sigh* well maybe you might just want to add a /proc file in order to configure this > behaviour. > > btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to > 8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue > is completely full (checked with a grep in netstat). This looks like as if the receiver is just too > slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty > pipe but linux doesn't send. What could this be? > Are you using a board that support TCP Segmentation Offload. The problem may well be that before we were not doing congestion control properly with TSO. A pre-2.6.8 host with TSO was violating all sorts of RFC's and unfairly monopolizing bandwidth. -- Stephen Hemminger From shemminger@osdl.org Thu Feb 3 11:52:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:52:18 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13JqBnm009293 for ; Thu, 3 Feb 2005 11:52:11 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13JpHl16131; Thu, 3 Feb 2005 11:51:17 -0800 Date: Thu, 3 Feb 2005 11:51:27 -0800 From: Stephen Hemminger To: Lorenzo =?ISO-8859-1?B?SGVybuFuZGV6IEdhcmPtYS1IaWVycm8=?= Cc: linux@horizon.com, mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, Valdis.Kletnieks@vt.edu, spender@grsecurity.net Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050203115127.3245951f@dxpl.pdx.osdl.net> In-Reply-To: <1107365917.3754.155.camel@localhost.localdomain> References: <20050202171702.24523.qmail@science.horizon.com> <1107365917.3754.155.camel@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (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=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j13JqBnm009293 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: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 02 Feb 2005 18:38:37 +0100 Lorenzo Hernández García-Hierro wrote: > El mié, 02-02-2005 a las 17:17 +0000, linux@horizon.com escribió: > > There *are* things in OpenBSD, like randomized port assignment (as opposed > > to the linear scan in tcp_v4_get_port()) that would be worth emulating. > > Maybe worry about that first? > > Recent 2.6 does a more advanced form of port randomization already using address hash at connect time. tcp_v4_get_port is only used for the case of applications that explicitly bind to port zero to find a free port. So the sequence: socket(); connect(); will assign a random port in a manner similar to sequence number creation The sequence: socket(); bind(); connect(); assigns a simple linear increasing port value. It could be randomized, but most applications don't bother binding, so the first case is sufficient. -- Stephen Hemminger From webmaster@rapidforum.com Thu Feb 3 11:59:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 11:59:09 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13Jx2C3009985 for ; Thu, 3 Feb 2005 11:59:03 -0800 Received: (qmail 13663 invoked by uid 1004); 3 Feb 2005 19:59:02 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 19:59:02 -0000 Message-ID: <42028278.7040008@rapidforum.com> Date: Thu, 03 Feb 2005 20:58:48 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> In-Reply-To: <20050203113335.46396c11@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev Hm how can I check that? and what do you mean with "board"? Mainboard? NIC? its an onboard-nic on this mainboard: http://www.supermicro.com/products/motherboard/Xeon/E7501/X5DP8-G2.cfm The worst thing is the stalled downloads. It drops to 8-12 kb-sec. sometimes after a few seconds it goes up to full speed again, but sometimes it suddenly stops completely. After a few seconds it continues with full speed or it stalls forever. send-queue is always full..... Thank you for your help in this matter. Chris Stephen Hemminger wrote: > On Thu, 03 Feb 2005 06:21:46 +0100 > Christian Schmid wrote: > > >>Actually, thats my problem. Single streams are too slow! Before I had buffers up to 500 KB. This was >>very nice to CPU because I only needed to "push" more data once in 5 seconds. I am doing this every >>second now... *sigh* well maybe you might just want to add a /proc file in order to configure this >>behaviour. >> >>btw: Another problem I am experiencing is that downloads suddenly break in speed from 360 kb/sec to >>8-12 kb/sec. 5 seconds later they stall completely. But the interesting part is, that the send-queue >>is completely full (checked with a grep in netstat). This looks like as if the receiver is just too >>slow. But this is not the case. That makes it rather funny. The receiver is waiting with an empty >>pipe but linux doesn't send. What could this be? >> > > > Are you using a board that support TCP Segmentation Offload. The problem may well be that > before we were not doing congestion control properly with TSO. A pre-2.6.8 host with TSO was violating > all sorts of RFC's and unfairly monopolizing bandwidth. > From marcel@holtmann.org Thu Feb 3 12:04:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:04:46 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13K4dtu010606 for ; Thu, 3 Feb 2005 12:04:40 -0800 Received: from pegasus (p3EE2CEA9.dip.t-dialin.net [62.226.206.169]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j13K4ihH030983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Feb 2005 21:04:45 +0100 Subject: Problem with "ESP: sha1 digestsize 20 != 0" From: Marcel Holtmann To: Network Development Mailing List Content-Type: text/plain Date: Thu, 03 Feb 2005 21:04:33 +0100 Message-Id: <1107461073.6833.8.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: marcel@holtmann.org Precedence: bulk X-list: netdev Hi, when using my RAS account with 2.6.11-rc3, I see a lot of ESP: sha1 digestsize 20 != 0 messages in my logs and the IPsec tunnel is not working. I tracked the problem down to the change below. After reverting this patch, everything works like before. Regards Marcel ChangeSet@1.1830.738.7, 2005-01-25 21:53:42-08:00, herbert@gondor.apana.org.au [XFRM]: Probe selected algorithm only. This patch removes an annoying problem in xfrm_user. As it is every time an SA is added it probes every known algorithm in the universe. Now if they all existed it would be OK. However, for the ones which don't actually exist this causes multiple /sbin/modprobe processes to be spawned which slows the system down when you're adding hundreds of SAs. Since we know the type of algorithm required when we're adding a new SA, we can get away with only probing the selected algorithms. This is what the following patch does for xfrm_user. From buytenh@wantstofly.org Thu Feb 3 12:14:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:14:14 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KE9bC011431 for ; Thu, 3 Feb 2005 12:14:10 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 8BA762B0EC; Thu, 3 Feb 2005 21:14:08 +0100 (MET) Date: Thu, 3 Feb 2005 21:14:08 +0100 From: Lennert Buytenhek To: Stephen Hemminger Cc: Lorenzo =?iso-8859-1?Q?Hern=E1ndez_Garc=EDa-Hierro?= , linux@horizon.com, mingo@elte.hu, Arjan van de Ven , bunk@stusta.de, Chris Wright , davem@redhat.com, Hank Leininger , "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, Valdis.Kletnieks@vt.edu, spender@grsecurity.net Subject: Re: [PATCH] OpenBSD Networking-related randomization port Message-ID: <20050203201408.GB3199@xi.wantstofly.org> References: <20050202171702.24523.qmail@science.horizon.com> <1107365917.3754.155.camel@localhost.localdomain> <20050203115127.3245951f@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203115127.3245951f@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote: > Recent 2.6 does a more advanced form of port randomization already > using address hash at connect time. tcp_v4_get_port is only used for > the case of applications that explicitly bind to port zero to find a > free port. Is any such randomisation done or planned for UDP? --L From shemminger@osdl.org Thu Feb 3 12:15:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:15:07 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KF1ff011723 for ; Thu, 3 Feb 2005 12:15:01 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j13KEsl20870; Thu, 3 Feb 2005 12:14:54 -0800 Date: Thu, 3 Feb 2005 12:15:03 -0800 From: Stephen Hemminger To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... Message-ID: <20050203121503.4f122779@dxpl.pdx.osdl.net> In-Reply-To: <42028278.7040008@rapidforum.com> References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 03 Feb 2005 20:58:48 +0100 Christian Schmid wrote: E1000 support TSO. To check if it is enabled do: ethtool -k eth0 To turn it off use. ethtool -K eth0 tso off You get the idea.. -- Stephen Hemminger From webmaster@rapidforum.com Thu Feb 3 12:19:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:19:38 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13KJXNT015791 for ; Thu, 3 Feb 2005 12:19:34 -0800 Received: (qmail 14775 invoked by uid 1004); 3 Feb 2005 20:19:32 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 20:19:32 -0000 Message-ID: <42028747.6060602@rapidforum.com> Date: Thu, 03 Feb 2005 21:19:19 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> In-Reply-To: <20050203121503.4f122779@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on What exactly is tcp segmentation offload? Where can I read more about it? Should I disable it or is this not a good idea? Stephen Hemminger wrote: > On Thu, 03 Feb 2005 20:58:48 +0100 > Christian Schmid wrote: > > E1000 support TSO. To check if it is enabled do: > ethtool -k eth0 > To turn it off use. > ethtool -K eth0 tso off > > You get the idea.. > From herbert@gondor.apana.org.au Thu Feb 3 12:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:31: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 j13KVQV3019208 for ; Thu, 3 Feb 2005 12:31: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 1Cwncu-0004YC-00; Fri, 04 Feb 2005 07:30:56 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwncA-0001qT-00; Fri, 04 Feb 2005 07:30:10 +1100 Date: Fri, 4 Feb 2005 07:30:10 +1100 To: Anton Blanchard Cc: Olaf Kirch , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203203010.GA7081@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote: > > Architectures should guarantee that any of the atomics and bitops that > return values order in both directions. So you dont need the > smp_mb__before_atomic_dec here. I wasn't aware of this requirement before. However, if this is so, why don't we get rid of the smp_mb__* macros? 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 Feb 3 12:40:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:40:35 -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 j13KeQgc019963 for ; Thu, 3 Feb 2005 12:40: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 1Cwnll-0004dv-00; Fri, 04 Feb 2005 07:40:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwnlK-0001rv-00; Fri, 04 Feb 2005 07:39:38 +1100 From: Herbert Xu To: marcel@holtmann.org (Marcel Holtmann) Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" Cc: netdev@oss.sgi.com, davem@davemloft.net Organization: Core In-Reply-To: <1107461073.6833.8.camel@pegasus> 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, 04 Feb 2005 07:39:38 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Marcel Holtmann wrote: > > when using my RAS account with 2.6.11-rc3, I see a lot of > > ESP: sha1 digestsize 20 != 0 > > messages in my logs and the IPsec tunnel is not working. I tracked the > problem down to the change below. After reverting this patch, everything > works like before. Sorry, my fault. The name test in xfrm_get_byname is inverted. 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 -- ===== net/xfrm/xfrm_algo.c 1.16 vs edited ===== --- 1.16/net/xfrm/xfrm_algo.c 2005-01-26 16:53:19 +11:00 +++ edited/net/xfrm/xfrm_algo.c 2005-02-04 07:38:16 +11:00 @@ -357,7 +357,7 @@ return NULL; for (i = 0; i < entries; i++) { - if (!strcmp(name, list[i].name)) + if (strcmp(name, list[i].name)) continue; if (list[i].available) From rick.jones2@hp.com Thu Feb 3 12:47:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 12:47:19 -0800 (PST) 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 j13KlFDa020558 for ; Thu, 3 Feb 2005 12:47:15 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 138809ED for ; Thu, 3 Feb 2005 12:47:15 -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 MAA15008 for ; Thu, 3 Feb 2005 12:47:14 -0800 (PST) Message-ID: <42028DD2.2010809@hp.com> Date: Thu, 03 Feb 2005 12:47:14 -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@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> In-Reply-To: <42028747.6060602@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rick.jones2@hp.com Precedence: bulk X-list: netdev Christian Schmid wrote: > Offload parameters for eth0: > rx-checksumming: on > tx-checksumming: on > scatter-gather: on > tcp segmentation offload: on > > What exactly is tcp segmentation offload? TCP Segmentation Offload, aka TSO or in other contexts "large send" can be thought of as a "poor man's" Jumbo Frame. The NIC advertises to the host that it can resegment larger TCP segments into sizes apropriate for the network. This allows the host CPU stack to make fewer trips down the protocol stack to transfer a given quantity of data, thus reducing the service demand (quantity of CPU consumed per quantity of work). The reduction in service demand can result in an increase in throughput if the transfer was previously CPU-bound. It has the advantage over JumboFrame in that it does not require support in the rest of the infrastructure (switches, routers, receivers etc). I call it "poor man's" JumboFrame because it does not reduce the overheads on the receiver - the receiver still sees just as many "normally" sized segments as before, and sends just as many ACKs per KB transferred as before. If a NIC is implemented with a microprocessor (bletch - personal opinion) the additional demands of TSO resegmenation may actually reduce throughput even as it greatly reduces server CPU utilization. That was particularly evident in old Tigon2 NICs. I am not sure if that is noticable in current generation BMC570X's or not - most of the systems I have at my disposal have BCM5701's in them and I'm not sure the drivers allow TSO to be enabled on that rev? I've not seen a drop in maximum throughput on the "e1000" NICs I've played with, which have been some dual-port cards HP sells. YMMV. > Where can I read more about it? In addition to whatever there may be in Linux documentation... TSO or large send is also a long-standing feature of TCP in AIX and (dare I say it here?-) Windows. As such IBM and Microsoft may have writeups - I'm pretty sure that Microsoft had a write-up about it on their website - talking about the NDIS interface at least. It is also a fairly recent addition to HP-UX, but I am not sure if there are any writeups about it on HP's websites yet. >Should I disable it or is this not a good idea? That depends. If you are concerned about proper slow-start behaviour at the beginning of a connection you should disable it until you are on a later rev. I've always wondered if it wouldn't be an interesting experiment with a "real" server to see if dishonouring slow-start at connection establishment (and there only, keep it after RTO) made all that much a difference in the host's retransmission rates... rick jones From marcel@holtmann.org Thu Feb 3 13:02:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 13:02:55 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13L2oH7021357 for ; Thu, 3 Feb 2005 13:02:51 -0800 Received: from pegasus (p3EE2CEA9.dip.t-dialin.net [62.226.206.169]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j13L2ihH031379 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Feb 2005 22:02:44 +0100 Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" From: Marcel Holtmann To: Herbert Xu Cc: Network Development Mailing List , "David S. Miller" In-Reply-To: References: Content-Type: text/plain Date: Thu, 03 Feb 2005 22:02:33 +0100 Message-Id: <1107464553.6911.0.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: marcel@holtmann.org Precedence: bulk X-list: netdev Hi Herbert, > > when using my RAS account with 2.6.11-rc3, I see a lot of > > > > ESP: sha1 digestsize 20 != 0 > > > > messages in my logs and the IPsec tunnel is not working. I tracked the > > problem down to the change below. After reverting this patch, everything > > works like before. > > Sorry, my fault. > > The name test in xfrm_get_byname is inverted. now it is working again. Thanks. Regards Marcel From rugolsky@telemetry-investments.com Thu Feb 3 13:35:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 13:35:53 -0800 (PST) Received: from ti41.telemetry-investments.com (209-166-240-202.cust.walrus.com [209.166.240.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13LZmij022324 for ; Thu, 3 Feb 2005 13:35:49 -0800 Received: from ti64.telemetry-investments.com (ti64 [192.168.8.64]) by ti41.telemetry-investments.com (Postfix) with ESMTP id DF13E10107; Thu, 3 Feb 2005 16:35:42 -0500 (EST) Received: by ti64.telemetry-investments.com (Postfix, from userid 343) id D41EFFF2C; Thu, 3 Feb 2005 16:35:42 -0500 (EST) Date: Thu, 3 Feb 2005 16:35:42 -0500 From: "Bill Rugolsky Jr." To: "David S. Miller" Cc: Olaf Hering , okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: limited number if iptable rules on 64bit hosts Message-ID: <20050203213542.GC16868@ti64.telemetry-investments.com> References: <20050202133851.GA9680@suse.de> <20050202222516.GA15440@suse.de> <20050202223853.GA29237@ti64.telemetry-investments.com> <20050202225258.GA15563@suse.de> <20050203111939.GI31570@suse.de> <20050203104822.05be3281.davem@davemloft.net> <20050203185928.GA22832@suse.de> <20050203110049.6b2d9c64.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203110049.6b2d9c64.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: brugolsky@telemetry-investments.com Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 11:00:49AM -0800, David S. Miller wrote: > It might not help for Olaf's 128 cpu box though :-) > > I think reconsider the idea of replicating the rule itself per-cpu. > Also, this thread should have begun with netfilter-devel at least on > the CC:, added. As Olaf Kirch pointed out, an entry is about 150 bytes, while the counters are two 64-bit ints, and it looks like 'unsigned int comefrom' is set as the chains are traversed [net/ipv4/netfilter/ip_tables.c]: /* Save old back ptr in next entry */ struct ipt_entry *next = (void *)e + e->next_offset; next->comefrom = (void *)back - table_base; /* set back pointer to next entry */ back = next; That's 20-24 bytes of state per-entry per-cpu, for a factor of 6-7 savings, at the expense of hairing up the code slightly to do parallel indexed access, Fortran style. If I am understanding the mm code correctly, a single vmalloc() allocation is currently limited to 64M on a 64-bit platform, but the VMALLOC address range is much greater, so one might also prefer to do a kmalloc()/vmalloc() per CPU, perhaps by creating {vmalloc,vfree}_percpu() and using the percpu interfaces. Bill Rugolsky From jgarzik@pobox.com Thu Feb 3 14:13:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:13:57 -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 j13MDqhe023755 for ; Thu, 3 Feb 2005 14:13:53 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwpEV-0004Cx-1h; Thu, 03 Feb 2005 22:13:51 +0000 Message-ID: <4202A206.7060100@pobox.com> Date: Thu, 03 Feb 2005 17:13:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schmid CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> In-Reply-To: <42028747.6060602@rapidforum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jgarzik@pobox.com Precedence: bulk X-list: netdev Christian Schmid wrote: > What exactly is tcp segmentation offload? Where can I read more about > it? Should I disable it or is this not a good idea? It's an optimization designed to reduce CPU usage for zero-copy apps (those that use sendfile(2)). It would be a useful datapoint to disable TSO, and see if that improves things for you. Jeff From davem@davemloft.net Thu Feb 3 14:26:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:26:29 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13MQOfC024432 for ; Thu, 3 Feb 2005 14:26:24 -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 1CwpJV-0008Cm-00; Thu, 03 Feb 2005 14:19:01 -0800 Date: Thu, 3 Feb 2005 14:19:01 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203141901.5ce04c92.davem@davemloft.net> In-Reply-To: <20050203203010.GA7081@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 07:30:10 +1100 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote: > > > > Architectures should guarantee that any of the atomics and bitops that > > return values order in both directions. So you dont need the > > smp_mb__before_atomic_dec here. > > I wasn't aware of this requirement before. However, if this is so, > why don't we get rid of the smp_mb__* macros? They are for cases where you want strict ordering even for the non-return-value-giving atomic_t ops. Actually.... Herbert has a point. By Anton's specification, several uses in 2.6.x I see of these smp_mb__*() routines are bogus. Case in point, look at mm/filemap.c: void fastcall unlock_page(struct page *page) { smp_mb__before_clear_bit(); if (!TestClearPageLocked(page)) BUG(); smp_mb__after_clear_bit(); wake_up_page(page, PG_locked); } TestClearPageLocked() uses one of the bitops returning a value, so must be providing the explicit memory barriers in it's implementation. void end_page_writeback(struct page *page) { if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) { if (!test_clear_page_writeback(page)) BUG(); } smp_mb__after_clear_bit(); wake_up_page(page, PG_writeback); } Same thing there. Looking at include/linux/sunrpc/sched.h, those uses are legitimate, correct, and needed. As is the put_bh() use in include/linux/buffer_head.h There are several other correct and necessary uses in: include/linux/interrupt.h include/linux/netdevice.h include/linux/nfs_page.h include/linux/spinlock.h net/core/dev.c net/sunrpc/sched.c sound/pci/bt87x.c fs/buffer.c fs/nfs/pagelist.c drivers/block/ll_rw_blk.c arch/ppc64/kernel/smp.c arch/i386/kernel/smp.c arch/i386/mach-voyager/smp.c I'm working on a rough but rather complete draft Anton said needs to be written to explicitly spell out the atomic_t and bitops stuff. From webmaster@rapidforum.com Thu Feb 3 14:29:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:29:38 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j13MTX8e024937 for ; Thu, 3 Feb 2005 14:29:34 -0800 Received: (qmail 20779 invoked by uid 1004); 3 Feb 2005 22:29:32 -0000 Received: from p3ee04d3c.dip0.t-ipconnect.de (HELO ?62.224.77.60?) (62.224.77.60) by www.rapidforum.com with SMTP; 3 Feb 2005 22:29:32 -0000 Message-ID: <4202A5B6.5080903@rapidforum.com> Date: Thu, 03 Feb 2005 23:29:10 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: TCP-Protection is really a pain... References: <4201A382.1020208@rapidforum.com> <20050202205437.571a702b@localhost.localdomain> <4201B4EA.2030101@rapidforum.com> <20050203113335.46396c11@dxpl.pdx.osdl.net> <42028278.7040008@rapidforum.com> <20050203121503.4f122779@dxpl.pdx.osdl.net> <42028747.6060602@rapidforum.com> <4202A206.7060100@pobox.com> In-Reply-To: <4202A206.7060100@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: webmaster@rapidforum.com Precedence: bulk X-list: netdev I turned it off and without it, I was unable to reproduce any stalls anymore. Jeff Garzik wrote: > Christian Schmid wrote: > >> What exactly is tcp segmentation offload? Where can I read more about >> it? Should I disable it or is this not a good idea? > > > It's an optimization designed to reduce CPU usage for zero-copy apps > (those that use sendfile(2)). > > It would be a useful datapoint to disable TSO, and see if that improves > things for you. > > Jeff > > > > From sudeep.list@gmail.com Thu Feb 3 14:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 14:45:19 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13MjF7Z025749 for ; Thu, 3 Feb 2005 14:45:16 -0800 Received: by rproxy.gmail.com with SMTP id a41so516159rng for ; Thu, 03 Feb 2005 14:45:15 -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=V2qeG9laEFqkB+494ibAlyj+/BXPxmcRCWhiyuDJrvXOtrnr9o7sfF1sEmiNFYRvnNzLspLXiql8VYlGZOBiwhSzGoTi4gxGVB02/mfXRyGA11J6zfkIq5/e+kK5N4BdUbe+1MoPU88SUHgIkAaEPB1zbBZxVryZ8r3hqz5MW74= Received: by 10.38.9.54 with SMTP id 54mr156386rni; Thu, 03 Feb 2005 14:45:15 -0800 (PST) Received: by 10.38.72.22 with HTTP; Thu, 3 Feb 2005 14:45:15 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 15:45:15 -0700 From: sudeep list Reply-To: sudeep list To: netdev@oss.sgi.com Subject: pointers in the sk_buff structure. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: sudeep.list@gmail.com Precedence: bulk X-list: netdev hello, I figured that the pointer sk_buff->tail points to the end of data in the buffer attached to the sk_buff. What does the pointer sk_buff->end point to ? Is there any data that lies between the two pointers, or they are two pointers to the same address (end of data in the buffer area) ? Sudeep From davem@davemloft.net Thu Feb 3 15:15:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:15:46 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13NFcdZ027041 for ; Thu, 3 Feb 2005 15:15:39 -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 1Cwq5G-0008R7-00; Thu, 03 Feb 2005 15:08:22 -0800 Date: Thu, 3 Feb 2005 15:08:21 -0800 From: "David S. Miller" To: Anton Blanchard Cc: herbert@gondor.apana.org.au, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203150821.2321130b.davem@davemloft.net> In-Reply-To: <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 01:27:05 +1100 Anton Blanchard wrote: > Its difficult stuff, everyone gets it wrong and Andrew keeps > hassling me to write up a document explaining it. Ok, here goes nothing. Can someone run with this? It should be rather complete, and require only minor editorial work. --- atomic_ops.txt --- This document is intended to serve as a guide to Linux port maintainers on how to implement atomic counter and bitops operations properly. The atomic_t type should be defined as a signed integer. Also, it should be made opaque such that any kind of cast to a normal C integer type will fail. Something like the following should suffice: typedef struct { volatile int counter; } atomic_t; The first operations to implement for atomic_t's are the initializers and plain reads. #define ATOMIC_INIT(i) { (i) } #define atomic_set(v, i) ((v)->counter = (i)) The first macro is used in definitions, such as: static atomic_t my_counter = ATOMIC_INIT(1); The second interface can be used at runtime, as in: k = kmalloc(sizeof(*k), GFP_KERNEL); if (!k) return -ENOMEM; atomic_set(&k->counter, 0); Next, we have: #define atomic_read(v) ((v)->counter) which simply reads the current value of the counter. Now, we move onto the actual atomic operation interfaces. void atomic_add(int i, atomic_t *v); void atomic_sub(int i, atomic_t *v); void atomic_inc(atomic_t *v); void atomic_dec(atomic_t *v); These four routines add and subtract integral values to/from the given atomic_t value. The first two routines pass explicit integers by which to make the adjustment, whereas the latter two use an implicit adjustment value of "1". One very important aspect of these two routines is that they DO NOT require any explicit memory barriers. They need only perform the atomic_t counter update in an SMP safe manner. Next, we have: int atomic_inc_return(atomic_t *v); int atomic_dec_return(atomic_t *v); These routines add 1 and subtract 1, respectively, from the given atomic_t and return the new counter value after the operation is performed. Unlike the above routines, it is required that explicit memory barriers are performed before and after the operation. It must be done such that all memory operations before and after the atomic operation calls are strongly ordered with respect to the atomic operation itself. For example, it should behave as if a smp_mb() call existed both before and after the atomic operation. If the atomic instructions used in an implementation provide explicit memory barrier semantics which satisfy the above requirements, that is fine as well. Let's move on: int atomic_add_return(int i, atomic_t *v); int atomic_sub_return(int i, atomic_t *v); These behave just like atomic_{inc,dec}_return() except that an explicit counter adjustment is given instead of the implicit "1". This means that like atomic_{inc,dec}_return(), the memory barrier semantics are required. Next: int atomic_inc_and_test(atomic_t *v); int atomic_dec_and_test(atomic_t *v); These two routines increment and decrement by 1, respectively, the given atomic counter. They return a boolean indicating whether the resulting counter value was zero or not. It requires explicit memory barrier semantics around the operation as above. int atomic_sub_and_test(int i, atomic_t *v); This is identical to atomic_dec_and_test() except that an explicit decrement is given instead of the implicit "1". It requires explicit memory barrier semantics around the operation. int atomic_add_negative(int i, atomic_t *v); The given increment is added to the given atomic counter value. A boolean is return which indicates whether the resulting counter value is negative. It requires explicit memory barrier semantics around the operation. If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: void smb_mb__before_atomic_dec(void); void smb_mb__after_atomic_dec(void); void smb_mb__before_atomic_inc(void); void smb_mb__after_atomic_dec(void); For example, smb_mb__before_atomic_dec() can be used like so: obj->dead = 1; smb_mb__before_atomic_dec(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceeding the atomic_dec() call are strongly ordered with respect to the atomic counter operation. In the above example, it guarentees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. Without the explicitl smb_mb__before_atomic_dec() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. The other three interfaces listed are used to provide explicit ordering with respect to memory operations after an atomic_dec() call (smb_mb__after_atomic_dec()) and around atomic_inc() calls (smb_mb__{before,after}_atomic_inc()). A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disasterous results. Here is an example, which follows a pattern occuring frequently in the Linux kernel. It is the use of atomic counters to implement reference counting, and it works such that once the counter falls to zero it can be guarenteed that no other entity can be accessing the object. Observe: list_del(&obj->list); if (atomic_dec_and_test(&obj->ref_count)) kfree(obj); Here, the list (say it is some linked list on which object searches are performed) creates the reference to the object. The insertion code probably looks something like this: atomic_inc(&obj->ref_count); list_add(&obj->list, &global_obj_list); And searches look something like: for_each(obj, &global_obj_list) { if (key_compare(obj->key, key)) { atomic_inc(&obj->ref_count); return obj; } } return NULL; Given the above scheme, it must be the case that the list_del() be visible to other processors before the atomic counter decrement is performed. Otherwise, the counter could fall to zero, yet the object is still visible for lookup on the linked list. So we'd get a bogus sequence like this: cpu 0 cpu 1 list_del(&obj->list); ... visibility delayed ... lookup and find obj on global_obj_list atomic_dec_and_test(); obj refcount hits zero, this is visible globally atomic_inc() obj refcount incremented to one list_del() becomes visible kfree(obj); obj is now freed up memory --> CRASH With the memory barrier semantics required of the atomic_t operations which return values, the above sequence of memory visibility can never happen. We will now cover the atomic bitmask operations. You will find that their SMP and memory barrier semantics are similar in shape to the atomic_t ops above. Native atomic bit operations are defined to operate on objects aligned to the size of an "unsigned long" C data type, and are least of that size. The endianness of the bits within each "unsigned long" are the native endianness of the cpu. void set_bit(unsigned long nr, volatils unsigned long *addr); void clear_bit(unsigned long nr, volatils unsigned long *addr); void change_bit(unsigned long nr, volatils unsigned long *addr); These routines set, clear, and change, respectively, the bit number indicated by "nr" on the bit mask pointed to by "ADDR". They must execute atomically, yet there are no implicit memory barrier semantics required of these interfaces. long test_and_set_bit(unsigned long nr, volatils unsigned long *addr); long test_and_clear_bit(unsigned long nr, volatils unsigned long *addr); long test_and_change_bit(unsigned long nr, volatils unsigned long *addr); Like the above, except that these routines return a boolean which indicates whether the changed bit was set _BEFORE_ the atomic bit operation. These routines, like the atomic_t counter operations returning values, require explicit memory barrier semantics around their execution. All memory operations before the atomic bit operation call must be made visible globally before the atomic bit operation is made visible. Likewise, the atomic bit operation must be visible globally before any subsequent memory operation is made visible. For example: obj->dead = 1; if (test_and_set_bit(0, &obj->flags)) /* ... */; obj->killed = 1; The implementation of test_and_set_bit() must guarentee that "obj->dead = 1;" is visible to cpus before the atomic memory operation done by test_and_set_bit() becomes visible. Likewise, the atomic memory operation done by test_and_set_bit() must become visible before "obj->killed = 1;" is visible. Finally there is the basic operation: long test_bit(unsigned long nr, __const__ volatile unsigned long *addr); Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". If explicit memory barriers are required around clear_bit() (which does not return a value, and thus does not need to provide memory barrier semantics), two interfaces are provided: void smp_mb__before_clear_bit(void); void smp_mb__after_clear_bit(void); They are used as follows, and are akin to their atomic_t operation brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ smp_mb__before_clear_bit(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ smp_mb__after_clear_bit(); Finally, there are non-atomic versions of the bitmask operations provided. They are used in contexts where some other higher-level SMP locking scheme is being used to protect the bitmask, and thus less expensive non-atomic operations may be used in the implementation. They have names similar to the above bitmask operation interfaces, except that two underscores are prefixed to the interface name. void __set_bit(unsigned long nr, volatile unsigned long *addr); void __clear_bit(unsigned long nr, volatile unsigned long *addr); void __change_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_set_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_change_bit(unsigned long nr, volatile unsigned long *addr); These non-atomic variants also do not require any special memory barrier semantics. From davem@davemloft.net Thu Feb 3 15:51:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:51:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Np274028018 for ; Thu, 3 Feb 2005 15:51:02 -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 1Cwqdb-00008J-00; Thu, 03 Feb 2005 15:43:51 -0800 Date: Thu, 3 Feb 2005 15:43:51 -0800 From: "David S. Miller" To: Herbert Xu Cc: marcel@holtmann.org, netdev@oss.sgi.com Subject: Re: Problem with "ESP: sha1 digestsize 20 != 0" Message-Id: <20050203154351.1c653848.davem@davemloft.net> In-Reply-To: References: <1107461073.6833.8.camel@pegasus> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 04 Feb 2005 07:39:38 +1100 Herbert Xu wrote: > Marcel Holtmann wrote: > > > > when using my RAS account with 2.6.11-rc3, I see a lot of > > > > ESP: sha1 digestsize 20 != 0 > > > > messages in my logs and the IPsec tunnel is not working. I tracked the > > problem down to the change below. After reverting this patch, everything > > works like before. > > Sorry, my fault. > > The name test in xfrm_get_byname is inverted. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From herbert@gondor.apana.org.au Thu Feb 3 15:51:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 15:52:05 -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 j13NpuAw028318 for ; Thu, 3 Feb 2005 15:51:57 -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 1Cwqku-0005zu-00; Fri, 04 Feb 2005 10:51:24 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CwqkH-0002CF-00; Fri, 04 Feb 2005 10:50:45 +1100 Date: Fri, 4 Feb 2005 10:50:44 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050203235044.GA8422@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20050203141901.5ce04c92.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 03, 2005 at 02:19:01PM -0800, David S. Miller wrote: > > They are for cases where you want strict ordering even for the > non-return-value-giving atomic_t ops. I see. I got atomic_dec and atomic_dec_and_test mixed up. So the problem isn't as big as I thought which is good. sk_buff is only in trouble because of the atomic_read optimisation which really needs a memory barrier. However, instead of adding a memory barrier which makes the optimisation less useful, let's just get rid of the atomic_read. Signed-off-by: Herbert Xu Thanks for the document, it's really helpful. 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=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-04 10:44:17 +11:00 @@ -353,14 +353,14 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) + if (atomic_dec_and_test(&skb->users)) __kfree_skb(skb); } /* Use this if you didn't touch the skb state [for fast switching] */ static inline void kfree_skb_fast(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) + if (atomic_dec_and_test(&skb->users)) kfree_skbmem(skb); } --fUYQa+Pmc3FrFX/N-- From andy.furniss@dsl.pipex.com Thu Feb 3 16:33:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:34:01 -0800 (PST) Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140Xsg2004777 for ; Thu, 3 Feb 2005 16:33:55 -0800 Received: from dsl.pipex.com (81-178-134-214.dsl.pipex.com [81.178.134.214]) by ranger.systems.pipex.net (Postfix) with ESMTP id 96522E000149; Fri, 4 Feb 2005 00:33:43 +0000 (GMT) Message-ID: <4202C2F2.2050500@dsl.pipex.com> Date: Fri, 04 Feb 2005 00:33:54 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Remus , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <41FEB3AE.3090400@dsl.pipex.com> <1107258578.1095.570.camel@jzny.localdomain> <41FF97E9.7040501@dsl.pipex.com> <1107353106.1098.65.camel@jzny.localdomain> In-Reply-To: <1107353106.1098.65.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev jamal wrote: > On Tue, 2005-02-01 at 09:53, Andy Furniss wrote: > >>jamal wrote: >> >>>I know for a while the Bart howto was mislabeling the meaning of >>>policing - not sure about shaping. >>>Shaping has a precise definition that involves a queue and a >>>non-working-conserving scheduler in order to rate control. This doesnt >>>matter where it happens (egress or ingress). Policing on the other hand >>>is work conserving etc. >> >>Ok, but shaping to LARTC posters means being able to classify traffic >>and set up sharing/priorotising of classes. >> >>This is the reason most need >>to be able to queue - they want to use htb/hfsc for complicated setups > > > Close - but you are missing the rate control requirement. > You can do the above with prio qdisc for example but that does not > equate to shaping. Understood about Lartc users definitions. However, > note that they are influenced by what people tell them or what people > write in docs. Help in making sure the redefinition doesnt propagate. > Theres a very precise meaning to shaping and it is _exactly_ the way i > described it above. Clue people who ask questions. I see your point. > > >>and until now were not aware that it was even possible to replicate this >>in policers > > > I am sure i have written about 50 emails on this topic over the last 5 > years;-> look at the archives. I even joked about it here: > http://www.cyberus.ca/~hadi/patches/action/README over 2 years ago. > look at the text reading "it must be the summer heat again; weve had > someone doing that every year around summer" > Unfortunately people who are writting docs havent picked it up for > whatever reasons. I am hoping we finaly get this documented somewhere. > Can you help fix this? I could write up some what I did type stuff. Once I work out what to do and how to do it :-) > > >>and if it becomes feasable it will probably appear daunting >>to do compared with HTB and all the existing docs/scripts. >> > > >>From a usability perspective i agree with you. > Its still doable is all i can say ;-> (but you are correct in that it > may not be for the weak hearts) > As a reminder of some of the big discussions on shared and hierachical > policing - look at the many many discussions I had with devik on this > topic a few years back. > It resulted in the birth of HTB (which is essentially a hierachy of the > same token bucket meters used in policers; hierachical shared policers > are doable - look at iproute2/examples/diffserv). HTB otoh has proven > useful due to simplicty - so it stands on its own merit now. > I think there may be peculiar occasions where you may need to have > queues to shape traffic to a local app - but thats peculiar. > I'll have to read up abit. > >>For me, I think queuing and dropping is better than just dropping, you >>can affect tcp by delaying eg. 1 ack per packet rather than delayed acks >>and clocking out the packets helps smooth burstiness, > > > True - but i question the usefulness of localy terminating TCP packets > being shaped. For packets being forwarded, the shaping happens on > egress. I know it's a bit odd, but then if I had just one PC I would want to rather than police for reasons below. > > >>which hurts >>latency if you are doing traffic control from the wrong end of the >>bottleneck. >> > > > Not sure i followed the latency connection. I am shaping a relativly slow link from the wrong end. My objective is to avoid the 600ms buffer at ISP/Teleco getting filled as it adds latency for my interactive traffic. If I have a dozen bulk tcp connections running then policing encourages each to send data in bursts at link speed, because delayed acks will pair packets and say a group of four passes without dropping it causes another group of four from that connection at link speed. Add to that the different or variable rtts of the 12 connections it means that there will be times when large bunches of big packets arrive together and delay the interactive traffic. If I shape and dequeue each connection round robin and the aggeragate rate is below link speed then the aggregate flow is smoothed better. If the rates are low enough I will delay longer than delayed ack timers and get one packet per ack aswell. It's still not perfect of course. > > >>As long as I could use netfilter to mark/classify connections then I >>think I can sort my setup, don't know about others. >> >> > > > Great. yes, you can. > > >>>Are pre/post routing sufficient as netfilter hooks for your case? >> >>Yes but depends on where in pre/postrouting. For me after/before nat, as >>I say above though I could workaround if I classify connections with >>netfilter. For others as long as they can filter on a mark/classify set >>in forward, then I think it will be OK for them. >> > > > You can mark in netfilter or even in tc and use those marks in both > places. Great. > > > >>I am not sure what exactly can can't be done in your example: >> >> ># redirect all IP packets arriving in eth0 to dummy0 >> ># use mark 1 --> puts them onto class 1:1 >> >$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ >> >match u32 0 0 flowid 1:1 \ >> >>What I can do here depends where it hooks packets. >> >> >action ipt -j MARK --set-mark 1 \ >> >>I don't know what table I am using - may be OK as long as I can test for >>a mark I made earlier in the egress dummy case or test connmark/state I >>set for that connection in the ingress case. >> > > > That would be doable. Thanks for taking the time Andy. Glad I can help. Andy. > > cheers, > jamal > > From davem@davemloft.net Thu Feb 3 16:42:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:42:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140gSeQ005405 for ; Thu, 3 Feb 2005 16:42:28 -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 1CwrR4-0000KS-00; Thu, 03 Feb 2005 16:34:58 -0800 Date: Thu, 3 Feb 2005 16:34:58 -0800 From: "David S. Miller" To: Herbert Xu , anton@samba.org, anton@au.ibm.com Cc: okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203163458.6282c3fe.davem@davemloft.net> In-Reply-To: <20050203111224.GA3267@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050202162023.075015d4.davem@davemloft.net> <20050203111224.GA3267@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 3 Feb 2005 22:12:24 +1100 Herbert Xu wrote: > This paradigm is repeated throughout the kernel. I bet the > same race can be found in a lot of those places. So we really > need to sit down and audit them one by one or else come up with > a magical solution apart from disabling SMP :) Ok. I'm commenting now considering Anton's atomic_t rules. Anton, please read down below, I think there is a hole in the PPC memory barriers used for atomic ops on SMP. I don't see what changes are needed anywhere given those rules. Olaf says the problem shows up on PPC SMP system, and since Anton knows the proper rules we hopefully can safely assume he implemented them correctly on PPC :-) I thought for a moment that the atomic_read() might be an issue, and I'd really hate to kill that optimization. But I can't see how it is. Let us restate Olaf's original guess as to the problematic sequence of events: cpu 0 cpu 1 skb_get(skb) unlock(neigh) lock(neigh) __skb_unlink(skb) kfree_skb(sb) kfree_skb(skb) First, __skb_unlink(skb) does an unlocked queue unlink, and these memory operations may have their visibility freely reordered by the processor. However, cpu 1 will see the refcount at 2, so it will execute: atomic_dec_and_test(&skb->users) which has the implicit memory barriers, as Anton stated. This means that the cpu will make the __skb_unlink(skb) results visible globally before the decrement. Now the kfree_skb() on cpu 0 executes, the atomic_read() sees it at 1, we do the __kfree_skb() and since the __skb_unlink() has been made visible before the decrement on the count to "1" the BUG() should not trigger in __kfree_skb(). This all assumes, again, that PPC implements these things properly. Let's take a look (Anton, start reading here). My understanding of PPC memory barriers, wrt. the physical memory coherency domain, is as follows: sync ! All previous read/write execute before all subsequent read/write lwsync ! All previous reads execute before all subsequent read/write eieio ! All previous writes execute before all subsequent read/write isync ! All previous memory operations and instructions execute and ! reach global visibility before any subsequent instructions execute What guarentees does isync really make about "read" reordering around the atomic increment? Any descrepencies here would account for the case Olaf observed. All the atomic ops returning values on PPC do this on SMP: eieio atomic_op() isync At a minimum, it seems that the eieio is not strong enough a memory barrier. It is defined to order previous writes against future memory operations, but we also need to strictly order previous reads as well don't we? Also, if my understanding of isync is not correct, that could have implications as well. I guess for performance reasons, ppc doesn't use "sync" both before and after the atomic ops requiring ordering. But I suspect that might be what is actually needed for proper conformity to the atomic_t memory ordering rules. Anton? From jt@hpl.hp.com Thu Feb 3 16:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:53:52 -0800 (PST) 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 j140rl57006511 for ; Thu, 3 Feb 2005 16:53:48 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 41E09100F; Thu, 3 Feb 2005 16:53:47 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA04043; Thu, 3 Feb 2005 16:56:02 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CwrjG-00027v-00; Thu, 03 Feb 2005 16:53:46 -0800 Date: Thu, 3 Feb 2005 16:53:46 -0800 To: Marcelo Tosatti , Stephen Hemminger , Linux kernel mailing list , netdev@oss.sgi.com Subject: [PATCH 2.4] SIOCSIFNAME wildcard support Message-ID: <20050204005346.GA7692@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jt@hpl.hp.com Precedence: bulk X-list: netdev Hi Marcelo, This patch adds wildcard support for the SIOCSIFNAME ioctl, like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to change network interface names (such as nameif, ifrename, or ip link), this patch allow those tools to specify a pattern, such as "eth%d" or "wlan%d", and the kernel use the lowest available slot. The reason I'm sending you this patch is that I've got some 2.4.X users who requested the feature... This patch was initially done for 2.4.23, and I rediffed and retested with 2.4.29. It's somewhat different from the patch Stephen and me added to 2.6.1, because the netdev init code is different and also this patch is more conservative. Have fun... Jean ------------------------------------------------------------- diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c --- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003 +++ linux/net/core/dev.c Wed Dec 3 18:55:27 2003 @@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr, case SIOCSIFNAME: if (dev->flags&IFF_UP) return -EBUSY; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - dev->name[IFNAMSIZ-1] = 0; + /* Check if name contains a wildcard */ + if (strchr(ifr->ifr_newname, '%')) { + char format[IFNAMSIZ + 1]; + int ret; + memcpy(format, ifr->ifr_newname, IFNAMSIZ); + format[IFNAMSIZ-1] = 0; + /* Find a free name based on format. + * dev_alloc_name() replaces "%d" with at max + * 2 digits, so no name overflow. - Jean II */ + ret = dev_alloc_name(dev, format); + if (ret < 0) + return ret; + /* Copy the new name back to caller. */ + strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ); + } else { + if (__dev_get_by_name(ifr->ifr_newname)) + return -EEXIST; + memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); + dev->name[IFNAMSIZ-1] = 0; + } notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); return 0; @@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar * - return a value */ + case SIOCSIFNAME: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) @@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: From davem@davemloft.net Thu Feb 3 16:56:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 16:56:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140uYhi007141 for ; Thu, 3 Feb 2005 16:56:34 -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 1Cwrf0-0000OH-00; Thu, 03 Feb 2005 16:49:22 -0800 Date: Thu, 3 Feb 2005 16:49:22 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203164922.2627a112.davem@davemloft.net> In-Reply-To: <20050203235044.GA8422@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 10:50:44 +1100 Herbert Xu wrote: > So the problem isn't as big as I thought which is good. sk_buff > is only in trouble because of the atomic_read optimisation which > really needs a memory barrier. > > However, instead of adding a memory barrier which makes the optimisation > less useful, let's just get rid of the atomic_read. See my other email, the atomic_read() should function just fine. If we see the count dropped to "1", whoever set it to "1" made sure that all outstanding memory operations (including things like __skb_unlink()) are globally visible before the atomic_dec_and_test() which put the thing to "1" from "2". (and we did use atomic_dec_and_test() since the refcount was not "1") Example, assuming skb->users is "2": cpu 0 cpu 1 __skb_unlink() kfree_skb() kfree_skb() If cpu 0 sees the count at "1", it will always see the __skb_unlink() as well. Either my logic is flawed (very possible, I am a pinhead) or something is amiss in the PPC atomic ops. I describe all of this more explicitly in my other email. I'm actually going through all the sparc64 chip manuals to make sure I have things correct in that implementation :-))) From jt@hpl.hp.com Thu Feb 3 17:08:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:08:13 -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 j14185um009004 for ; Thu, 3 Feb 2005 17:08:05 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 9C99AA848; Thu, 3 Feb 2005 17:07:58 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA04434; Thu, 3 Feb 2005 17:10:14 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Cwrx0-00028Y-00; Thu, 03 Feb 2005 17:07:58 -0800 Date: Thu, 3 Feb 2005 17:07:58 -0800 To: Marcelo Tosatti , Jeff Garzik , Linux kernel mailing list , netdev@oss.sgi.com Subject: [PATCH 2.4] Wireless Extension v17 Message-ID: <20050204010758.GB7692@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jt@hpl.hp.com Precedence: bulk X-list: netdev Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin : * - Fix kernel data leak to user space in private handler handling Have fun... Jean -------------------------------------------------------------------- diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h 2005-02-03 14:54:56.000000000 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.000000000 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.000000000 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.000000000 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * -------------------------------- * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -------------- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * ---------- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ /**************************** CONSTANTS ****************************/ @@ -251,7 +258,7 @@ /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define IW_MODE_SECOND 5 /* Secondary master/repeater (backup) */ #define IW_MODE_MONITOR 6 /* Passive monitor (listen only) */ +/* Statistics flags (bitmask in updated) */ +#define IW_QUAL_QUAL_UPDATED 0x1 /* Value was updated since last read */ +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define IW_QUAL_NOISE_UPDATED 0x4 +#define IW_QUAL_QUAL_INVALID 0x10 /* Driver doesn't provide value */ +#define IW_QUAL_LEVEL_INVALID 0x20 +#define IW_QUAL_NOISE_INVALID 0x40 + +/* Frequency flags */ +#define IW_FREQ_AUTO 0x00 /* Let the driver decides */ +#define IW_FREQ_FIXED 0x01 /* Force a specific value */ + /* Maximum number of size of encoding token available * they are listed in the range structure */ #define IW_MAX_ENCODING_SIZES 8 @@ -390,6 +409,7 @@ #define IW_TXPOW_TYPE 0x00FF /* Type of value */ #define IW_TXPOW_DBM 0x0000 /* Value is in dBm */ #define IW_TXPOW_MWATT 0x0001 /* Value is in mW */ +#define IW_TXPOW_RELATIVE 0x0002 /* Value is in arbitrary units */ #define IW_TXPOW_RANGE 0x1000 /* Range of value between min/max */ /* Retry limits and lifetime flags available */ @@ -418,6 +438,25 @@ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Event capability macros - in (struct iw_range *)->event_capa + * Because we have more than 32 possible events, we use an array of + * 32 bit bitmasks. Note : 32 bits = 0x20 = 2^5. */ +#define IW_EVENT_CAPA_BASE(cmd) ((cmd >= SIOCIWFIRSTPRIV) ? \ + (cmd - SIOCIWFIRSTPRIV + 0x60) : \ + (cmd - SIOCSIWCOMMIT)) +#define IW_EVENT_CAPA_INDEX(cmd) (IW_EVENT_CAPA_BASE(cmd) >> 5) +#define IW_EVENT_CAPA_MASK(cmd) (1 << (IW_EVENT_CAPA_BASE(cmd) & 0x1F)) +/* Event capability constants - event autogenerated by the kernel + * This list is valid for most 802.11 devices, customise as needed... */ +#define IW_EVENT_CAPA_K_0 (IW_EVENT_CAPA_MASK(0x8B04) | \ + IW_EVENT_CAPA_MASK(0x8B06) | \ + IW_EVENT_CAPA_MASK(0x8B1A)) +#define IW_EVENT_CAPA_K_1 (IW_EVENT_CAPA_MASK(0x8B2A)) +/* "Easy" macro to set events in iw_range (less efficient) */ +#define IW_EVENT_CAPA_SET(event_capa, cmd) (event_capa[IW_EVENT_CAPA_INDEX(cmd)] |= IW_EVENT_CAPA_MASK(cmd)) +#define IW_EVENT_CAPA_SET_KERNEL(event_capa) {event_capa[0] |= IW_EVENT_CAPA_K_0; event_capa[1] |= IW_EVENT_CAPA_K_1; } + + /****************************** TYPES ******************************/ /* --------------------------- SUBTYPES --------------------------- */ @@ -456,7 +495,7 @@ struct iw_freq __s32 m; /* Mantissa */ __s16 e; /* Exponent */ __u8 i; /* List index (when in range struct) */ - __u8 pad; /* Unused - just for alignement */ + __u8 flags; /* Flags (fixed/auto) */ }; /* @@ -610,11 +649,12 @@ struct iw_range /* Old Frequency (backward compat - moved lower ) */ __u16 old_num_channels; __u8 old_num_frequency; - /* Filler to keep "version" at the same offset */ - __s32 old_freq[6]; + + /* Wireless event capability bitmasks */ + __u32 event_capa[6]; /* signal level threshold range */ - __s32 sensitivity; + __s32 sensitivity; /* Quality of link & SNR stuff */ /* Quality range (link, level, noise) diff -u -p linux/include/net/iw_handler.we16.h linux/include/net/iw_handler.h --- linux/include/net/iw_handler.we16.h 2005-02-03 14:55:26.000000000 -0800 +++ linux/include/net/iw_handler.h 2005-02-03 15:47:04.000000000 -0800 @@ -1,10 +1,10 @@ /* * This file define the new driver API for Wireless Extensions * - * Version : 5 4.12.02 + * Version : 6 21.6.04 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 2001-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 2001-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _IW_HANDLER_H @@ -206,7 +206,7 @@ * will be needed... * I just plan to increment with each new version. */ -#define IW_HANDLER_VERSION 5 +#define IW_HANDLER_VERSION 6 /* * Changes : @@ -224,11 +224,18 @@ * V4 to V5 * -------- * - Add new spy support : struct iw_spy_data & prototypes + * + * V5 to V6 + * -------- + * - Change the way we get to spy_data method for added safety + * - Remove spy #ifdef, they are always on -> cleaner code + * - Add IW_DESCR_FLAG_NOMAX flag for very large requests + * - Start migrating get_wireless_stats to struct iw_handler_def */ /**************************** CONSTANTS ****************************/ -/* Enable enhanced spy support. Disable to reduce footprint */ +/* Enhanced spy support available */ #define IW_WIRELESS_SPY #define IW_WIRELESS_THRSPY @@ -258,6 +265,7 @@ #define IW_DESCR_FLAG_EVENT 0x0002 /* Generate an event on SET */ #define IW_DESCR_FLAG_RESTRICT 0x0004 /* GET : request is ROOT only */ /* SET : Omit payload from generated iwevent */ +#define IW_DESCR_FLAG_NOMAX 0x0008 /* GET : no limit on request size */ /* Driver level flags */ #define IW_DESCR_FLAG_WAIT 0x0100 /* Wait for driver event */ @@ -311,23 +319,25 @@ struct iw_handler_def /* Array of handlers for standard ioctls * We will call dev->wireless_handlers->standard[ioctl - SIOCSIWNAME] */ - iw_handler * standard; + const iw_handler * standard; /* Array of handlers for private ioctls * Will call dev->wireless_handlers->private[ioctl - SIOCIWFIRSTPRIV] */ - iw_handler * private; + const iw_handler * private; /* Arguments of private handler. This one is just a list, so you * can put it in any order you want and should not leave holes... * We will automatically export that to user space... */ - struct iw_priv_args * private_args; + const struct iw_priv_args * private_args; - /* Driver enhanced spy support */ - long spy_offset; /* Spy data offset */ + /* This field will be *removed* in the next version of WE */ + long spy_offset; /* DO NOT USE */ - /* In the long term, get_wireless_stats will move from - * 'struct net_device' to here, to minimise bloat. */ + /* New location of get_wireless_stats, to de-bloat struct net_device. + * The old pointer in struct net_device will be gradually phased + * out, and drivers are encouraged to use this one... */ + struct iw_statistics* (*get_wireless_stats)(struct net_device *dev); }; /* ---------------------- IOCTL DESCRIPTION ---------------------- */ @@ -374,18 +384,29 @@ struct iw_ioctl_description */ struct iw_spy_data { -#ifdef IW_WIRELESS_SPY /* --- Standard spy support --- */ int spy_number; u_char spy_address[IW_MAX_SPY][ETH_ALEN]; struct iw_quality spy_stat[IW_MAX_SPY]; -#ifdef IW_WIRELESS_THRSPY /* --- Enhanced spy support (event) */ struct iw_quality spy_thr_low; /* Low threshold */ struct iw_quality spy_thr_high; /* High threshold */ u_char spy_thr_under[IW_MAX_SPY]; -#endif /* IW_WIRELESS_THRSPY */ -#endif /* IW_WIRELESS_SPY */ +}; + +/* --------------------- DEVICE WIRELESS DATA --------------------- */ +/* + * This is all the wireless data specific to a device instance that + * is managed by the core of Wireless Extensions. + * We only keep pointer to those structures, so that a driver is free + * to share them between instances. + * This structure should be initialised before registering the device. + * Access to this data follow the same rules as any other struct net_device + * data (i.e. valid as long as struct net_device exist, same locking rules). + */ +struct iw_public_data { + /* Driver enhanced spy support */ + struct iw_spy_data * spy_data; }; /**************************** PROTOTYPES ****************************/ diff -u -p linux/net/core/dev.we16.c linux/net/core/dev.c --- linux/net/core/dev.we16.c 2005-02-03 14:55:56.000000000 -0800 +++ linux/net/core/dev.c 2005-02-03 15:28:48.000000000 -0800 @@ -2426,7 +2426,7 @@ int dev_ioctl(unsigned int cmd, void *ar /* Follow me in net/core/wireless.c */ ret = wireless_process_ioctl(&ifr, cmd); rtnl_unlock(); - if (!ret && IW_IS_GET(cmd) && + if (IW_IS_GET(cmd) && copy_to_user(arg, &ifr, sizeof(struct ifreq))) return -EFAULT; return ret; diff -u -p linux/net/core/wireless.we16.c linux/net/core/wireless.c --- linux/net/core/wireless.we16.c 2005-02-03 14:56:09.000000000 -0800 +++ linux/net/core/wireless.c 2005-02-03 16:33:22.000000000 -0800 @@ -2,7 +2,7 @@ * This file implement the Wireless Extensions APIs. * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2003 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. * * (As all part of the Linux kernel, this file is GPL) */ @@ -48,6 +48,16 @@ * o Add common spy support : iw_handler_set_spy(), wireless_spy_update() * o Add enhanced spy support : iw_handler_set_thrspy() and event. * o Add WIRELESS_EXT version display in /proc/net/wireless + * + * v6 - 18.06.04 - Jean II + * o Change get_spydata() method for added safety + * o Remove spy #ifdef, they are always on -> cleaner code + * o Allow any size GET request if user specifies length > max + * and if request has IW_DESCR_FLAG_NOMAX flag or is SIOCGIWPRIV + * o Start migrating get_wireless_stats to struct iw_handler_def + * o Add wmb() in iw_handler_set_spy() for non-coherent archs/cpus + * Based on patch from Pavel Roskin : + * o Fix kernel data leak to user space in private handler handling */ /***************************** INCLUDES *****************************/ @@ -64,11 +74,7 @@ /**************************** CONSTANTS ****************************/ -/* Enough lenience, let's make sure things are proper... */ -#define WE_STRICT_WRITE /* Check write buffer size */ -/* I'll probably drop both the define and kernel message in the next version */ - -/* Debuging stuff */ +/* Debugging stuff */ #undef WE_IOCTL_DEBUG /* Debug IOCTL API */ #undef WE_EVENT_DEBUG /* Debug Event dispatcher */ #undef WE_SPY_DEBUG /* Debug enhanced spy support */ @@ -134,11 +140,11 @@ static const struct iw_ioctl_description /* -- hole -- */ { IW_HEADER_TYPE_NULL, 0, 0, 0, 0, 0}, /* SIOCGIWAPLIST */ - { IW_HEADER_TYPE_POINT, 0, (sizeof(struct sockaddr) + sizeof(struct iw_quality)), 0, IW_MAX_AP, 0}, + { IW_HEADER_TYPE_POINT, 0, (sizeof(struct sockaddr) + sizeof(struct iw_quality)), 0, IW_MAX_AP, IW_DESCR_FLAG_NOMAX}, /* SIOCSIWSCAN */ { IW_HEADER_TYPE_PARAM, 0, 0, 0, 0, 0}, /* SIOCGIWSCAN */ - { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_SCAN_MAX_DATA, 0}, + { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_SCAN_MAX_DATA, IW_DESCR_FLAG_NOMAX}, /* SIOCSIWESSID */ { IW_HEADER_TYPE_POINT, 0, 1, 0, IW_ESSID_MAX_SIZE + 1, IW_DESCR_FLAG_EVENT}, /* SIOCGIWESSID */ @@ -203,7 +209,7 @@ static const int standard_event_num = (s sizeof(struct iw_ioctl_description)); /* Size (in bytes) of the various private data types */ -static const char priv_type_size[] = { +static const char iw_priv_type_size[] = { 0, /* IW_PRIV_TYPE_NONE */ 1, /* IW_PRIV_TYPE_BYTE */ 1, /* IW_PRIV_TYPE_CHAR */ @@ -270,12 +276,15 @@ static inline iw_handler get_handler(str */ static inline struct iw_statistics *get_wireless_stats(struct net_device *dev) { + /* New location */ + if((dev->wireless_handlers != NULL) && + (dev->wireless_handlers->get_wireless_stats != NULL)) + return dev->wireless_handlers->get_wireless_stats(dev); + + /* Old location, will be phased out in next WE */ return (dev->get_wireless_stats ? dev->get_wireless_stats(dev) : (struct iw_statistics *) NULL); - /* In the future, get_wireless_stats may move from 'struct net_device' - * to 'struct iw_handler_def', to de-bloat struct net_device. - * Definitely worse a thought... */ } /* ---------------------------------------------------------------- */ @@ -310,14 +319,32 @@ static inline int call_commit_handler(st /* ---------------------------------------------------------------- */ /* - * Number of private arguments + * Calculate size of private arguments */ static inline int get_priv_size(__u16 args) { int num = args & IW_PRIV_SIZE_MASK; int type = (args & IW_PRIV_TYPE_MASK) >> 12; - return num * priv_type_size[type]; + return num * iw_priv_type_size[type]; +} + +/* ---------------------------------------------------------------- */ +/* + * Re-calculate the size of private arguments + */ +static inline int adjust_priv_size(__u16 args, + union iwreq_data * wrqu) +{ + int num = wrqu->data.length; + int max = args & IW_PRIV_SIZE_MASK; + int type = (args & IW_PRIV_TYPE_MASK) >> 12; + + /* Make sure the driver doesn't goof up */ + if (max < num) + num = max; + + return num * iw_priv_type_size[type]; } @@ -350,11 +377,14 @@ static inline int sprintf_wireless_stats dev->name, stats->status, stats->qual.qual, - stats->qual.updated & 1 ? '.' : ' ', + stats->qual.updated & IW_QUAL_QUAL_UPDATED + ? '.' : ' ', ((__u8) stats->qual.level), - stats->qual.updated & 2 ? '.' : ' ', + stats->qual.updated & IW_QUAL_LEVEL_UPDATED + ? '.' : ' ', ((__u8) stats->qual.noise), - stats->qual.updated & 4 ? '.' : ' ', + stats->qual.updated & IW_QUAL_NOISE_UPDATED + ? '.' : ' ', stats->discard.nwid, stats->discard.code, stats->discard.fragment, @@ -470,13 +500,15 @@ static inline int ioctl_export_private(s /* Check NULL pointer */ if(iwr->u.data.pointer == NULL) return -EFAULT; -#ifdef WE_STRICT_WRITE + /* Check if there is enough buffer up there */ if(iwr->u.data.length < dev->wireless_handlers->num_private_args) { - printk(KERN_ERR "%s (WE) : Buffer for request SIOCGIWPRIV too small (%d<%d)\n", dev->name, iwr->u.data.length, dev->wireless_handlers->num_private_args); + /* User space can't know in advance how large the buffer + * needs to be. Give it a hint, so that we can support + * any size buffer we want somewhat efficiently... */ + iwr->u.data.length = dev->wireless_handlers->num_private_args; return -E2BIG; } -#endif /* WE_STRICT_WRITE */ /* Set the number of available ioctls. */ iwr->u.data.length = dev->wireless_handlers->num_private_args; @@ -505,7 +537,6 @@ static inline int ioctl_standard_call(st const struct iw_ioctl_description * descr; struct iw_request_info info; int ret = -EINVAL; - int user_size = 0; /* Get the description of the IOCTL */ if((cmd - SIOCIWFIRST) >= standard_ioctl_num) @@ -536,8 +567,14 @@ static inline int ioctl_standard_call(st #endif /* WE_SET_EVENT */ } else { char * extra; + int extra_size; + int user_length = 0; int err; + /* Calculate space needed by arguments. Always allocate + * for max space. Easier, and won't last long... */ + extra_size = descr->max_tokens * descr->token_size; + /* Check what user space is giving us */ if(IW_IS_SET(cmd)) { /* Check NULL pointer */ @@ -554,18 +591,33 @@ static inline int ioctl_standard_call(st if(iwr->u.data.pointer == NULL) return -EFAULT; /* Save user space buffer size for checking */ - user_size = iwr->u.data.length; + user_length = iwr->u.data.length; + + /* Don't check if user_length > max to allow forward + * compatibility. The test user_length < min is + * implied by the test at the end. */ + + /* Support for very large requests */ + if((descr->flags & IW_DESCR_FLAG_NOMAX) && + (user_length > descr->max_tokens)) { + /* Allow userspace to GET more than max so + * we can support any size GET requests. + * There is still a limit : -ENOMEM. */ + extra_size = user_length * descr->token_size; + /* Note : user_length is originally a __u16, + * and token_size is controlled by us, + * so extra_size won't get negative and + * won't overflow... */ + } } #ifdef WE_IOCTL_DEBUG printk(KERN_DEBUG "%s (WE) : Malloc %d bytes\n", - dev->name, descr->max_tokens * descr->token_size); + dev->name, extra_size); #endif /* WE_IOCTL_DEBUG */ - /* Always allocate for max space. Easier, and won't last - * long... */ - extra = kmalloc(descr->max_tokens * descr->token_size, - GFP_KERNEL); + /* Create the kernel buffer */ + extra = kmalloc(extra_size, GFP_KERNEL); if (extra == NULL) { return -ENOMEM; } @@ -591,14 +643,11 @@ static inline int ioctl_standard_call(st /* If we have something to return to the user */ if (!ret && IW_IS_GET(cmd)) { -#ifdef WE_STRICT_WRITE /* Check if there is enough buffer up there */ - if(user_size < iwr->u.data.length) { - printk(KERN_ERR "%s (WE) : Buffer for request %04X too small (%d<%d)\n", dev->name, cmd, user_size, iwr->u.data.length); + if(user_length < iwr->u.data.length) { kfree(extra); return -E2BIG; } -#endif /* WE_STRICT_WRITE */ err = copy_to_user(iwr->u.data.pointer, extra, iwr->u.data.length * @@ -661,7 +710,7 @@ static inline int ioctl_private_call(str iw_handler handler) { struct iwreq * iwr = (struct iwreq *) ifr; - struct iw_priv_args * descr = NULL; + const struct iw_priv_args * descr = NULL; struct iw_request_info info; int extra_size = 0; int i; @@ -701,7 +750,7 @@ static inline int ioctl_private_call(str ((extra_size + offset) <= IFNAMSIZ)) extra_size = 0; } else { - /* Size of set arguments */ + /* Size of get arguments */ extra_size = get_priv_size(descr->get_args); /* Does it fits in iwr ? */ @@ -771,6 +820,14 @@ static inline int ioctl_private_call(str /* If we have something to return to the user */ if (!ret && IW_IS_GET(cmd)) { + + /* Adjust for the actual length if it's variable, + * avoid leaking kernel bits outside. */ + if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) { + extra_size = adjust_priv_size(descr->get_args, + &(iwr->u)); + } + err = copy_to_user(iwr->u.data.pointer, extra, extra_size); if (err) @@ -1042,9 +1099,25 @@ void wireless_send_event(struct net_devi * One of the main advantage of centralising spy support here is that * it becomes much easier to improve and extend it without having to touch * the drivers. One example is the addition of the Spy-Threshold events. - * Note : IW_WIRELESS_SPY is defined in iw_handler.h */ +/* ---------------------------------------------------------------- */ +/* + * Return the pointer to the spy data in the driver. + * Because this is called on the Rx path via wireless_spy_update(), + * we want it to be efficient... + */ +static inline struct iw_spy_data * get_spydata(struct net_device *dev) +{ + /* This is the new way */ + if(dev->wireless_data) + return(dev->wireless_data->spy_data); + + /* This is the old way. Doesn't work for multi-headed drivers. + * It will be removed in the next version of WE. */ + return (dev->priv + dev->wireless_handlers->spy_offset); +} + /*------------------------------------------------------------------*/ /* * Standard Wireless Handler : set Spy List @@ -1054,16 +1127,26 @@ int iw_handler_set_spy(struct net_device union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct sockaddr * address = (struct sockaddr *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Disable spy collection while we copy the addresses. - * As we don't disable interrupts, we need to do this to avoid races. - * As we are the only writer, this is good enough. */ + * While we copy addresses, any call to wireless_spy_update() + * will NOP. This is OK, as anyway the addresses are changing. */ spydata->spy_number = 0; + /* We want to operate without locking, because wireless_spy_update() + * most likely will happen in the interrupt handler, and therefore + * have its own locking constraints and needs performance. + * The rtnl_lock() make sure we don't race with the other iw_handlers. + * This make sure wireless_spy_update() "see" that the spy list + * is temporarily disabled. */ + wmb(); + /* Are there are addresses to copy? */ if(wrqu->data.length > 0) { int i; @@ -1089,13 +1172,14 @@ int iw_handler_set_spy(struct net_device spydata->spy_address[i][5]); #endif /* WE_SPY_DEBUG */ } + + /* Make sure above is updated before re-enabling */ + wmb(); + /* Enable addresses */ spydata->spy_number = wrqu->data.length; return 0; -#else /* IW_WIRELESS_SPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_SPY */ } /*------------------------------------------------------------------*/ @@ -1107,12 +1191,14 @@ int iw_handler_get_spy(struct net_device union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct sockaddr * address = (struct sockaddr *) extra; int i; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + wrqu->data.length = spydata->spy_number; /* Copy addresses. */ @@ -1129,9 +1215,6 @@ int iw_handler_get_spy(struct net_device for(i = 0; i < spydata->spy_number; i++) spydata->spy_stat[i].updated = 0; return 0; -#else /* IW_WIRELESS_SPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_SPY */ } /*------------------------------------------------------------------*/ @@ -1143,11 +1226,13 @@ int iw_handler_set_thrspy(struct net_dev union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_THRSPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct iw_thrspy * threshold = (struct iw_thrspy *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Just do it */ memcpy(&(spydata->spy_thr_low), &(threshold->low), 2 * sizeof(struct iw_quality)); @@ -1160,9 +1245,6 @@ int iw_handler_set_thrspy(struct net_dev #endif /* WE_SPY_DEBUG */ return 0; -#else /* IW_WIRELESS_THRSPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_THRSPY */ } /*------------------------------------------------------------------*/ @@ -1174,22 +1256,20 @@ int iw_handler_get_thrspy(struct net_dev union iwreq_data * wrqu, char * extra) { -#ifdef IW_WIRELESS_THRSPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); struct iw_thrspy * threshold = (struct iw_thrspy *) extra; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return -EOPNOTSUPP; + /* Just do it */ memcpy(&(threshold->low), &(spydata->spy_thr_low), 2 * sizeof(struct iw_quality)); return 0; -#else /* IW_WIRELESS_THRSPY */ - return -EOPNOTSUPP; -#endif /* IW_WIRELESS_THRSPY */ } -#ifdef IW_WIRELESS_THRSPY /*------------------------------------------------------------------*/ /* * Prepare and send a Spy Threshold event @@ -1227,7 +1307,6 @@ static void iw_send_thrspy_event(struct /* Send event to user space */ wireless_send_event(dev, SIOCGIWTHRSPY, &wrqu, (char *) &threshold); } -#endif /* IW_WIRELESS_THRSPY */ /* ---------------------------------------------------------------- */ /* @@ -1240,12 +1319,14 @@ void wireless_spy_update(struct net_devi unsigned char * address, struct iw_quality * wstats) { -#ifdef IW_WIRELESS_SPY - struct iw_spy_data * spydata = (dev->priv + - dev->wireless_handlers->spy_offset); + struct iw_spy_data * spydata = get_spydata(dev); int i; int match = -1; + /* Make sure driver is not buggy or using the old API */ + if(!spydata) + return; + #ifdef WE_SPY_DEBUG printk(KERN_DEBUG "wireless_spy_update() : offset %ld, spydata %p, address %02X:%02X:%02X:%02X:%02X:%02X\n", dev->wireless_handlers->spy_offset, spydata, address[0], address[1], address[2], address[3], address[4], address[5]); #endif /* WE_SPY_DEBUG */ @@ -1257,7 +1338,7 @@ void wireless_spy_update(struct net_devi sizeof(struct iw_quality)); match = i; } -#ifdef IW_WIRELESS_THRSPY + /* Generate an event if we cross the spy threshold. * To avoid event storms, we have a simple hysteresis : we generate * event only when we go under the low threshold or above the @@ -1277,6 +1358,4 @@ void wireless_spy_update(struct net_devi } } } -#endif /* IW_WIRELESS_THRSPY */ -#endif /* IW_WIRELESS_SPY */ } From akpm@osdl.org Thu Feb 3 17:12:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:13:04 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141Cw7a009645 for ; Thu, 3 Feb 2005 17:12:58 -0800 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j141Cql18180; Thu, 3 Feb 2005 17:12:52 -0800 Date: Thu, 3 Feb 2005 17:17:58 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: kernel26@dush.student.utwente.nl Subject: Fw: [Bugme-new] [Bug 4158] New: bridge always takes the mac i don't want Message-Id: <20050203171758.4805879c.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Thu, 3 Feb 2005 16:59:05 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4158] New: bridge always takes the mac i don't want http://bugme.osdl.org/show_bug.cgi?id=4158 Summary: bridge always takes the mac i don't want Kernel Version: 2.4+ Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: kernel26@dush.student.utwente.nl Problem Description: in some situations your bridge needs to take the mac address of one certain interface. in my case the isp checks my mac address. currently it is not possible to choose which mac the bridge takes. i changed the code somewhat to make it possible to choose the mac of the bridge by changing the order in which you add interfaces to the bridge. please consider changing this in the kernel. code: net/bridge/br_stp_if.c:156 if (addr == br_mac_zero || memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0) addr = p->dev->dev_addr; please change it to: if (addr == br_mac_zero) addr = p->dev->dev_addr; ------- 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 Thu Feb 3 17:22:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:22:13 -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 j141M4kH010278 for ; Thu, 3 Feb 2005 17:22:04 -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 1CwsAD-0006Ub-00; Fri, 04 Feb 2005 12:21:37 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cws9W-0002LA-00; Fri, 04 Feb 2005 12:20:54 +1100 Date: Fri, 4 Feb 2005 12:20:53 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204012053.GA8949@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203164922.2627a112.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 04:49:22PM -0800, David S. Miller wrote: > > If we see the count dropped to "1", whoever set it to "1" made > sure that all outstanding memory operations (including things > like __skb_unlink()) are globally visible before the > atomic_dec_and_test() which put the thing to "1" from "2". > (and we did use atomic_dec_and_test() since the refcount was > not "1") Example, assuming skb->users is "2": > > cpu 0 cpu 1 > __skb_unlink() > kfree_skb() > kfree_skb() > > If cpu 0 sees the count at "1", it will always see the > __skb_unlink() as well. This is true if CPU 0 reads the count before reading skb->list. Without a memory barrier, atomic_read and reading skb->list can be reordered. Put it another way, reading skb->list could return a cached value that was read from the main memory prior to the atomic_read. So in order for CPU 0 to always see an up-to-date value of skb->list, it needs to do an smp_rmb() between the atomic_read and reading skb->list. 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 Feb 3 17:31:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:31:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141V8r8010972 for ; Thu, 3 Feb 2005 17:31:09 -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 1CwsCT-0000dy-00; Thu, 03 Feb 2005 17:23:57 -0800 Date: Thu, 3 Feb 2005 17:23:57 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050203172357.670c3402.davem@davemloft.net> In-Reply-To: <20050204012053.GA8949@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 4 Feb 2005 12:20:53 +1100 Herbert Xu wrote: > This is true if CPU 0 reads the count before reading skb->list. > Without a memory barrier, atomic_read and reading skb->list can > be reordered. Put it another way, reading skb->list could return > a cached value that was read from the main memory prior to the > atomic_read. > > So in order for CPU 0 to always see an up-to-date value of skb->list, > it needs to do an smp_rmb() between the atomic_read and reading > skb->list. You're absolutely right. Ok, so we do need to change kfree_skb(). I believe even with the memory barrier, the atomic_read() optimization is still worth it. atomic ops on sparc64 take a minimum of 40 some odd cycles on UltraSPARC-III and later, whereas the memory barrier will take up a single cycle most of the time. So it'll look something like: if (atomic_read(&skb->users) == 1) smb_rmb(); else if (!atomic_dec_and_test(&skb->users)) return; __kfree_skb(skb); From herbert@gondor.apana.org.au Thu Feb 3 17:56:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 17:56:38 -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 j141uSMu012534 for ; Thu, 3 Feb 2005 17:56: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 1Cwsha-0006n0-00; Fri, 04 Feb 2005 12:56:06 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cwsh9-0002XE-00; Fri, 04 Feb 2005 12:55:39 +1100 Date: Fri, 4 Feb 2005 12:55:39 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204015539.GA9727@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20050203172357.670c3402.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 03, 2005 at 05:23:57PM -0800, David S. Miller wrote: > > You're absolutely right. Ok, so we do need to change kfree_skb(). > I believe even with the memory barrier, the atomic_read() optimization > is still worth it. atomic ops on sparc64 take a minimum of 40 some odd > cycles on UltraSPARC-III and later, whereas the memory barrier will > take up a single cycle most of the time. OK, here is the patch to do that. Let's get rid of kfree_skb_fast while we're at it since it's no longer used. 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 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/skbuff.h 1.59 vs edited ===== --- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00 +++ edited/include/linux/skbuff.h 2005-02-04 12:46:15 +11:00 @@ -353,15 +353,11 @@ */ static inline void kfree_skb(struct sk_buff *skb) { - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - __kfree_skb(skb); -} - -/* Use this if you didn't touch the skb state [for fast switching] */ -static inline void kfree_skb_fast(struct sk_buff *skb) -{ - if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) - kfree_skbmem(skb); + if (likely(atomic_read(&skb->users) == 1)) + smp_rmb(); + else if (likely(!atomic_dec_and_test(&skb->users))) + return; + __kfree_skb(skb); } /** --YiEDa0DAkWCtVeE4-- From jgarzik@pobox.com Thu Feb 3 19:06:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 19:06:22 -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 j1436D7j014774 for ; Thu, 3 Feb 2005 19:06:16 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CwtnP-0000iu-Ix; Fri, 04 Feb 2005 03:06:11 +0000 Message-ID: <4202E693.90808@pobox.com> Date: Thu, 03 Feb 2005 22:05:55 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel Mailing List CC: schwidefsky@de.ibm.com, akpm@osdl.org, Netdev Subject: Re: [PATCH] s390: qeth network driver References: <200502040211.j142BI35023854@hera.kernel.org> In-Reply-To: <200502040211.j142BI35023854@hera.kernel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jgarzik@pobox.com Precedence: bulk X-list: netdev Linux Kernel Mailing List wrote: > ChangeSet 1.2072, 2005/02/03 17:04:37-08:00, schwidefsky@de.ibm.com > > [PATCH] s390: qeth network driver > > From: Steffen Thoss > From: Frank Pavlic > > qeth network driver changes: > - Improve performance by omitting svs. > - Use function callback mechanism to set layer 2 parameters when getting > a reply for a Layer 2 command. > - dev->hard_header must not be NULL when fake_ll is no set since > IPv6 and Layer2 needs the default function set by network stack. > - ping6 works now when running in layer 2 mode. > - Save original dev->hard_header to restore it when the user doesn't > want to use fake_ll anymore. > - Fake ethernet header in outgoing packets. This currently works > only if qeth is compiled without ipv6 support. > - Add more debug information in case of failures in qeth_set_offline. > - Using fake_ll with HiperSockets devices results in misaligned > ip packets and thus no traffic over HiperSockets. > - Start qeth_remove_device only after the qeth recovery completed. > > Signed-off-by: Martin Schwidefsky > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds It would be nice if this stuff was CC'd to the network, and network driver maintainers. Two immediate concerns I have are, * saving and restoring dev->hard_header is more than a little bit of a hack * overall, I'm not so sure IPv6 support should be conditionalized on anything but CONFIG_IPV6. Though S/390 and qeth are certainly unusual cases, none of the other net drivers in the kernel require a special config option to enable IPv6 support. Jeff From kaber@trash.net Thu Feb 3 19:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 19:11:02 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j143Av4C015482 for ; Thu, 3 Feb 2005 19:10:58 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cwtry-0000sC-AH; Fri, 04 Feb 2005 04:10:54 +0100 Message-ID: <4202E7BE.6050606@trash.net> Date: Fri, 04 Feb 2005 04:10:54 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [PATCH 2.6.11 PKT_SCHED]: ipt action: add back pskb_expand_head call Content-Type: multipart/mixed; boundary="------------090003050808000303010605" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090003050808000303010605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, Jamal asked me to add back the call to pskb_expand_head before 2.6.11. This fixes a regression caused by my tc action cleanup patches, the tc actions most not replace packets, so it must prevent netfilter from doing so. Regards Patrick --------------090003050808000303010605 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/sched/ipt.c 1.13 vs edited ===== --- 1.13/net/sched/ipt.c 2005-01-14 05:41:07 +01:00 +++ edited/net/sched/ipt.c 2005-02-04 04:06:45 +01:00 @@ -207,6 +207,11 @@ struct tcf_ipt *p = PRIV(a, ipt); struct sk_buff *skb = *pskb; + if (skb_cloned(skb)) { + if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + return TC_ACT_UNSPEC; + } + spin_lock(&p->lock); p->tm.lastuse = jiffies; --------------090003050808000303010605-- From kaber@trash.net Thu Feb 3 20:09:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 20:09:49 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1449gLx017407 for ; Thu, 3 Feb 2005 20:09:43 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cwump-00026q-Al; Fri, 04 Feb 2005 05:09:39 +0100 Message-ID: <4202F583.1040601@trash.net> Date: Fri, 04 Feb 2005 05:09:39 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: Re: [PATCH 2.6.11 PKT_SCHED]: ipt action: add back pskb_expand_head call References: <4202E7BE.6050606@trash.net> In-Reply-To: <4202E7BE.6050606@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: kaber@trash.net Precedence: bulk X-list: netdev Patrick McHardy wrote: > Hi Dave, > > Jamal asked me to add back the call to pskb_expand_head before 2.6.11. > This fixes a regression caused by my tc action cleanup patches, the > tc actions most not replace packets, so it must prevent netfilter from > doing so. I forgot the Signed-off-by line, sorry: Signed-off-by: Patrick McHardy >------------------------------------------------------------------------ > >===== net/sched/ipt.c 1.13 vs edited ===== >--- 1.13/net/sched/ipt.c 2005-01-14 05:41:07 +01:00 >+++ edited/net/sched/ipt.c 2005-02-04 04:06:45 +01:00 >@@ -207,6 +207,11 @@ > struct tcf_ipt *p = PRIV(a, ipt); > struct sk_buff *skb = *pskb; > >+ if (skb_cloned(skb)) { >+ if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) >+ return TC_ACT_UNSPEC; >+ } >+ > spin_lock(&p->lock); > > p->tm.lastuse = jiffies; > > From herbert@gondor.apana.org.au Thu Feb 3 23:33:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Feb 2005 23:34:04 -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 j147XseO025379 for ; Thu, 3 Feb 2005 23:33:55 -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 1CwxyF-0008Np-00; Fri, 04 Feb 2005 18:33:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cwxxn-00033I-00; Fri, 04 Feb 2005 18:33:11 +1100 Date: Fri, 4 Feb 2005 18:33:11 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NET] Add barriers for dst refcnt Message-ID: <20050204073311.GA11716@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: In light of the recent discussion about sk_buff, I think we need the following patch for dst_entry. This adds a memory barrier before dst_release drops the refcnt, and a read memory barrier before dst_destroy starts destroying the entry. 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 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/dst.h 1.24 vs edited ===== --- 1.24/include/net/dst.h 2004-10-26 09:10:25 +10:00 +++ edited/include/net/dst.h 2005-02-04 18:24:46 +11:00 @@ -147,6 +147,7 @@ { if (dst) { WARN_ON(atomic_read(&dst->__refcnt) < 1); + smp_mb__before_atomic_dec(); atomic_dec(&dst->__refcnt); } } ===== net/core/dst.c 1.25 vs edited ===== --- 1.25/net/core/dst.c 2005-01-14 15:41:04 +11:00 +++ edited/net/core/dst.c 2005-02-04 18:26:06 +11:00 @@ -169,6 +169,8 @@ struct neighbour *neigh; struct hh_cache *hh; + smp_rmb(); + again: neigh = dst->neighbour; hh = dst->hh; --OgqxwSJOaUobr8KG-- From linux-netdev@gmane.org Fri Feb 4 01:21:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 01:21:32 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j149LPUE031550 for ; Fri, 4 Feb 2005 01:21:26 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Cwzdj-0002M6-Ra for netdev@oss.sgi.com; Fri, 04 Feb 2005 10:20:35 +0100 Received: from host81-155-183-72.range81-155.btcentralplus.com ([81.155.183.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Feb 2005 10:20:35 +0100 Received: from r.w.hobbs by host81-155-183-72.range81-155.btcentralplus.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Feb 2005 10:20:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Richard Hobbs Subject: [PATCH 4 2.4.27] pcnet32: Add HomePNA parameter for 79C978. Date: Fri, 4 Feb 2005 00:42:07 +0000 (UTC) Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.155.183.72 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: linux-netdev@m.gmane.org X-MailScanner-To: netdev@oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: r.w.hobbs@durham.ac.uk Precedence: bulk X-list: netdev I am trying to set up a hybrid network, part wired, part wireless and part homePNA (the building has some very thick walls and remote computers that can be reached by existing telephone wires). I am using Fedora core 3 with the 2.6.10 kernel. I have checked the pcnet32.c code and the patch 4 2.4.27 appears to be there. I load the pcnet32 module using: modprobe -v pcnet32 homepna=1 I get reply: insmod /lib/modules/2.6.10-1.741_FC3/kernel/drivers/net/pcnet32.ko homepna=1 Looks good. I then try to configure the network through the systems settings interface: eth0 is a e100 ethernet to my router/modem that is OK. Disconnecting eth0 to avoid any conflicts. eth1 should be the AMD79c978 card. Connecting with the telephone wire I set eth1 as an ethernet (I don't see an option for phoneline network) I have tried DHCP get the response on activating the network: Determining IP information for eth1 failed; no link present. Check cable. I have tried a static IP address, card activates but no device is detected at the modem/router. If I unload the module and reload without the homepna option, the card works fine with a standard ethernet cable. Any suggestions please. Thanks Richard Hobbs From okir@suse.de Fri Feb 4 03:17:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 03:17:09 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14BH0RK003887 for ; Fri, 4 Feb 2005 03:17:01 -0800 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 Cantor.suse.de (Postfix) with ESMTP id A492B13E5A9F; Fri, 4 Feb 2005 12:16:54 +0100 (CET) Date: Fri, 4 Feb 2005 12:16:49 +0100 From: Olaf Kirch To: Herbert Xu Cc: "David S. Miller" , anton@samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204111649.GB32678@suse.de> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> <20050204015539.GA9727@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204015539.GA9727@gondor.apana.org.au> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: okir@suse.de Precedence: bulk X-list: netdev On Fri, Feb 04, 2005 at 12:55:39PM +1100, Herbert Xu wrote: > OK, here is the patch to do that. Let's get rid of kfree_skb_fast > while we're at it since it's no longer used. Thanks, I'll give that to the PPC folks and ask the to run with it. Regards, 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 herbert@gondor.apana.org.au Fri Feb 4 03:34:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 03:34:29 -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 j14BYJDc004651 for ; Fri, 4 Feb 2005 03:34:20 -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 1Cx1ia-0001Nm-00; Fri, 04 Feb 2005 22:33:44 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Cx1hx-0003Lu-00; Fri, 04 Feb 2005 22:33:05 +1100 Date: Fri, 4 Feb 2005 22:33:05 +1100 To: "David S. Miller" Cc: Anton Blanchard , okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050204113305.GA12764@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203150821.2321130b.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 03:08:21PM -0800, David S. Miller wrote: > > Ok, here goes nothing. Can someone run with this? It should > be rather complete, and require only minor editorial work. Thanks. It's a very nice piece of work. > A missing memory barrier in the cases where they are required > by the atomic_t implementation above can have disasterous > results. Here is an example, which follows a pattern occuring > frequently in the Linux kernel. It is the use of atomic counters > to implement reference counting, and it works such that once > the counter falls to zero it can be guarenteed that no other > entity can be accessing the object. Observe: > > list_del(&obj->list); > if (atomic_dec_and_test(&obj->ref_count)) > kfree(obj); > > Here, the list (say it is some linked list on which object > searches are performed) creates the reference to the object. > The insertion code probably looks something like this: > > atomic_inc(&obj->ref_count); > list_add(&obj->list, &global_obj_list); I think you should probably note that some sort of locking or RCU scheme is required to make this safe. As it is the atomic_inc and the list_add can be reordered such that the atomic_inc occurs after the atomic_dec_and_test. Either that or you can modify the example to add an smp_mb__after_atomic_inc(). That'd be a good way to demonstrate its use. > And searches look something like: > > for_each(obj, &global_obj_list) { > if (key_compare(obj->key, key)) { > atomic_inc(&obj->ref_count); > return obj; > } > } > return NULL; Locking or RCU is definitely needed here. > the object is still visible for lookup on the linked list. So > we'd get a bogus sequence like this: > > cpu 0 cpu 1 > list_del(&obj->list); > ... visibility delayed ... > lookup and find obj on > global_obj_list The visibility only needs to be delayed up until this point for the crash to occur. > atomic_dec_and_test(); > obj refcount hits zero, this > is visible globally > atomic_inc() > obj refcount incremented > to one > list_del() becomes visible > > kfree(obj); > obj is now freed up memory > --> CRASH > > With the memory barrier semantics required of the atomic_t > operations which return values, the above sequence of memory > visibility can never happen. So this isn't exactly 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 buytenh@wantstofly.org Fri Feb 4 04:06:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 04:06:41 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14C6U18006186 for ; Fri, 4 Feb 2005 04:06:31 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id D20552B0EC; Fri, 4 Feb 2005 13:06:29 +0100 (MET) Date: Fri, 4 Feb 2005 13:06:29 +0100 From: Lennert Buytenhek To: sudeep list Cc: netdev@oss.sgi.com Subject: Re: pointers in the sk_buff structure. Message-ID: <20050204120629.GB12630@xi.wantstofly.org> 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 version 0.81, clamav-milter version 0.81b 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: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Thu, Feb 03, 2005 at 03:45:15PM -0700, sudeep list wrote: > hello, Hi, > I figured that the pointer sk_buff->tail points to the end of data in > the buffer attached to the sk_buff. What does the pointer sk_buff->end > point to ? > > Is there any data that lies between the two pointers, or they are two > pointers to the same address (end of data in the buffer area) ? This is a snippet from some docs on the subject I wrote a while ago, hope it helps. I should polish it up and submit it for inclusion. 2. The sk_buff structure. The sk_buff structure ('skb') is actually only used for storing the metadata corresponding to a packet. The packet's data is not stored inside the sk_buff structure itself, but in a separate buffer that is pointed to by skb->head. The skb->end member points one byte past the end of this data buffer. An important design requirement for sk_buffs is being able to add data at the end as well as at the front of the packet. As a packet travels downwards through the network stack, each layer will usually want to add its own header in front of the packet, and it would be nice if we could avoid reallocating and/or copying the entire data portion of the packet around to make more space at the front of the buffer every time we want to do this. To achieve this goal, the packet data is not necessarily stored at the front of the data buffer, but some space between the front of the buffer and the front of the packet is left unused. skb->data and skb->tail are two extra pointers that point to the beginning and one byte past the end of the currently used portion of the data buffer, respectively. Both are guaranteed to point somewhere within the data buffer. ('skb->head <= skb->data <= skb->tail <= skb->end') +----------+-------------------------------------+--------------+ | headroom | packet data | tailroom | +----------+-------------------------------------+--------------+ ^ ^ skb->data ^ skb->end ^ | | + skb->head + skb->tail The function skb_headroom(skb) calculates 'skb->data - skb->head', and indicates how many bytes we can add to the front of the packet without having to reallocate the buffer. Similarly, skb_tailroom(skb) calculates 'skb->end - skb->tail' and indicates how many bytes we can add to the end of the packet before having to reallocate. Adding data to and removing data from the front of the buffer is done with skb_push and skb_pull, respectively. These wrappers do some sanity checks to make sure the relevant constraints on the four pointers are maintained. When an sk_buff is allocated by alloc_skb, skb->{head,data,tail} are all initialised to point to the start of the data buffer. Depending on what the skb will be used for, the caller will usually want to reserve some headroom in anticipation of expansion of the data buffer towards the front. This is done by calling skb_reserve(). From ak@suse.de Fri Feb 4 06:09:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 06:09:12 -0800 (PST) Received: from Cantor.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14E96bL013598 for ; Fri, 4 Feb 2005 06:09:07 -0800 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 Cantor.suse.de (Postfix) with ESMTP id D290C1408306; Fri, 4 Feb 2005 15:09:00 +0100 (CET) Date: Fri, 4 Feb 2005 15:09:00 +0100 From: Andi Kleen To: netdev@oss.sgi.com Cc: netfilter-devel@lists.netfilter.org Subject: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050204140900.GD2518@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean 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: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 2382 Lines: 73 On kernels compiled with a big NR_CPUS netfilter rules would eat a lot of memory because all counters would be duplicated for all NR_CPUs CPUs. With NR_CPUS=256 this would add up to many MBs of memory. This patch only allocates enough memory for the possible CPUs, which is usually a much smaller number than NR_CPUS. This allows loading of bigger rule sets on 64bit systems. There is still a limit because someone else broke vmalloc to have a 64MB limit on 64bit systems for single allocations, 129MB on 32bit. It allocates an array of pages with kmalloc and kmalloc has a 128K limit. To be fixed with a separate patch. 64bit systems were hurt worst because they tend to have big NR_CPUS and the counters need more memory there, and the vmalloc limit is lower. But it will raise the limits even on 32bit. And in general it saves a lot of memory. Tested only on a small dual CPU box. Signed-off-by: Andi Kleen diff -u linux/net/ipv4/netfilter/ip_tables.c-o linux/net/ipv4/netfilter/ip_tables.c --- linux/net/ipv4/netfilter/ip_tables.c-o 2005-02-04 09:40:12.000000000 +0100 +++ linux/net/ipv4/netfilter/ip_tables.c 2005-02-04 14:26:56.000000000 +0100 @@ -923,7 +923,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -945,7 +945,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -992,7 +992,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1130,7 +1130,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1460,7 +1460,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; From yoshfuji@linux-ipv6.org Fri Feb 4 08:55:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 08:55:50 -0800 (PST) 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 j14GtfpS024268 for ; Fri, 4 Feb 2005 08:55:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 7B87233CC2; Sat, 5 Feb 2005 01:56:39 +0900 (JST) Date: Sat, 05 Feb 2005 01:56:33 +0900 (JST) Message-Id: <20050205.015633.45798306.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPV6]: Fix tunnel list locking in ip6_tunnel.c. 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 727 Lines: 27 Hello. We need to fix tunnel list locking in ip6_tunnel.c as well. Noticed by jean-mickael guerin . Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/ip6_tunnel.c 1.27 vs edited ===== --- 1.27/net/ipv6/ip6_tunnel.c 2005-01-14 13:41:06 +09:00 +++ edited/net/ipv6/ip6_tunnel.c 2005-02-05 01:50:53 +09:00 @@ -180,10 +180,10 @@ { struct ip6_tnl **tp = ip6ip6_bucket(&t->parms); - write_lock_bh(&ip6ip6_lock); t->next = *tp; - write_unlock_bh(&ip6ip6_lock); + write_lock_bh(&ip6ip6_lock); *tp = t; + write_unlock_bh(&ip6ip6_lock); } /** -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From serue@us.ibm.com Fri Feb 4 08:58:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 08:58:57 -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 j14GwqMD025047 for ; Fri, 4 Feb 2005 08:58:52 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j14GweH5360968 for ; Fri, 4 Feb 2005 11:58:40 -0500 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 j14Gweev457458 for ; Fri, 4 Feb 2005 09:58:40 -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 j14GwdXe005968 for ; Fri, 4 Feb 2005 09:58:40 -0700 Received: from IBM-BWN8ZTBWAO1.austin.ibm.com (IBM-BWN8ZTBWAO1.austin.ibm.com [9.41.223.195]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j14GwcaX005926; Fri, 4 Feb 2005 09:58:39 -0700 Received: by IBM-BWN8ZTBWAO1.austin.ibm.com (sSMTP sendmail emulation); Fri, 4 Feb 2005 10:58:40 -0600 Date: Fri, 4 Feb 2005 10:58:40 -0600 From: "Serge E. Hallyn" To: netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Cc: linux-audit@redhat.com Subject: [PATCH] Add audit uid to netlink credentials Message-ID: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.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 version 0.81, clamav-milter version 0.81b 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: serue@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8288 Lines: 223 Most audit control messages are sent over netlink. In order to properly log the identity of the sender of audit control messages, we would like to add the loginuid to the netlink_creds structure, as per the attached patch. thanks, -serge Signed-off-by: Serge Hallyn Index: linux-2.6.10/include/linux/audit.h =================================================================== --- linux-2.6.10.orig/include/linux/audit.h 2005-01-27 10:46:57.887036520 -0600 +++ linux-2.6.10/include/linux/audit.h 2005-01-27 10:51:37.408542792 -0600 @@ -145,7 +145,7 @@ extern void audit_inode(const char *name /* Private API (for audit.c only) */ extern int audit_receive_filter(int type, int pid, int uid, int seq, - void *data); + void *data, uid_t loginuid); extern void audit_get_stamp(struct audit_context *ctx, struct timespec *t, int *serial); extern int audit_set_loginuid(struct audit_context *ctx, uid_t loginuid); @@ -179,10 +179,10 @@ extern void audit_log_d_path(struct const char *prefix, struct dentry *dentry, struct vfsmount *vfsmnt); -extern int audit_set_rate_limit(int limit); -extern int audit_set_backlog_limit(int limit); -extern int audit_set_enabled(int state); -extern int audit_set_failure(int state); +extern int audit_set_rate_limit(int limit, uid_t loginuid); +extern int audit_set_backlog_limit(int limit, uid_t loginuid); +extern int audit_set_enabled(int state, uid_t loginuid); +extern int audit_set_failure(int state, uid_t loginuid); /* Private API (for auditsc.c only) */ extern void audit_send_reply(int pid, int seq, int type, Index: linux-2.6.10/include/linux/netlink.h =================================================================== --- linux-2.6.10.orig/include/linux/netlink.h 2005-01-27 10:46:57.888036368 -0600 +++ linux-2.6.10/include/linux/netlink.h 2005-01-27 10:51:37.409542640 -0600 @@ -110,6 +110,7 @@ struct netlink_skb_parms __u32 dst_pid; __u32 dst_groups; kernel_cap_t eff_cap; + __u32 loginuid; /* Login (audit) uid */ }; #define NETLINK_CB(skb) (*(struct netlink_skb_parms*)&((skb)->cb)) Index: linux-2.6.10/kernel/audit.c =================================================================== --- linux-2.6.10.orig/kernel/audit.c 2005-01-27 10:46:57.888036368 -0600 +++ linux-2.6.10/kernel/audit.c 2005-01-27 10:52:28.753737136 -0600 @@ -236,36 +236,36 @@ void audit_log_lost(const char *message) } -int audit_set_rate_limit(int limit) +int audit_set_rate_limit(int limit, uid_t loginuid) { int old = audit_rate_limit; audit_rate_limit = limit; - audit_log(current->audit_context, "audit_rate_limit=%d old=%d", - audit_rate_limit, old); + audit_log(NULL, "audit_rate_limit=%d old=%d by loginuid %u", + audit_rate_limit, old, loginuid); return old; } -int audit_set_backlog_limit(int limit) +int audit_set_backlog_limit(int limit, uid_t loginuid) { int old = audit_backlog_limit; audit_backlog_limit = limit; - audit_log(current->audit_context, "audit_backlog_limit=%d old=%d", - audit_backlog_limit, old); + audit_log(NULL, "audit_backlog_limit=%d old=%d by loginuid %u", + audit_backlog_limit, old, loginuid); return old; } -int audit_set_enabled(int state) +int audit_set_enabled(int state, uid_t loginuid) { int old = audit_enabled; if (state != 0 && state != 1) return -EINVAL; audit_enabled = state; - audit_log(current->audit_context, "audit_enabled=%d old=%d", - audit_enabled, old); + audit_log(NULL, "audit_enabled=%d old=%d by loginuid %u", + audit_enabled, old, loginuid); return old; } -int audit_set_failure(int state) +int audit_set_failure(int state, uid_t loginuid) { int old = audit_failure; if (state != AUDIT_FAIL_SILENT @@ -273,8 +273,8 @@ int audit_set_failure(int state) && state != AUDIT_FAIL_PANIC) return -EINVAL; audit_failure = state; - audit_log(current->audit_context, "audit_failure=%d old=%d", - audit_failure, old); + audit_log(NULL, "audit_failure=%d old=%d by loginuid %u", + audit_failure, old, loginuid); return old; } @@ -341,6 +341,7 @@ static int audit_receive_msg(struct sk_b int err; struct audit_buffer *ab; u16 msg_type = nlh->nlmsg_type; + uid_t loginuid; /* loginuid of sender */ err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type); if (err) @@ -348,6 +349,7 @@ static int audit_receive_msg(struct sk_b pid = NETLINK_CREDS(skb)->pid; uid = NETLINK_CREDS(skb)->uid; + loginuid = NETLINK_CB(skb).loginuid; seq = nlh->nlmsg_seq; data = NLMSG_DATA(nlh); @@ -368,31 +370,33 @@ static int audit_receive_msg(struct sk_b return -EINVAL; status_get = (struct audit_status *)data; if (status_get->mask & AUDIT_STATUS_ENABLED) { - err = audit_set_enabled(status_get->enabled); + err = audit_set_enabled(status_get->enabled, loginuid); if (err < 0) return err; } if (status_get->mask & AUDIT_STATUS_FAILURE) { - err = audit_set_failure(status_get->failure); + err = audit_set_failure(status_get->failure, loginuid); if (err < 0) return err; } if (status_get->mask & AUDIT_STATUS_PID) { int old = audit_pid; audit_pid = status_get->pid; - audit_log(current->audit_context, - "audit_pid=%d old=%d", audit_pid, old); + audit_log(NULL, "audit_pid=%d old=%d by loginuid %u", + audit_pid, old, loginuid); } if (status_get->mask & AUDIT_STATUS_RATE_LIMIT) - audit_set_rate_limit(status_get->rate_limit); + audit_set_rate_limit(status_get->rate_limit, loginuid); if (status_get->mask & AUDIT_STATUS_BACKLOG_LIMIT) - audit_set_backlog_limit(status_get->backlog_limit); + audit_set_backlog_limit(status_get->backlog_limit, + loginuid); break; case AUDIT_USER: ab = audit_log_start(NULL); if (!ab) break; /* audit_panic has been called */ audit_log_format(ab, - "user pid=%d uid=%d length=%d msg='%.1024s'", - pid, uid, + "user pid=%d uid=%d loginuid=%u length=%d" + " msg='%.1024s'", + pid, uid, loginuid, (int)(nlh->nlmsg_len - ((char *)data - (char *)nlh)), (char *)data); @@ -408,7 +412,7 @@ static int audit_receive_msg(struct sk_b case AUDIT_LIST: #ifdef CONFIG_AUDITSYSCALL err = audit_receive_filter(nlh->nlmsg_type, pid, uid, seq, - data); + data, loginuid); #else err = -EOPNOTSUPP; #endif Index: linux-2.6.10/kernel/auditsc.c =================================================================== --- linux-2.6.10.orig/kernel/auditsc.c 2005-01-27 10:46:57.890036064 -0600 +++ linux-2.6.10/kernel/auditsc.c 2005-01-27 10:52:53.776933032 -0600 @@ -228,7 +228,8 @@ static int audit_copy_rule(struct audit_ return 0; } -int audit_receive_filter(int type, int pid, int uid, int seq, void *data) +int audit_receive_filter(int type, int pid, int uid, int seq, void *data, + uid_t loginuid) { u32 flags; struct audit_entry *entry; @@ -263,6 +264,7 @@ int audit_receive_filter(int type, int p err = audit_add_rule(entry, &audit_entlist); if (!err && (flags & AUDIT_AT_EXIT)) err = audit_add_rule(entry, &audit_extlist); + audit_log(NULL, "loginuid %u added an audit rule\n", loginuid); break; case AUDIT_DEL: flags =((struct audit_rule *)data)->flags; @@ -272,6 +274,8 @@ int audit_receive_filter(int type, int p err = audit_del_rule(data, &audit_entlist); if (!err && (flags & AUDIT_AT_EXIT)) err = audit_del_rule(data, &audit_extlist); + audit_log(NULL, "loginuid %u removed an audit rule\n", + loginuid); break; default: return -EINVAL; Index: linux-2.6.10/net/netlink/af_netlink.c =================================================================== --- linux-2.6.10.orig/net/netlink/af_netlink.c 2005-01-27 10:46:57.891035912 -0600 +++ linux-2.6.10/net/netlink/af_netlink.c 2005-01-27 10:51:37.411542336 -0600 @@ -928,6 +928,7 @@ static int netlink_sendmsg(struct kiocb NETLINK_CB(skb).groups = nlk->groups; NETLINK_CB(skb).dst_pid = dst_pid; NETLINK_CB(skb).dst_groups = dst_groups; + NETLINK_CB(skb).loginuid = audit_get_loginuid(current->audit_context); memcpy(NETLINK_CREDS(skb), &siocb->scm->creds, sizeof(struct ucred)); /* What can I do? Netlink is asynchronous, so that From gandalf@wlug.westbo.se Fri Feb 4 09:34:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 09:34:54 -0800 (PST) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14HYnZ5027467 for ; Fri, 4 Feb 2005 09:34:49 -0800 Received: by null.rsn.bth.se (Postfix, from userid 65534) id CF8402C000E; Fri, 4 Feb 2005 18:34:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 731802C008D; Fri, 4 Feb 2005 18:34:44 +0100 (CET) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id B15D22C000E; Fri, 4 Feb 2005 18:34:43 +0100 (CET) Received: by tux.rsn.bth.se (Postfix, from userid 501) id B0B493F3F; Fri, 4 Feb 2005 18:34:43 +0100 (CET) Subject: Re: [PATCH] Reduce netfilter memory use on MP systems From: Martin Josefsson To: Patrick McHardy Cc: Andi Kleen , netdev@oss.sgi.com, Netfilter-devel In-Reply-To: <20050204140900.GD2518@wotan.suse.de> References: <20050204140900.GD2518@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-A0J9aMmekRjWTUo18QHr" Date: Fri, 04 Feb 2005 18:34:42 +0100 Message-Id: <1107538482.1111.6.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 on null.rsn.bth.se 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: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 1636 Lines: 47 --=-A0J9aMmekRjWTUo18QHr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 15:09 +0100, Andi Kleen wrote: > On kernels compiled with a big NR_CPUS netfilter rules would=20 > eat a lot of memory because all counters would be duplicated > for all NR_CPUs CPUs. With NR_CPUS=3D256 this would add up > to many MBs of memory. >=20 > This patch only allocates enough memory for the possible CPUs, > which is usually a much smaller number than NR_CPUS. >=20 > This allows loading of bigger rule sets on 64bit systems. > There is still a limit because someone else broke vmalloc to have a 64MB=20 > limit on 64bit systems for single allocations, 129MB on 32bit. > It allocates an array of pages with kmalloc and kmalloc has a 128K limit.= =20 > To be fixed with a separate patch. >=20 > 64bit systems were hurt worst because they tend to have big NR_CPUS > and the counters need more memory there, and the vmalloc limit is lower. > But it will raise the limits even on 32bit.=20 >=20 > And in general it saves a lot of memory. Patrick, could you apply and submit this patch to Davem? Or if Davem applies it himself. It's pretty obvious and would help small SMP machines with distribution kernels and/or strange admins. --=20 /Martin --=-A0J9aMmekRjWTUo18QHr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA7IyWm2vlfa207ERApm/AJ9LEA2DHbXBJhRewpcgZ95JWtcw5QCgsq+v wbiXYM5H1VpufxryKV8ufZU= =GMMw -----END PGP SIGNATURE----- --=-A0J9aMmekRjWTUo18QHr-- From ak@suse.de Fri Feb 4 09:51:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 09:51:44 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14HpexM028307 for ; Fri, 4 Feb 2005 09:51:41 -0800 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 Cantor.suse.de (Postfix) with ESMTP id E6E15140AAC9; Fri, 4 Feb 2005 18:51:34 +0100 (CET) Date: Fri, 4 Feb 2005 18:51:34 +0100 From: Andi Kleen To: Martin Josefsson Cc: Patrick McHardy , Andi Kleen , netdev@oss.sgi.com, Netfilter-devel Subject: Re: [PATCH] Reduce netfilter memory use on MP systems Message-ID: <20050204175134.GD2737@wotan.suse.de> References: <20050204140900.GD2518@wotan.suse.de> <1107538482.1111.6.camel@tux.rsn.bth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107538482.1111.6.camel@tux.rsn.bth.se> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 575 Lines: 13 > > And in general it saves a lot of memory. > > Patrick, could you apply and submit this patch to Davem? Or if Davem > applies it himself. It's pretty obvious and would help small SMP > machines with distribution kernels and/or strange admins. The main motivation is actually not to save the memory (that's just a useful side effect), but increase the max limit on 64bit systems. Fixing it fully will require fixing vmalloc of course, but it already help. Without it you can't get more than ~3800 rules on a 64bit system with NR_CPUS==128 and 128 byte cache lines. -Andi From chas@cmf.nrl.navy.mil Fri Feb 4 10:11:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:12:04 -0800 (PST) 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 j14IBv4H029337 for ; Fri, 4 Feb 2005 10:11:57 -0800 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 j14IBOna020338; Fri, 4 Feb 2005 13:11:27 -0500 (EST) Message-Id: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> To: Roman Kagan cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-Reply-To: Message from Roman Kagan of "Fri, 21 Jan 2005 11:51:23 +0300." <20050121085123.GA2471@katya> Date: Fri, 04 Feb 2005 13:11:25 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1273 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: 9944 Lines: 383 In message <20050121085123.GA2471@katya>,Roman Kagan writes: >The patch is against 2.6.10. Please comment. i guess i would prefer that entries be named typeN, like he0 instead of just a number. you were printing 7 octets for the address. if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the kfree. i added some other fields that i think are interesting. comments? # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/04 13:05:34-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/atm_sysfs.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +181 -0 # # net/atm/resources.h # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +3 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/resources.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +22 -6 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/atm_sysfs.c # 2005/02/04 13:05:17-05:00 chas@relax.cmf.nrl.navy.mil +0 -0 # BitKeeper file /scratch/chas/LATEST/2.6/net/atm/atm_sysfs.c # # net/atm/common.h # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +2 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/common.c # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +6 -1 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # net/atm/Makefile # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # # include/linux/atmdev.h # 2005/02/04 13:05:16-05:00 chas@relax.cmf.nrl.navy.mil +2 -0 # [ATM]: basic sysfs support for ATM devices (from Roman Kagan ) # diff -Nru a/include/linux/atmdev.h b/include/linux/atmdev.h --- a/include/linux/atmdev.h 2005-02-04 13:06:48 -05:00 +++ b/include/linux/atmdev.h 2005-02-04 13:06:48 -05:00 @@ -8,6 +8,7 @@ #include +#include #include #include #include @@ -345,6 +346,7 @@ struct proc_dir_entry *proc_entry; /* proc entry */ char *proc_name; /* proc entry name */ #endif + struct class_device class_dev; /* sysfs class device */ struct list_head dev_list; /* linkage */ }; diff -Nru a/net/atm/Makefile b/net/atm/Makefile --- a/net/atm/Makefile 2005-02-04 13:06:48 -05:00 +++ b/net/atm/Makefile 2005-02-04 13:06:48 -05:00 @@ -2,7 +2,7 @@ # Makefile for the ATM Protocol Families. # -atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o +atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o atm_sysfs.o mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o obj-$(CONFIG_ATM) += atm.o diff -Nru a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/atm/atm_sysfs.c 2005-02-04 13:06:48 -05:00 @@ -0,0 +1,181 @@ +/* ATM driver model support. */ + +#include +#include +#include +#include +#include +#include "common.h" +#include "resources.h" + +#define to_atm_dev(cldev) container_of(cldev, struct atm_dev, class_dev) + +static ssize_t show_type(struct class_device *cdev, char *buf) +{ + struct atm_dev *adev = to_atm_dev(cdev); + return sprintf(buf, "%s\n", adev->type); +} + +static ssize_t show_address(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + int i; + + for (i = 0; i < (ESI_LEN - 1); i++) + pos += sprintf(pos, "%02x:", adev->esi[i]); + pos += sprintf(pos, "%02x\n", adev->esi[i]); + + return pos - buf; +} + +static ssize_t show_atmaddress(struct class_device *cdev, char *buf) +{ + unsigned long flags; + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + struct atm_dev_addr *aaddr; + int bin[] = { 1, 2, 10, 6, 1 }, *fmt = bin; + int i, j; + + spin_lock_irqsave(&adev->lock, flags); + list_for_each_entry(aaddr, &adev->local, entry) { + for(i = 0, j = 0; i < ATM_ESA_LEN; ++i, ++j) { + if (j == *fmt) { + pos += sprintf(pos, "."); + ++fmt; + j = 0; + } + pos += sprintf(pos, "%02x", aaddr->addr.sas_addr.prv[i]); + } + pos += sprintf(pos, "\n"); + } + spin_unlock_irqrestore(&adev->lock, flags); + + return pos - buf; +} + +static ssize_t show_carrier(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + + pos += sprintf(pos, "%d\n", + adev->signal == ATM_PHY_SIG_LOST ? 0 : 1); + + return pos - buf; +} + +static ssize_t show_link_rate(struct class_device *cdev, char *buf) +{ + char *pos = buf; + struct atm_dev *adev = to_atm_dev(cdev); + int link_rate; + + /* show the link rate, not the data rate */ + switch (adev->link_rate) { + case ATM_OC3_PCR: + link_rate = 155520000; + break; + case ATM_OC12_PCR: + link_rate = 622080000; + break; + case ATM_25_PCR: + link_rate = 25600000; + break; + default: + link_rate = adev->link_rate * 8 * 53; + } + pos += sprintf(pos, "%d\n", link_rate); + + return pos - buf; +} + +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); +static CLASS_DEVICE_ATTR(atmaddress, S_IRUGO, show_atmaddress, NULL); +static CLASS_DEVICE_ATTR(carrier, S_IRUGO, show_carrier, NULL); +static CLASS_DEVICE_ATTR(type, S_IRUGO, show_type, NULL); +static CLASS_DEVICE_ATTR(link_rate, S_IRUGO, show_link_rate, NULL); + +static struct class_device_attribute *atm_attrs[] = { + &class_device_attr_atmaddress, + &class_device_attr_address, + &class_device_attr_carrier, + &class_device_attr_type, + &class_device_attr_link_rate, + NULL +}; + +#ifdef CONFIG_HOTPLUG +static int atm_hotplug(struct class_device *cdev, char **envp, int num_envp, char *buf, int size) +{ + struct atm_dev *adev; + int i = 0; + int length = 0; + + if (!cdev) + return -ENODEV; + + adev = to_atm_dev(cdev); + if (!adev) + return -ENODEV; + + if (add_hotplug_env_var(envp, num_envp, &i, buf, size, &length, + "INTERFACE=%s%d", adev->type, adev->number)) + return -ENOMEM; + + envp[i] = NULL; + return 0; +} +#endif + +static void atm_release(struct class_device *cdev) +{ + struct atm_dev *adev = to_atm_dev(cdev); + + kfree(adev); +} + +static struct class atm_class = { + .name = "atm", + .release = atm_release, +#ifdef CONFIG_HOTPLUG + .hotplug = atm_hotplug, +#endif +}; + +int atm_register_sysfs(struct atm_dev *adev) +{ + struct class_device *cdev = &adev->class_dev; + int i, err; + + cdev->class = &atm_class; + class_set_devdata(cdev, adev); + + snprintf(cdev->class_id, BUS_ID_SIZE, "%s%d", adev->type, adev->number); + err = class_device_register(cdev); + if (err < 0) + return err; + + for (i = 0; atm_attrs[i]; i++) + class_device_create_file(cdev, atm_attrs[i]); + + return 0; +} + +void atm_unregister_sysfs(struct atm_dev *adev) +{ + struct class_device *cdev = &adev->class_dev; + + class_device_del(cdev); +} + +int __init atm_sysfs_init(void) +{ + return class_register(&atm_class); +} + +void __exit atm_sysfs_exit(void) +{ + class_unregister(&atm_class); +} diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c 2005-02-04 13:06:48 -05:00 +++ b/net/atm/common.c 2005-02-04 13:06:48 -05:00 @@ -793,6 +793,10 @@ printk(KERN_ERR "atm_proc_init() failed with %d\n",error); goto failure; } + if ((error = atm_sysfs_init()) < 0) { + printk(KERN_ERR "atm_sysfs_init() failed with %d\n",error); + goto failure; + } return 0; failure: @@ -804,11 +808,12 @@ static void __exit atm_exit(void) { atm_proc_exit(); + atm_sysfs_exit(); atmsvc_exit(); atmpvc_exit(); } -module_init(atm_init); +subsys_initcall(atm_init); module_exit(atm_exit); MODULE_LICENSE("GPL"); diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h 2005-02-04 13:06:48 -05:00 +++ b/net/atm/common.h 2005-02-04 13:06:48 -05:00 @@ -28,6 +28,8 @@ void atmpvc_exit(void); int atmsvc_init(void); void atmsvc_exit(void); +int atm_sysfs_init(void); +void atm_sysfs_exit(void); #ifdef CONFIG_PROC_FS int atm_proc_init(void); diff -Nru a/net/atm/resources.c b/net/atm/resources.c --- a/net/atm/resources.c 2005-02-04 13:06:48 -05:00 +++ b/net/atm/resources.c 2005-02-04 13:06:48 -05:00 @@ -47,7 +47,11 @@ static void __free_atm_dev(struct atm_dev *dev) { +#ifdef CONFIG_SYSFS + class_device_put(&dev->class_dev); +#else kfree(dev); +#endif } static struct atm_dev *__atm_dev_lookup(int number) @@ -91,7 +95,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; @@ -117,14 +121,25 @@ printk(KERN_ERR "atm_dev_register: " "atm_proc_dev_register failed for dev %s\n", type); - spin_lock(&atm_dev_lock); - list_del(&dev->dev_list); - spin_unlock(&atm_dev_lock); - __free_atm_dev(dev); - return NULL; + goto reg_fail; + } + + if (atm_register_sysfs(dev) < 0) { + printk(KERN_ERR "atm_dev_register: " + "atm_register_sysfs failed for dev %s\n", + type); + atm_proc_dev_deregister(dev); + goto reg_fail; } return dev; + +reg_fail: + spin_lock(&atm_dev_lock); + list_del(&dev->dev_list); + spin_unlock(&atm_dev_lock); + kfree(dev); + return NULL; } @@ -132,6 +147,7 @@ { unsigned long warning_time; + atm_unregister_sysfs(dev); atm_proc_dev_deregister(dev); spin_lock(&atm_dev_lock); diff -Nru a/net/atm/resources.h b/net/atm/resources.h --- a/net/atm/resources.h 2005-02-04 13:06:48 -05:00 +++ b/net/atm/resources.h 2005-02-04 13:06:48 -05:00 @@ -43,4 +43,7 @@ #endif /* CONFIG_PROC_FS */ +int atm_register_sysfs(struct atm_dev *adev); +void atm_unregister_sysfs(struct atm_dev *adev); + #endif From kaber@trash.net Fri Feb 4 10:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:13:42 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IDb6g029677 for ; Fri, 4 Feb 2005 10:13:38 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.43) id 1Cx7xW-0004Sz-JM; Fri, 04 Feb 2005 19:13:34 +0100 Message-ID: <4203BB4E.3070908@trash.net> Date: Fri, 04 Feb 2005 19:13:34 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Martin Josefsson , netdev@oss.sgi.com, Netfilter-devel Subject: Re: [PATCH] Reduce netfilter memory use on MP systems References: <20050204140900.GD2518@wotan.suse.de> <1107538482.1111.6.camel@tux.rsn.bth.se> <20050204175134.GD2737@wotan.suse.de> In-Reply-To: <20050204175134.GD2737@wotan.suse.de> Content-Type: multipart/mixed; boundary="------------000409090703040601060603" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 6217 Lines: 195 This is a multi-part message in MIME format. --------------000409090703040601060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: >The main motivation is actually not to save the memory (that's just >a useful side effect), but increase the max limit on 64bit systems. >Fixing it fully will require fixing vmalloc of course, but it already >help. Without it you can't get more than ~3800 rules >on a 64bit system with NR_CPUS==128 and 128 byte cache lines. > Thanks Andi, I've added the patch to my 2.6.12 tree. I've also made the same change in arp_tables, ip6_tables and ebtables for consistency. Regards Patrick --------------000409090703040601060603 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/bridge/netfilter/ebtables.c 1.17 vs edited ===== --- 1.17/net/bridge/netfilter/ebtables.c 2004-11-24 08:46:46 +01:00 +++ edited/net/bridge/netfilter/ebtables.c 2005-02-04 19:03:01 +01:00 @@ -822,10 +822,10 @@ /* this will get free'd in do_replace()/ebt_register_table() if an error occurs */ newinfo->chainstack = (struct ebt_chainstack **) - vmalloc(NR_CPUS * sizeof(struct ebt_chainstack)); + vmalloc(num_possible_cpus() * sizeof(struct ebt_chainstack)); if (!newinfo->chainstack) return -ENOMEM; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { newinfo->chainstack[i] = vmalloc(udc_cnt * sizeof(struct ebt_chainstack)); if (!newinfo->chainstack[i]) { @@ -898,7 +898,7 @@ memcpy(counters, oldcounters, sizeof(struct ebt_counter) * nentries); /* add other counters to those of cpu 0 */ - for (cpu = 1; cpu < NR_CPUS; cpu++) { + for (cpu = 1; cpu < num_possible_cpus(); cpu++) { counter_base = COUNTER_BASE(oldcounters, nentries, cpu); for (i = 0; i < nentries; i++) { counters[i].pcnt += counter_base[i].pcnt; @@ -930,7 +930,7 @@ BUGPRINT("Entries_size never zero\n"); return -EINVAL; } - countersize = COUNTER_OFFSET(tmp.nentries) * NR_CPUS; + countersize = COUNTER_OFFSET(tmp.nentries) * num_possible_cpus(); newinfo = (struct ebt_table_info *) vmalloc(sizeof(struct ebt_table_info) + countersize); if (!newinfo) @@ -1023,7 +1023,7 @@ vfree(table->entries); if (table->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(table->chainstack[i]); vfree(table->chainstack); } @@ -1043,7 +1043,7 @@ vfree(counterstmp); /* can be initialized in translate_table() */ if (newinfo->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(newinfo->chainstack[i]); vfree(newinfo->chainstack); } @@ -1137,7 +1137,7 @@ return -EINVAL; } - countersize = COUNTER_OFFSET(table->table->nentries) * NR_CPUS; + countersize = COUNTER_OFFSET(table->table->nentries) * num_possible_cpus(); newinfo = (struct ebt_table_info *) vmalloc(sizeof(struct ebt_table_info) + countersize); ret = -ENOMEM; @@ -1191,7 +1191,7 @@ up(&ebt_mutex); free_chainstack: if (newinfo->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(newinfo->chainstack[i]); vfree(newinfo->chainstack); } @@ -1215,7 +1215,7 @@ if (table->private->entries) vfree(table->private->entries); if (table->private->chainstack) { - for (i = 0; i < NR_CPUS; i++) + for (i = 0; i < num_possible_cpus(); i++) vfree(table->private->chainstack[i]); vfree(table->private->chainstack); } ===== net/ipv4/netfilter/arp_tables.c 1.23 vs edited ===== --- 1.23/net/ipv4/netfilter/arp_tables.c 2005-01-11 03:45:54 +01:00 +++ edited/net/ipv4/netfilter/arp_tables.c 2005-02-04 19:01:20 +01:00 @@ -717,7 +717,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -768,7 +768,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; ARPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -886,7 +886,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct arpt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1159,7 +1159,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct arpt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) { ret = -ENOMEM; return ret; ===== net/ipv6/netfilter/ip6_tables.c 1.39 vs edited ===== --- 1.39/net/ipv6/netfilter/ip6_tables.c 2005-01-11 03:45:54 +01:00 +++ edited/net/ipv6/netfilter/ip6_tables.c 2005-02-04 19:01:55 +01:00 @@ -952,7 +952,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -974,7 +974,7 @@ struct ip6t_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -1021,7 +1021,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IP6T_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1155,7 +1155,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ip6t_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1469,7 +1469,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ip6t_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; --------------000409090703040601060603-- From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:23:17 -0800 (PST) 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 j14INDmE030392 for ; Fri, 4 Feb 2005 10:23:14 -0800 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 j14IN6RU020651; Fri, 4 Feb 2005 13:23:06 -0500 (EST) Message-Id: <200502041823.j14IN6RU020651@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1 of 3][ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() Date: Fri, 04 Feb 2005 13:23:07 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1275 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: 1765 Lines: 50 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 11:38:49-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/horizon.c # 2005/02/03 11:38:31-05:00 chas@relax.cmf.nrl.navy.mil +6 -7 # [ATM]: [horizon] replace interruptible_sleep_on() with wait_event_interruptible() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/horizon.c b/drivers/atm/horizon.c --- a/drivers/atm/horizon.c 2005-02-03 12:17:39 -05:00 +++ b/drivers/atm/horizon.c 2005-02-03 12:17:39 -05:00 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include @@ -1089,13 +1090,11 @@ /********** (queue to) become the next TX thread **********/ static inline int tx_hold (hrz_dev * dev) { - while (test_and_set_bit (tx_busy, &dev->flags)) { - PRINTD (DBG_TX, "sleeping at tx lock %p %lu", dev, dev->flags); - interruptible_sleep_on (&dev->tx_queue); - PRINTD (DBG_TX, "woken at tx lock %p %lu", dev, dev->flags); - if (signal_pending (current)) - return -1; - } + PRINTD (DBG_TX, "sleeping at tx lock %p %lu", dev, dev->flags); + wait_event_interruptible(dev->tx_queue, (!test_and_set_bit(tx_busy, &dev->flags))); + PRINTD (DBG_TX, "woken at tx lock %p %lu", dev, dev->flags); + if (signal_pending (current)) + return -1; PRINTD (DBG_TX, "set tx_busy for dev %p", dev); return 0; } From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:24:03 -0800 (PST) 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 j14INwC3030763 for ; Fri, 4 Feb 2005 10:23:58 -0800 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 j14INqY4020685; Fri, 4 Feb 2005 13:23:52 -0500 (EST) Message-Id: <200502041823.j14INqY4020685@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 3 of 3][ATM]: [zatm] replace sleep_on() with wait_event() Date: Fri, 04 Feb 2005 13:23:53 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1277 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: 2049 Lines: 72 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 12:05:12-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [zatm] replace sleep_on() with wait_event() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/zatm.c # 2005/02/03 12:04:54-05:00 chas@relax.cmf.nrl.navy.mil +10 -19 # [ATM]: [zatm] replace sleep_on() with wait_event() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c 2005-02-03 12:18:33 -05:00 +++ b/drivers/atm/zatm.c 2005-02-03 12:18:33 -05:00 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -867,31 +868,21 @@ struct zatm_vcc *zatm_vcc; unsigned long flags; int chan; -struct sk_buff *skb; -int once = 1; zatm_vcc = ZATM_VCC(vcc); zatm_dev = ZATM_DEV(vcc->dev); chan = zatm_vcc->tx_chan; if (!chan) return; DPRINTK("close_tx\n"); - while (skb_peek(&zatm_vcc->backlog)) { -if (once) { -printk("waiting for backlog to drain ...\n"); -event_dump(); -once = 0; -} - sleep_on(&zatm_vcc->tx_wait); - } -once = 1; - while ((skb = skb_peek(&zatm_vcc->tx_queue))) { -if (once) { -printk("waiting for TX queue to drain ... %p\n",skb); -event_dump(); -once = 0; -} - DPRINTK("waiting for TX queue to drain ... %p\n",skb); - sleep_on(&zatm_vcc->tx_wait); + if (skb_peek(&zatm_vcc->backlog)) { + printk("waiting for backlog to drain ...\n"); + event_dump(); + wait_event(zatm_vcc->tx_wait, !skb_peek(&zatm_vcc->backlog)); + } + if (skb_peek(&zatm_vcc->tx_queue)) { + printk("waiting for TX queue to drain ...\n"); + event_dump(); + wait_event(zatm_vcc->tx_wait, !skb_peek(&zatm_vcc->tx_queue)); } spin_lock_irqsave(&zatm_dev->lock, flags); #if 0 From chas@cmf.nrl.navy.mil Fri Feb 4 10:23:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:23:45 -0800 (PST) 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 j14INfBV030533 for ; Fri, 4 Feb 2005 10:23:41 -0800 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 j14INXtL020671; Fri, 4 Feb 2005 13:23:33 -0500 (EST) Message-Id: <200502041823.j14INXtL020671@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 2 of 3][ATM]: [iphase] remove sleep_on*() usage Date: Fri, 04 Feb 2005 13:23:34 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1276 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: 3033 Lines: 83 please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/03 11:28:25-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [iphase] remove sleep_on*() usage # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/iphase.c # 2005/02/03 11:26:35-05:00 chas@relax.cmf.nrl.navy.mil +12 -14 # [ATM]: [iphase] remove sleep_on*() usage # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/iphase.c b/drivers/atm/iphase.c --- a/drivers/atm/iphase.c 2005-02-03 12:17:19 -05:00 +++ b/drivers/atm/iphase.c 2005-02-03 12:17:19 -05:00 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include #include @@ -2586,14 +2587,14 @@ } static void ia_close(struct atm_vcc *vcc) -{ +{ + DEFINE_WAIT(wait); u16 *vc_table; IADEV *iadev; struct ia_vcc *ia_vcc; struct sk_buff *skb = NULL; struct sk_buff_head tmp_tx_backlog, tmp_vcc_backlog; unsigned long closetime, flags; - int ctimeout; iadev = INPH_IA_DEV(vcc->dev); ia_vcc = INPH_IA_VCC(vcc); @@ -2606,7 +2607,9 @@ skb_queue_head_init (&tmp_vcc_backlog); if (vcc->qos.txtp.traffic_class != ATM_NONE) { iadev->close_pending++; - sleep_on_timeout(&iadev->timeout_wait, 50); + prepare_to_wait(&iadev->timeout_wait, &wait, TASK_UNINTERRUPTIBLE); + schedule_timeout(50); + finish_wait(&iadev->timeout_wait, &wait); spin_lock_irqsave(&iadev->tx_lock, flags); while((skb = skb_dequeue(&iadev->tx_backlog))) { if (ATM_SKB(skb)->vcc == vcc){ @@ -2619,17 +2622,12 @@ while((skb = skb_dequeue(&tmp_tx_backlog))) skb_queue_tail(&iadev->tx_backlog, skb); IF_EVENT(printk("IA TX Done decs_cnt = %d\n", ia_vcc->vc_desc_cnt);) - closetime = jiffies; - ctimeout = 300000 / ia_vcc->pcr; - if (ctimeout == 0) - ctimeout = 1; - while (ia_vcc->vc_desc_cnt > 0){ - if ((jiffies - closetime) >= ctimeout) - break; - spin_unlock_irqrestore(&iadev->tx_lock, flags); - sleep_on(&iadev->close_wait); - spin_lock_irqsave(&iadev->tx_lock, flags); - } + closetime = 300000 / ia_vcc->pcr; + if (closetime == 0) + closetime = 1; + spin_unlock_irqrestore(&iadev->tx_lock, flags); + wait_event_timeout(iadev->close_wait, (ia_vcc->vc_desc_cnt <= 0), closetime); + spin_lock_irqsave(&iadev->tx_lock, flags); iadev->close_pending--; iadev->testTable[vcc->vci]->lastTime = 0; iadev->testTable[vcc->vci]->fract = 0; From castet.matthieu@free.fr Fri Feb 4 10:27:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:27:15 -0800 (PST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14IRAQm031840 for ; Fri, 4 Feb 2005 10:27:11 -0800 Received: from [82.67.62.65] (mutualite-1-82-67-62-65.fbx.proxad.net [82.67.62.65]) by postfix3-1.free.fr (Postfix) with ESMTP id BD7D31734FB; Fri, 4 Feb 2005 19:27:07 +0100 (CET) Message-ID: <4203BE7B.2030503@free.fr> Date: Fri, 04 Feb 2005 19:27:07 +0100 From: matthieu castet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: fr-fr, en, en-us MIME-Version: 1.0 To: chas williams - CONTRACTOR Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) References: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> In-Reply-To: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: castet.matthieu@free.fr Precedence: bulk X-list: netdev Content-Length: 856 Lines: 36 Hi, chas williams - CONTRACTOR wrote: > In message <20050121085123.GA2471@katya>,Roman Kagan writes: > >>The patch is against 2.6.10. Please comment. > > > i guess i would prefer that entries be named typeN, like he0 > instead of just a number. > > you were printing 7 octets for the address. > > if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the > kfree. > > i added some other fields that i think are interesting. > > comments? > > + > +static ssize_t show_carrier(struct class_device *cdev, char *buf) > +{ > + char *pos = buf; > + struct atm_dev *adev = to_atm_dev(cdev); > + > + pos += sprintf(pos, "%d\n", > + adev->signal == ATM_PHY_SIG_LOST ? 0 : 1); > + > + return pos - buf; > +} Shouldn't adev->signal == ATM_PHY_SIG_FOUND ? 1 : 0); be better : in the case of ATM_PHY_SIG_UNKNOWN, it return 1... Matthieu From brazilnut@us.ibm.com Fri Feb 4 10:45:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:45:53 -0800 (PST) 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 j14IjfVq032620 for ; Fri, 4 Feb 2005 10:45:48 -0800 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 j14IjaZ7428462 for ; Fri, 4 Feb 2005 13:45:36 -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 j14IjZBC307584 for ; Fri, 4 Feb 2005 11:45:35 -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 j14IjZmo006042 for ; Fri, 4 Feb 2005 11:45:35 -0700 Received: from DYN319661.beaverton.ibm.com (DYN319661.beaverton.ibm.com [9.47.22.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j14IjZiQ006030; Fri, 4 Feb 2005 11:45:35 -0700 Received: by DYN319661.beaverton.ibm.com (Postfix, from userid 1000) id 0BEED229AFD; Fri, 4 Feb 2005 10:45:32 -0800 (PST) Date: Fri, 4 Feb 2005 10:45:31 -0800 From: Don Fry To: Richard Hobbs Cc: netdev@oss.sgi.com Subject: Re: [PATCH 4 2.4.27] pcnet32: Add HomePNA parameter for 79C978. Message-ID: <20050204184531.GA15595@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2092 Lines: 62 Richard, 2.6.10 has the driver to support the 79c978 card in homepna mode. I have only used the card in a point-to-point configuration when in homepna mode, because all I have is two cards (no modem/router). When you bring up the card with homepna=1, if you look in /var/log/messages it should indicate the speed at which the card is operating. In my system I see: pcnet32: media set to 1Mbit mode. pcnet32: PCnet/Home 79C978 at 0x252c00, 00 90 00 05 dd 27 assigned IRQ 201. eth8: registered as PCnet/Home 79C978 pcnet32: 8 cards_found. With the cards cabled together I see link detected using ethtool. # ethtool eth8 Settings for eth8: Current message level: 0x00000007 (7) Link detected: yes On Fri, Feb 04, 2005 at 12:42:07AM +0000, Richard Hobbs wrote: > > I am trying to set up a hybrid network, part wired, part wireless and part > homePNA (the building has some very thick walls and remote computers that can be > reached by existing telephone wires). I am using Fedora core 3 with the 2.6.10 > kernel. I have checked the pcnet32.c code and the patch 4 2.4.27 appears to be > there. > > I load the pcnet32 module using: > modprobe -v pcnet32 homepna=1 > > I get reply: > insmod /lib/modules/2.6.10-1.741_FC3/kernel/drivers/net/pcnet32.ko homepna=1 > > Looks good. > > I then try to configure the network through the systems settings interface: > eth0 is a e100 ethernet to my router/modem that is OK. > Disconnecting eth0 to avoid any conflicts. > > eth1 should be the AMD79c978 card. Connecting with the telephone wire > > I set eth1 as an ethernet (I don't see an option for phoneline network) > I have tried DHCP get the response on activating the network: > Determining IP information for eth1 failed; no link present. Check cable. > > I have tried a static IP address, card activates but no device is detected at > the modem/router. > > If I unload the module and reload without the homepna option, the card works > fine with a standard ethernet cable. > > Any suggestions please. > > Thanks > Richard Hobbs -- Don Fry brazilnut@us.ibm.com From jketreno@linux.intel.com Fri Feb 4 10:48:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:48:21 -0800 (PST) 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 j14Im28h000673 for ; Fri, 4 Feb 2005 10:48:03 -0800 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 j14Ilvtr024069 for ; Fri, 4 Feb 2005 18:47:57 GMT Received: from [192.168.1.154] (hdlrvguser-315.hd.intel.com [10.127.53.78]) 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 j14Ilbv0022747 for ; Fri, 4 Feb 2005 18:47:42 GMT Message-ID: <4203C32A.70402@linux.intel.com> Date: Fri, 04 Feb 2005 12:47:06 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH] ieee80211 subsystem X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040601040104090008060909" X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 147314 Lines: 5008 This is a multi-part message in MIME format. --------------040601040104090008060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 subsystem used by the ipw2100 and ipw2200 projects. I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that use thist stack to the list on Monday. In terms of what the stack currently does: * HW independent -- it only knows about 802.11 data and structures * Performs an 802.3 <-> 802.11 transform for data Tx/Rx * Host based support for fragmentation, WEP, and WPA using the kernel's crypto functions * Beacon and probe response collection and parsing * Default implementation of some of the WE handlers that can be managed without hardware knowledge We are working to merge in Dave Miller's p80211 code into the ieee80211 subsystem so that it hooks into the kernel as a true network layer as opposed to a mutated offspring of ethernet. Once that is done, hopefully the skb to txb code can be reworked and 802.11 fragments can be treated either as normal skbs, or skbs can be modified to directly support them (ideally so that encrypted 802.11 frames in support of IP packets can be cached by the stack instead of having to be re-encrypted on TCP retries) Support for HW/FW crypto and fragmentation offload, in a HW independent fashion, is also on the short-term list. When you look through the patch you'll likely notice the #ifdef NOTYET/#endif sequences surrounding portions of code from the hostap project. Portions of this subsystem were based on an earlier version of the hostap project. Those areas that weren't directly supported by the ipw* projects weren't ported to be completely hardware independent (since I don't have the hardware to test it), and so are still wrapped in the ifdefs. These sections mainly cover support for MASTER and WDS modes. Anyway, please let me know what you think. Hopefully I built the patch right... Thanks, James --------------040601040104090008060909 Content-Type: text/x-patch; name="netdev-2.6-ieee80211.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdev-2.6-ieee80211.patch" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/Kconfig netdev-2.6-ipw/drivers/net/wireless/Kconfig --- netdev-2.6/drivers/net/wireless/Kconfig 2005-02-04 10:10:44 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/Kconfig 2005-02-04 10:20:02 -06:00 @@ -28,6 +28,8 @@ special kernel support are available from . +source "drivers/net/wireless/ieee80211/Kconfig" + # Note : the cards are obsolete (can't buy them anymore), but the drivers # are not, as people are still using them... comment "Obsolete Wireless cards support (pre-802.11)" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/Kconfig netdev-2.6-ipw/drivers/net/wireless/ieee80211/Kconfig --- netdev-2.6/drivers/net/wireless/ieee80211/Kconfig 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/Kconfig 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,72 @@ +config IEEE80211 + tristate "Generic IEEE 802.11 Networking Stack" + depends on NET_RADIO + +config IEEE80211_DEBUG + bool "Enable full debugging output" + depends on IEEE80211 + ---help--- + This option will enable debug tracing output for the + ieee80211 network stack. + + This will result in the kernel module being ~70k larger. You + can control which debug output is sent to the kernel log by + setting the value in + + /proc/net/ieee80211/debug_level + + For example: + + % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level + + For a list of values you can assign to debug_level, simply + perform: + + % . idvals + + From within drivers/net/wireless/ipw2200 + + If you are not trying to debug or develop the IPW2200 driver, + you + most likely want to say N here. + +config IEEE80211_CRYPT + tristate "IEEE 802.11 encryption" + depends on IEEE80211 + select CRYPTO + select CRYPTO_ARC4 + select CRC32 + ---help--- + Software implementation of IEEE 802.11 encryption. This module + adds WEP support, and the baseline capabilities required for + WPA. + + This can be compiled as a modules and it will be called + "ieee80211_crypt.ko". + +config IEEE80211_WPA + tristate "IEEE 802.11 WPA" + depends on IEEE80211_CRYPT + ---help--- + Software implementation of IEEE 802.11 WPA. You will need + to select the WPA algorithms you wish to use. + +config IEEE80211_CRYPT_CCMP + tristate "IEEE 802.11 CCMP encryption" + depends on IEEE80211_WPA + select CRYPTO_AES_586 + ---help--- + Software implementation of IEEE 802.11 CCMP encryption. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_ccmp.ko". + +config IEEE80211_CRYPT_TKIP + tristate "IEEE 802.11 TKIP encryption" + depends on IEEE80211_WPA + select CRYPTO_MICHAEL_MIC + ---help--- + Software implementation of IEEE 802.11 TKIP encryption. + + This can be compiled as a modules and it will be called + "ieee80211_crypt_tkip.ko". diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/Makefile netdev-2.6-ipw/drivers/net/wireless/ieee80211/Makefile --- netdev-2.6/drivers/net/wireless/ieee80211/Makefile 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/Makefile 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,11 @@ +obj-$(CONFIG_IEEE80211) += ieee80211.o +obj-$(CONFIG_IEEE80211_CRYPT) += ieee80211_crypt.o +obj-$(CONFIG_IEEE80211_CRYPT) += ieee80211_crypt_wep.o +obj-$(CONFIG_IEEE80211_CRYPT_WPA) += ieee80211_crypt_ccmp.o +obj-$(CONFIG_IEEE80211_CRYPT_WPA) += ieee80211_crypt_tkip.o +ieee80211-objs := \ + ieee80211_module.o \ + ieee80211_tx.o \ + ieee80211_rx.o \ + ieee80211_wx.o + diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,253 @@ +/* + * Host AP crypto routines + * + * Copyright (c) 2002-2003, Jouni Malinen + * Portions Copyright (C) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("HostAP crypto"); +MODULE_LICENSE("GPL"); + +struct ieee80211_crypto_alg { + struct list_head list; + struct ieee80211_crypto_ops *ops; +}; + + +struct ieee80211_crypto { + struct list_head algs; + spinlock_t lock; +}; + +static struct ieee80211_crypto *hcrypt; + +void ieee80211_crypt_deinit_entries(struct ieee80211_device *ieee, + int force) +{ + struct list_head *ptr, *n; + struct ieee80211_crypt_data *entry; + + for (ptr = ieee->crypt_deinit_list.next, n = ptr->next; + ptr != &ieee->crypt_deinit_list; ptr = n, n = ptr->next) { + entry = list_entry(ptr, struct ieee80211_crypt_data, list); + + if (atomic_read(&entry->refcnt) != 0 && !force) + continue; + + list_del(ptr); + + if (entry->ops) { + entry->ops->deinit(entry->priv); + module_put(entry->ops->owner); + } + kfree(entry); + } +} + +void ieee80211_crypt_deinit_handler(unsigned long data) +{ + struct ieee80211_device *ieee = (struct ieee80211_device *)data; + unsigned long flags; + + spin_lock_irqsave(&ieee->lock, flags); + ieee80211_crypt_deinit_entries(ieee, 0); + if (!list_empty(&ieee->crypt_deinit_list)) { + printk(KERN_DEBUG "%s: entries remaining in delayed crypt " + "deletion list\n", ieee->dev->name); + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); + +} + +void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee, + struct ieee80211_crypt_data **crypt) +{ + struct ieee80211_crypt_data *tmp; + unsigned long flags; + + if (*crypt == NULL) + return; + + tmp = *crypt; + *crypt = NULL; + + /* must not run ops->deinit() while there may be pending encrypt or + * decrypt operations. Use a list of delayed deinits to avoid needing + * locking. */ + + spin_lock_irqsave(&ieee->lock, flags); + list_add(&tmp->list, &ieee->crypt_deinit_list); + if (!timer_pending(&ieee->crypt_deinit_timer)) { + ieee->crypt_deinit_timer.expires = jiffies + HZ; + add_timer(&ieee->crypt_deinit_timer); + } + spin_unlock_irqrestore(&ieee->lock, flags); +} + +int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct ieee80211_crypto_alg *alg; + + if (hcrypt == NULL) + return -1; + + alg = kmalloc(sizeof(*alg), GFP_KERNEL); + if (alg == NULL) + return -ENOMEM; + + memset(alg, 0, sizeof(*alg)); + alg->ops = ops; + + spin_lock_irqsave(&hcrypt->lock, flags); + list_add(&alg->list, &hcrypt->algs); + spin_unlock_irqrestore(&hcrypt->lock, flags); + + printk(KERN_DEBUG "ieee80211_crypt: registered algorithm '%s'\n", + ops->name); + + return 0; +} + +int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *del_alg = NULL; + + if (hcrypt == NULL) + return -1; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (alg->ops == ops) { + list_del(&alg->list); + del_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (del_alg) { + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s'\n", ops->name); + kfree(del_alg); + } + + return del_alg ? 0 : -1; +} + + +struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name) +{ + unsigned long flags; + struct list_head *ptr; + struct ieee80211_crypto_alg *found_alg = NULL; + + if (hcrypt == NULL) + return NULL; + + spin_lock_irqsave(&hcrypt->lock, flags); + for (ptr = hcrypt->algs.next; ptr != &hcrypt->algs; ptr = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + if (strcmp(alg->ops->name, name) == 0) { + found_alg = alg; + break; + } + } + spin_unlock_irqrestore(&hcrypt->lock, flags); + + if (found_alg) + return found_alg->ops; + else + return NULL; +} + + +static void * ieee80211_crypt_null_init(int keyidx) { return (void *) 1; } +static void ieee80211_crypt_null_deinit(void *priv) {} + +static struct ieee80211_crypto_ops ieee80211_crypt_null = { + .name = "NULL", + .init = ieee80211_crypt_null_init, + .deinit = ieee80211_crypt_null_deinit, + .encrypt_mpdu = NULL, + .decrypt_mpdu = NULL, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = NULL, + .get_key = NULL, + .extra_prefix_len = 0, + .extra_postfix_len = 0, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_init(void) +{ + hcrypt = kmalloc(sizeof(*hcrypt), GFP_KERNEL); + if (hcrypt == NULL) + return -ENOMEM; + + memset(hcrypt, 0, sizeof(*hcrypt)); + INIT_LIST_HEAD(&hcrypt->algs); + spin_lock_init(&hcrypt->lock); + + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); + + return 0; +} + + +static void __exit ieee80211_crypto_deinit(void) +{ + struct list_head *ptr, *n; + + if (hcrypt == NULL) + return; + + for (ptr = hcrypt->algs.next, n = ptr->next; ptr != &hcrypt->algs; + ptr = n, n = ptr->next) { + struct ieee80211_crypto_alg *alg = + (struct ieee80211_crypto_alg *) ptr; + list_del(ptr); + printk(KERN_DEBUG "ieee80211_crypt: unregistered algorithm " + "'%s' (deinit)\n", alg->ops->name); + kfree(alg); + } + + kfree(hcrypt); +} + +EXPORT_SYMBOL(ieee80211_crypt_deinit_entries); +EXPORT_SYMBOL(ieee80211_crypt_deinit_handler); +EXPORT_SYMBOL(ieee80211_crypt_delayed_deinit); + +EXPORT_SYMBOL(ieee80211_register_crypto_ops); +EXPORT_SYMBOL(ieee80211_unregister_crypto_ops); +EXPORT_SYMBOL(ieee80211_get_crypto_ops); + +module_init(ieee80211_crypto_init); +module_exit(ieee80211_crypto_deinit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,477 @@ +/* + * Host AP crypt: host-based CCMP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif + +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: CCMP"); +MODULE_LICENSE("GPL"); + +#define AES_BLOCK_LEN 16 +#define CCMP_HDR_LEN 8 +#define CCMP_MIC_LEN 8 +#define CCMP_TK_LEN 16 +#define CCMP_PN_LEN 6 + +struct ieee80211_ccmp_data { + u8 key[CCMP_TK_LEN]; + int key_set; + + u8 tx_pn[CCMP_PN_LEN]; + u8 rx_pn[CCMP_PN_LEN]; + + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; + + int key_idx; + + struct crypto_tfm *tfm; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN], + tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN]; + u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN]; +}; + +void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm, + const u8 pt[16], u8 ct[16]) +{ + struct scatterlist src, dst; + + src.page = virt_to_page(pt); + src.offset = offset_in_page(pt); + src.length = AES_BLOCK_LEN; + + dst.page = virt_to_page(ct); + dst.offset = offset_in_page(ct); + dst.length = AES_BLOCK_LEN; + + crypto_cipher_encrypt(tfm, &dst, &src, AES_BLOCK_LEN); +} + +static void * ieee80211_ccmp_init(int key_idx) +{ + struct ieee80211_ccmp_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) { + goto fail; + } + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm = crypto_alloc_tfm("aes", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_ccmp: could not allocate " + "crypto API aes\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_ccmp_deinit(void *priv) +{ + struct ieee80211_ccmp_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +static inline void xor_block(u8 *b, u8 *a, size_t len) +{ + int i; + for (i = 0; i < len; i++) + b[i] ^= a[i]; +} + + +static void ccmp_init_blocks(struct crypto_tfm *tfm, + struct ieee80211_hdr *hdr, + u8 *pn, size_t dlen, u8 *b0, u8 *auth, + u8 *s0) +{ + u8 *pos, qc = 0; + size_t aad_len; + u16 fc; + int a4_included, qc_included; + u8 aad[2 * AES_BLOCK_LEN]; + + fc = le16_to_cpu(hdr->frame_ctl); + a4_included = ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)); + qc_included = ((WLAN_FC_GET_TYPE(fc) == IEEE80211_FTYPE_DATA) && + (WLAN_FC_GET_STYPE(fc) & 0x08)); + aad_len = 22; + if (a4_included) + aad_len += 6; + if (qc_included) { + pos = (u8 *) &hdr->addr4; + if (a4_included) + pos += 6; + qc = *pos & 0x0f; + aad_len += 2; + } + + /* CCM Initial Block: + * Flag (Include authentication header, M=3 (8-octet MIC), + * L=1 (2-octet Dlen)) + * Nonce: 0x00 | A2 | PN + * Dlen */ + b0[0] = 0x59; + b0[1] = qc; + memcpy(b0 + 2, hdr->addr2, ETH_ALEN); + memcpy(b0 + 8, pn, CCMP_PN_LEN); + b0[14] = (dlen >> 8) & 0xff; + b0[15] = dlen & 0xff; + + /* AAD: + * FC with bits 4..6 and 11..13 masked to zero; 14 is always one + * A1 | A2 | A3 + * SC with bits 4..15 (seq#) masked to zero + * A4 (if present) + * QC (if present) + */ + pos = (u8 *) hdr; + aad[0] = 0; /* aad_len >> 8 */ + aad[1] = aad_len & 0xff; + aad[2] = pos[0] & 0x8f; + aad[3] = pos[1] & 0xc7; + memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN); + pos = (u8 *) &hdr->seq_ctl; + aad[22] = pos[0] & 0x0f; + aad[23] = 0; /* all bits masked */ + memset(aad + 24, 0, 8); + if (a4_included) + memcpy(aad + 24, hdr->addr4, ETH_ALEN); + if (qc_included) { + aad[a4_included ? 30 : 24] = qc; + /* rest of QC masked */ + } + + /* Start with the first block and AAD */ + ieee80211_ccmp_aes_encrypt(tfm, b0, auth); + xor_block(auth, aad, AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN); + ieee80211_ccmp_aes_encrypt(tfm, auth, auth); + b0[0] &= 0x07; + b0[14] = b0[15] = 0; + ieee80211_ccmp_aes_encrypt(tfm, b0, s0); +} + + +static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + int data_len, i, blocks, last, len; + u8 *pos, *mic; + struct ieee80211_hdr *hdr; + u8 *b0 = key->tx_b0; + u8 *b = key->tx_b; + u8 *e = key->tx_e; + u8 *s0 = key->tx_s0; + + if (skb_headroom(skb) < CCMP_HDR_LEN || + skb_tailroom(skb) < CCMP_MIC_LEN || + skb->len < hdr_len) + return -1; + + data_len = skb->len - hdr_len; + pos = skb_push(skb, CCMP_HDR_LEN); + memmove(pos, pos + CCMP_HDR_LEN, hdr_len); + pos += hdr_len; + mic = skb_put(skb, CCMP_MIC_LEN); + + i = CCMP_PN_LEN - 1; + while (i >= 0) { + key->tx_pn[i]++; + if (key->tx_pn[i] != 0) + break; + i--; + } + + *pos++ = key->tx_pn[5]; + *pos++ = key->tx_pn[4]; + *pos++ = 0; + *pos++ = (key->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = key->tx_pn[3]; + *pos++ = key->tx_pn[2]; + *pos++ = key->tx_pn[1]; + *pos++ = key->tx_pn[0]; + + hdr = (struct ieee80211_hdr *) skb->data; + ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Authentication */ + xor_block(b, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, b, b); + /* Encryption, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, e); + xor_block(pos, e, len); + pos += len; + } + + for (i = 0; i < CCMP_MIC_LEN; i++) + mic[i] = b[i] ^ s0[i]; + + return 0; +} + + +static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_ccmp_data *key = priv; + u8 keyidx, *pos; + struct ieee80211_hdr *hdr; + u8 *b0 = key->rx_b0; + u8 *b = key->rx_b; + u8 *a = key->rx_a; + u8 pn[6]; + int i, blocks, last, len; + size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN; + u8 *mic = skb->data + skb->len - CCMP_MIC_LEN; + + if (skb->len < hdr_len + CCMP_HDR_LEN + CCMP_MIC_LEN) { + key->dot11RSNAStatsCCMPFormatErrors++; + return -1; + } + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPFormatErrors++; + return -2; + } + keyidx >>= 6; + if (key->key_idx != keyidx) { + printk(KERN_DEBUG "CCMP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", key->key_idx, keyidx, priv); + return -6; + } + if (!key->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + + pn[0] = pos[7]; + pn[1] = pos[6]; + pn[2] = pos[5]; + pn[3] = pos[4]; + pn[4] = pos[1]; + pn[5] = pos[0]; + pos += 8; + + if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT + " previous PN %02x%02x%02x%02x%02x%02x " + "received PN %02x%02x%02x%02x%02x%02x\n", + MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn), + MAC_ARG(pn)); + } + key->dot11RSNAStatsCCMPReplays++; + return -4; + } + + ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b); + xor_block(mic, b, CCMP_MIC_LEN); + + blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN; + last = data_len % AES_BLOCK_LEN; + + for (i = 1; i <= blocks; i++) { + len = (i == blocks && last) ? last : AES_BLOCK_LEN; + /* Decrypt, with counter */ + b0[14] = (i >> 8) & 0xff; + b0[15] = i & 0xff; + ieee80211_ccmp_aes_encrypt(key->tfm, b0, b); + xor_block(pos, b, len); + /* Authentication */ + xor_block(a, pos, len); + ieee80211_ccmp_aes_encrypt(key->tfm, a, a); + pos += len; + } + + if (memcmp(mic, a, CCMP_MIC_LEN) != 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "CCMP: decrypt failed: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + key->dot11RSNAStatsCCMPDecryptErrors++; + return -5; + } + + memcpy(key->rx_pn, pn, CCMP_PN_LEN); + + /* Remove hdr and MIC */ + memmove(skb->data + CCMP_HDR_LEN, skb->data, hdr_len); + skb_pull(skb, CCMP_HDR_LEN); + skb_trim(skb, skb->len - CCMP_MIC_LEN); + + return keyidx; +} + + +static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + int keyidx; + struct crypto_tfm *tfm = data->tfm; + + keyidx = data->key_idx; + memset(data, 0, sizeof(*data)); + data->key_idx = keyidx; + data->tfm = tfm; + if (len == CCMP_TK_LEN) { + memcpy(data->key, key, CCMP_TK_LEN); + data->key_set = 1; + if (seq) { + data->rx_pn[0] = seq[5]; + data->rx_pn[1] = seq[4]; + data->rx_pn[2] = seq[3]; + data->rx_pn[3] = seq[2]; + data->rx_pn[4] = seq[1]; + data->rx_pn[5] = seq[0]; + } + crypto_cipher_setkey(data->tfm, data->key, CCMP_TK_LEN); + } else if (len == 0) { + data->key_set = 0; + } else + return -1; + + return 0; +} + + +static int ieee80211_ccmp_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_ccmp_data *data = priv; + + if (len < CCMP_TK_LEN) + return -1; + + if (!data->key_set) + return 0; + memcpy(key, data->key, CCMP_TK_LEN); + + if (seq) { + seq[0] = data->tx_pn[5]; + seq[1] = data->tx_pn[4]; + seq[2] = data->tx_pn[3]; + seq[3] = data->tx_pn[2]; + seq[4] = data->tx_pn[1]; + seq[5] = data->tx_pn[0]; + } + + return CCMP_TK_LEN; +} + + +static char * ieee80211_ccmp_print_stats(char *p, void *priv) +{ + struct ieee80211_ccmp_data *ccmp = priv; + p += sprintf(p, "key[%d] alg=CCMP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "format_errors=%d replays=%d decrypt_errors=%d\n", + ccmp->key_idx, ccmp->key_set, + MAC_ARG(ccmp->tx_pn), MAC_ARG(ccmp->rx_pn), + ccmp->dot11RSNAStatsCCMPFormatErrors, + ccmp->dot11RSNAStatsCCMPReplays, + ccmp->dot11RSNAStatsCCMPDecryptErrors); + + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_ccmp = { + .name = "CCMP", + .init = ieee80211_ccmp_init, + .deinit = ieee80211_ccmp_deinit, + .encrypt_mpdu = ieee80211_ccmp_encrypt, + .decrypt_mpdu = ieee80211_ccmp_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = ieee80211_ccmp_set_key, + .get_key = ieee80211_ccmp_get_key, + .print_stats = ieee80211_ccmp_print_stats, + .extra_prefix_len = CCMP_HDR_LEN, + .extra_postfix_len = CCMP_MIC_LEN, + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_ccmp_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_ccmp) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_ccmp_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_ccmp); +} + + +module_init(ieee80211_crypto_ccmp_init); +module_exit(ieee80211_crypto_ccmp_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,714 @@ +/* + * Host AP crypt: host-based TKIP encryption implementation for Host AP driver + * + * Copyright (c) 2003-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif + +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: TKIP"); +MODULE_LICENSE("GPL"); + +struct ieee80211_tkip_data { +#define TKIP_KEY_LEN 32 + u8 key[TKIP_KEY_LEN]; + int key_set; + + u32 tx_iv32; + u16 tx_iv16; + u16 tx_ttak[5]; + int tx_phase1_done; + + u32 rx_iv32; + u16 rx_iv16; + u16 rx_ttak[5]; + int rx_phase1_done; + u32 rx_iv32_new; + u16 rx_iv16_new; + + u32 dot11RSNAStatsTKIPReplays; + u32 dot11RSNAStatsTKIPICVErrors; + u32 dot11RSNAStatsTKIPLocalMICFailures; + + int key_idx; + + struct crypto_tfm *tfm_arc4; + struct crypto_tfm *tfm_michael; + + /* scratch buffers for virt_to_page() (crypto API) */ + u8 rx_hdr[16], tx_hdr[16]; +}; + +static void * ieee80211_tkip_init(int key_idx) +{ + struct ieee80211_tkip_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = key_idx; + + priv->tfm_arc4 = crypto_alloc_tfm("arc4", 0); + if (priv->tfm_arc4 == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + priv->tfm_michael = crypto_alloc_tfm("michael_mic", 0); + if (priv->tfm_michael == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate " + "crypto API michael_mic\n"); + goto fail; + } + + return priv; + +fail: + if (priv) { + if (priv->tfm_michael) + crypto_free_tfm(priv->tfm_michael); + if (priv->tfm_arc4) + crypto_free_tfm(priv->tfm_arc4); + kfree(priv); + } + + return NULL; +} + + +static void ieee80211_tkip_deinit(void *priv) +{ + struct ieee80211_tkip_data *_priv = priv; + if (_priv && _priv->tfm_michael) + crypto_free_tfm(_priv->tfm_michael); + if (_priv && _priv->tfm_arc4) + crypto_free_tfm(_priv->tfm_arc4); + kfree(priv); +} + + +static inline u16 RotR1(u16 val) +{ + return (val >> 1) | (val << 15); +} + + +static inline u8 Lo8(u16 val) +{ + return val & 0xff; +} + + +static inline u8 Hi8(u16 val) +{ + return val >> 8; +} + + +static inline u16 Lo16(u32 val) +{ + return val & 0xffff; +} + + +static inline u16 Hi16(u32 val) +{ + return val >> 16; +} + + +static inline u16 Mk16(u8 hi, u8 lo) +{ + return lo | (((u16) hi) << 8); +} + + +static inline u16 Mk16_le(u16 *v) +{ + return le16_to_cpu(*v); +} + + +static const u16 Sbox[256] = +{ + 0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154, + 0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A, + 0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B, + 0x41EC, 0xB367, 0x5FFD, 0x45EA, 0x23BF, 0x53F7, 0xE496, 0x9B5B, + 0x75C2, 0xE11C, 0x3DAE, 0x4C6A, 0x6C5A, 0x7E41, 0xF502, 0x834F, + 0x685C, 0x51F4, 0xD134, 0xF908, 0xE293, 0xAB73, 0x6253, 0x2A3F, + 0x080C, 0x9552, 0x4665, 0x9D5E, 0x3028, 0x37A1, 0x0A0F, 0x2FB5, + 0x0E09, 0x2436, 0x1B9B, 0xDF3D, 0xCD26, 0x4E69, 0x7FCD, 0xEA9F, + 0x121B, 0x1D9E, 0x5874, 0x342E, 0x362D, 0xDCB2, 0xB4EE, 0x5BFB, + 0xA4F6, 0x764D, 0xB761, 0x7DCE, 0x527B, 0xDD3E, 0x5E71, 0x1397, + 0xA6F5, 0xB968, 0x0000, 0xC12C, 0x4060, 0xE31F, 0x79C8, 0xB6ED, + 0xD4BE, 0x8D46, 0x67D9, 0x724B, 0x94DE, 0x98D4, 0xB0E8, 0x854A, + 0xBB6B, 0xC52A, 0x4FE5, 0xED16, 0x86C5, 0x9AD7, 0x6655, 0x1194, + 0x8ACF, 0xE910, 0x0406, 0xFE81, 0xA0F0, 0x7844, 0x25BA, 0x4BE3, + 0xA2F3, 0x5DFE, 0x80C0, 0x058A, 0x3FAD, 0x21BC, 0x7048, 0xF104, + 0x63DF, 0x77C1, 0xAF75, 0x4263, 0x2030, 0xE51A, 0xFD0E, 0xBF6D, + 0x814C, 0x1814, 0x2635, 0xC32F, 0xBEE1, 0x35A2, 0x88CC, 0x2E39, + 0x9357, 0x55F2, 0xFC82, 0x7A47, 0xC8AC, 0xBAE7, 0x322B, 0xE695, + 0xC0A0, 0x1998, 0x9ED1, 0xA37F, 0x4466, 0x547E, 0x3BAB, 0x0B83, + 0x8CCA, 0xC729, 0x6BD3, 0x283C, 0xA779, 0xBCE2, 0x161D, 0xAD76, + 0xDB3B, 0x6456, 0x744E, 0x141E, 0x92DB, 0x0C0A, 0x486C, 0xB8E4, + 0x9F5D, 0xBD6E, 0x43EF, 0xC4A6, 0x39A8, 0x31A4, 0xD337, 0xF28B, + 0xD532, 0x8B43, 0x6E59, 0xDAB7, 0x018C, 0xB164, 0x9CD2, 0x49E0, + 0xD8B4, 0xACFA, 0xF307, 0xCF25, 0xCAAF, 0xF48E, 0x47E9, 0x1018, + 0x6FD5, 0xF088, 0x4A6F, 0x5C72, 0x3824, 0x57F1, 0x73C7, 0x9751, + 0xCB23, 0xA17C, 0xE89C, 0x3E21, 0x96DD, 0x61DC, 0x0D86, 0x0F85, + 0xE090, 0x7C42, 0x71C4, 0xCCAA, 0x90D8, 0x0605, 0xF701, 0x1C12, + 0xC2A3, 0x6A5F, 0xAEF9, 0x69D0, 0x1791, 0x9958, 0x3A27, 0x27B9, + 0xD938, 0xEB13, 0x2BB3, 0x2233, 0xD2BB, 0xA970, 0x0789, 0x33A7, + 0x2DB6, 0x3C22, 0x1592, 0xC920, 0x8749, 0xAAFF, 0x5078, 0xA57A, + 0x038F, 0x59F8, 0x0980, 0x1A17, 0x65DA, 0xD731, 0x84C6, 0xD0B8, + 0x82C3, 0x29B0, 0x5A77, 0x1E11, 0x7BCB, 0xA8FC, 0x6DD6, 0x2C3A, +}; + + +static inline u16 _S_(u16 v) +{ + u16 t = Sbox[Hi8(v)]; + return Sbox[Lo8(v)] ^ ((t << 8) | (t >> 8)); +} + + +#define PHASE1_LOOP_COUNT 8 + +static void tkip_mixing_phase1(u16 *TTAK, const u8 *TK, const u8 *TA, u32 IV32) +{ + int i, j; + + /* Initialize the 80-bit TTAK from TSC (IV32) and TA[0..5] */ + TTAK[0] = Lo16(IV32); + TTAK[1] = Hi16(IV32); + TTAK[2] = Mk16(TA[1], TA[0]); + TTAK[3] = Mk16(TA[3], TA[2]); + TTAK[4] = Mk16(TA[5], TA[4]); + + for (i = 0; i < PHASE1_LOOP_COUNT; i++) { + j = 2 * (i & 1); + TTAK[0] += _S_(TTAK[4] ^ Mk16(TK[1 + j], TK[0 + j])); + TTAK[1] += _S_(TTAK[0] ^ Mk16(TK[5 + j], TK[4 + j])); + TTAK[2] += _S_(TTAK[1] ^ Mk16(TK[9 + j], TK[8 + j])); + TTAK[3] += _S_(TTAK[2] ^ Mk16(TK[13 + j], TK[12 + j])); + TTAK[4] += _S_(TTAK[3] ^ Mk16(TK[1 + j], TK[0 + j])) + i; + } +} + + +static void tkip_mixing_phase2(u8 *WEPSeed, const u8 *TK, const u16 *TTAK, + u16 IV16) +{ + /* Make temporary area overlap WEP seed so that the final copy can be + * avoided on little endian hosts. */ + u16 *PPK = (u16 *) &WEPSeed[4]; + + /* Step 1 - make copy of TTAK and bring in TSC */ + PPK[0] = TTAK[0]; + PPK[1] = TTAK[1]; + PPK[2] = TTAK[2]; + PPK[3] = TTAK[3]; + PPK[4] = TTAK[4]; + PPK[5] = TTAK[4] + IV16; + + /* Step 2 - 96-bit bijective mixing using S-box */ + PPK[0] += _S_(PPK[5] ^ Mk16_le((u16 *) &TK[0])); + PPK[1] += _S_(PPK[0] ^ Mk16_le((u16 *) &TK[2])); + PPK[2] += _S_(PPK[1] ^ Mk16_le((u16 *) &TK[4])); + PPK[3] += _S_(PPK[2] ^ Mk16_le((u16 *) &TK[6])); + PPK[4] += _S_(PPK[3] ^ Mk16_le((u16 *) &TK[8])); + PPK[5] += _S_(PPK[4] ^ Mk16_le((u16 *) &TK[10])); + + PPK[0] += RotR1(PPK[5] ^ Mk16_le((u16 *) &TK[12])); + PPK[1] += RotR1(PPK[0] ^ Mk16_le((u16 *) &TK[14])); + PPK[2] += RotR1(PPK[1]); + PPK[3] += RotR1(PPK[2]); + PPK[4] += RotR1(PPK[3]); + PPK[5] += RotR1(PPK[4]); + + /* Step 3 - bring in last of TK bits, assign 24-bit WEP IV value + * WEPSeed[0..2] is transmitted as WEP IV */ + WEPSeed[0] = Hi8(IV16); + WEPSeed[1] = (Hi8(IV16) | 0x20) & 0x7F; + WEPSeed[2] = Lo8(IV16); + WEPSeed[3] = Lo8((PPK[5] ^ Mk16_le((u16 *) &TK[0])) >> 1); + +#ifdef __BIG_ENDIAN + { + int i; + for (i = 0; i < 6; i++) + PPK[i] = (PPK[i] << 8) | (PPK[i] >> 8); + } +#endif +} + +static int ieee80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int len; + u8 rc4key[16], *pos, *icv; + struct ieee80211_hdr *hdr; + u32 crc; + struct scatterlist sg; + + if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + if (!tkey->tx_phase1_done) { + tkip_mixing_phase1(tkey->tx_ttak, tkey->key, hdr->addr2, + tkey->tx_iv32); + tkey->tx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, tkey->tx_iv16); + + len = skb->len - hdr_len; + pos = skb_push(skb, 8); + memmove(pos, pos + 8, hdr_len); + pos += hdr_len; + icv = skb_put(skb, 4); + + *pos++ = rc4key[0]; + *pos++ = rc4key[1]; + *pos++ = rc4key[2]; + *pos++ = (tkey->key_idx << 6) | (1 << 5) /* Ext IV included */; + *pos++ = tkey->tx_iv32 & 0xff; + *pos++ = (tkey->tx_iv32 >> 8) & 0xff; + *pos++ = (tkey->tx_iv32 >> 16) & 0xff; + *pos++ = (tkey->tx_iv32 >> 24) & 0xff; + + crc = ~crc32_le(~0, pos, len); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(tkey->tfm_arc4, &sg, &sg, len + 4); + + tkey->tx_iv16++; + if (tkey->tx_iv16 == 0) { + tkey->tx_phase1_done = 0; + tkey->tx_iv32++; + } + + return 0; +} + +static int ieee80211_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 rc4key[16]; + u8 keyidx, *pos; + u32 iv32; + u16 iv16; + struct ieee80211_hdr *hdr; + u8 icv[4]; + u32 crc; + struct scatterlist sg; + int plen; + + if (skb->len < hdr_len + 8 + 4) + return -1; + + hdr = (struct ieee80211_hdr *) skb->data; + pos = skb->data + hdr_len; + keyidx = pos[3]; + if (!(keyidx & (1 << 5))) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet without ExtIV" + " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + return -2; + } + keyidx >>= 6; + if (tkey->key_idx != keyidx) { + printk(KERN_DEBUG "TKIP: RX tkey->key_idx=%d frame " + "keyidx=%d priv=%p\n", tkey->key_idx, keyidx, priv); + return -6; + } + if (!tkey->key_set) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: received packet from " MAC_FMT + " with keyid=%d that does not have a configured" + " key\n", MAC_ARG(hdr->addr2), keyidx); + } + return -3; + } + iv16 = (pos[0] << 8) | pos[2]; + iv32 = pos[4] | (pos[5] << 8) | (pos[6] << 16) | (pos[7] << 24); + pos += 8; + + if (iv32 < tkey->rx_iv32 || + (iv32 == tkey->rx_iv32 && iv16 <= tkey->rx_iv16)) { + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: replay detected: STA=" MAC_FMT + " previous TSC %08x%04x received TSC " + "%08x%04x\n", MAC_ARG(hdr->addr2), + tkey->rx_iv32, tkey->rx_iv16, iv32, iv16); + } + tkey->dot11RSNAStatsTKIPReplays++; + return -4; + } + + if (iv32 != tkey->rx_iv32 || !tkey->rx_phase1_done) { + tkip_mixing_phase1(tkey->rx_ttak, tkey->key, hdr->addr2, iv32); + tkey->rx_phase1_done = 1; + } + tkip_mixing_phase2(rc4key, tkey->key, tkey->rx_ttak, iv16); + + plen = skb->len - hdr_len - 12; + + crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(tkey->tfm_arc4, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + if (iv32 != tkey->rx_iv32) { + /* Previously cached Phase1 result was already lost, so + * it needs to be recalculated for the next packet. */ + tkey->rx_phase1_done = 0; + } + if (net_ratelimit()) { + printk(KERN_DEBUG "TKIP: ICV error detected: STA=" + MAC_FMT "\n", MAC_ARG(hdr->addr2)); + } + tkey->dot11RSNAStatsTKIPICVErrors++; + return -5; + } + + /* Update real counters only after Michael MIC verification has + * completed */ + tkey->rx_iv32_new = iv32; + tkey->rx_iv16_new = iv16; + + /* Remove IV and ICV */ + memmove(skb->data + 8, skb->data, hdr_len); + skb_pull(skb, 8); + skb_trim(skb, skb->len - 4); + + return keyidx; +} + + +static int michael_mic(struct ieee80211_tkip_data *tkey, u8 *key, u8 *hdr, + u8 *data, size_t data_len, u8 *mic) +{ + struct scatterlist sg[2]; + + if (tkey->tfm_michael == NULL) { + printk(KERN_WARNING "michael_mic: tfm_michael == NULL\n"); + return -1; + } + sg[0].page = virt_to_page(hdr); + sg[0].offset = offset_in_page(hdr); + sg[0].length = 16; + + sg[1].page = virt_to_page(data); + sg[1].offset = offset_in_page(data); + sg[1].length = data_len; + + crypto_digest_init(tkey->tfm_michael); + crypto_digest_setkey(tkey->tfm_michael, key, 8); + crypto_digest_update(tkey->tfm_michael, sg, 2); + crypto_digest_final(tkey->tfm_michael, mic); + + return 0; +} + +static void michael_mic_hdr(struct sk_buff *skb, u8 *hdr) +{ + struct ieee80211_hdr *hdr11; + + hdr11 = (struct ieee80211_hdr *) skb->data; + switch (le16_to_cpu(hdr11->frame_ctl) & + (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr3, ETH_ALEN); /* SA */ + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */ + break; + case 0: + memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ + memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + break; + } + + hdr[12] = 0; /* priority */ + hdr[13] = hdr[14] = hdr[15] = 0; /* reserved */ +} + + +static int ieee80211_michael_mic_add(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 *pos; + + if (skb_tailroom(skb) < 8 || skb->len < hdr_len) { + printk(KERN_DEBUG "Invalid packet for Michael MIC add " + "(tailroom=%d hdr_len=%d skb->len=%d)\n", + skb_tailroom(skb), hdr_len, skb->len); + return -1; + } + + michael_mic_hdr(skb, tkey->tx_hdr); + pos = skb_put(skb, 8); + if (michael_mic(tkey, &tkey->key[16], tkey->tx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, pos)) + return -1; + + return 0; +} + + +#if WIRELESS_EXT >= 18 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + struct iw_michaelmicfailure ev; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + memset(&ev, 0, sizeof(ev)); + ev.flags = keyidx & IW_MICFAILURE_KEY_ID; + if (hdr->addr1[0] & 0x01) + ev.flags |= IW_MICFAILURE_GROUP; + else + ev.flags |= IW_MICFAILURE_PAIRWISE; + ev.src_addr.sa_family = ARPHRD_ETHER; + memcpy(ev.src_addr.sa_data, hdr->addr2, ETH_ALEN); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = sizeof(ev); + wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *) &ev); +} +#elif WIRELESS_EXT >= 15 +static void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ + union iwreq_data wrqu; + char buf[128]; + + /* TODO: needed parameters: count, keyid, key type, TSC */ + sprintf(buf, "MLME-MICHAELMICFAILURE.indication(keyid=%d %scast addr=" + MAC_FMT ")", keyidx, hdr->addr1[0] & 0x01 ? "broad" : "uni", + MAC_ARG(hdr->addr2)); + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.data.length = strlen(buf); + wireless_send_event(dev, IWEVCUSTOM, &wrqu, buf); +} +#else /* WIRELESS_EXT >= 15 */ +static inline void ieee80211_michael_mic_failure(struct net_device *dev, + struct ieee80211_hdr *hdr, + int keyidx) +{ +} +#endif /* WIRELESS_EXT >= 15 */ + + +static int ieee80211_michael_mic_verify(struct sk_buff *skb, int keyidx, + int hdr_len, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + u8 mic[8]; + + if (!tkey->key_set) + return -1; + + michael_mic_hdr(skb, tkey->rx_hdr); + if (michael_mic(tkey, &tkey->key[24], tkey->rx_hdr, + skb->data + hdr_len, skb->len - 8 - hdr_len, mic)) + return -1; + if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) { + struct ieee80211_hdr *hdr; + hdr = (struct ieee80211_hdr *) skb->data; + printk(KERN_DEBUG "%s: Michael MIC verification failed for " + "MSDU from " MAC_FMT " keyidx=%d\n", + skb->dev ? skb->dev->name : "N/A", MAC_ARG(hdr->addr2), + keyidx); + if (skb->dev) + ieee80211_michael_mic_failure(skb->dev, hdr, keyidx); + tkey->dot11RSNAStatsTKIPLocalMICFailures++; + return -1; + } + + /* Update TSC counters for RX now that the packet verification has + * completed. */ + tkey->rx_iv32 = tkey->rx_iv32_new; + tkey->rx_iv16 = tkey->rx_iv16_new; + + skb_trim(skb, skb->len - 8); + + return 0; +} + + +static int ieee80211_tkip_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + int keyidx; + struct crypto_tfm *tfm = tkey->tfm_michael; + struct crypto_tfm *tfm2 = tkey->tfm_arc4; + + keyidx = tkey->key_idx; + memset(tkey, 0, sizeof(*tkey)); + tkey->key_idx = keyidx; + tkey->tfm_michael = tfm; + tkey->tfm_arc4 = tfm2; + if (len == TKIP_KEY_LEN) { + memcpy(tkey->key, key, TKIP_KEY_LEN); + tkey->key_set = 1; + tkey->tx_iv16 = 1; /* TSC is initialized to 1 */ + if (seq) { + tkey->rx_iv32 = (seq[5] << 24) | (seq[4] << 16) | + (seq[3] << 8) | seq[2]; + tkey->rx_iv16 = (seq[1] << 8) | seq[0]; + } + } else if (len == 0) { + tkey->key_set = 0; + } else + return -1; + + return 0; +} + + +static int ieee80211_tkip_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct ieee80211_tkip_data *tkey = priv; + + if (len < TKIP_KEY_LEN) + return -1; + + if (!tkey->key_set) + return 0; + memcpy(key, tkey->key, TKIP_KEY_LEN); + + if (seq) { + /* Return the sequence number of the last transmitted frame. */ + u16 iv16 = tkey->tx_iv16; + u32 iv32 = tkey->tx_iv32; + if (iv16 == 0) + iv32--; + iv16--; + seq[0] = tkey->tx_iv16; + seq[1] = tkey->tx_iv16 >> 8; + seq[2] = tkey->tx_iv32; + seq[3] = tkey->tx_iv32 >> 8; + seq[4] = tkey->tx_iv32 >> 16; + seq[5] = tkey->tx_iv32 >> 24; + } + + return TKIP_KEY_LEN; +} + + +static char * ieee80211_tkip_print_stats(char *p, void *priv) +{ + struct ieee80211_tkip_data *tkip = priv; + p += sprintf(p, "key[%d] alg=TKIP key_set=%d " + "tx_pn=%02x%02x%02x%02x%02x%02x " + "rx_pn=%02x%02x%02x%02x%02x%02x " + "replays=%d icv_errors=%d local_mic_failures=%d\n", + tkip->key_idx, tkip->key_set, + (tkip->tx_iv32 >> 24) & 0xff, + (tkip->tx_iv32 >> 16) & 0xff, + (tkip->tx_iv32 >> 8) & 0xff, + tkip->tx_iv32 & 0xff, + (tkip->tx_iv16 >> 8) & 0xff, + tkip->tx_iv16 & 0xff, + (tkip->rx_iv32 >> 24) & 0xff, + (tkip->rx_iv32 >> 16) & 0xff, + (tkip->rx_iv32 >> 8) & 0xff, + tkip->rx_iv32 & 0xff, + (tkip->rx_iv16 >> 8) & 0xff, + tkip->rx_iv16 & 0xff, + tkip->dot11RSNAStatsTKIPReplays, + tkip->dot11RSNAStatsTKIPICVErrors, + tkip->dot11RSNAStatsTKIPLocalMICFailures); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_tkip = { + .name = "TKIP", + .init = ieee80211_tkip_init, + .deinit = ieee80211_tkip_deinit, + .encrypt_mpdu = ieee80211_tkip_encrypt, + .decrypt_mpdu = ieee80211_tkip_decrypt, + .encrypt_msdu = ieee80211_michael_mic_add, + .decrypt_msdu = ieee80211_michael_mic_verify, + .set_key = ieee80211_tkip_set_key, + .get_key = ieee80211_tkip_get_key, + .print_stats = ieee80211_tkip_print_stats, + .extra_prefix_len = 4 + 4, /* IV + ExtIV */ + .extra_postfix_len = 8 + 4, /* MIC + ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_tkip_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_tkip) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_tkip_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_tkip); +} + + +module_init(ieee80211_crypto_tkip_init); +module_exit(ieee80211_crypto_tkip_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,277 @@ +/* + * Host AP crypt: host-based WEP encryption implementation for Host AP driver + * + * Copyright (c) 2002-2004, Jouni Malinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + +#ifndef CONFIG_CRYPTO +#error CONFIG_CRYPTO is required to build this module. +#endif +#include +#include +#include + +MODULE_AUTHOR("Jouni Malinen"); +MODULE_DESCRIPTION("Host AP crypt: WEP"); +MODULE_LICENSE("GPL"); + + +struct prism2_wep_data { + u32 iv; +#define WEP_KEY_LEN 13 + u8 key[WEP_KEY_LEN + 1]; + u8 key_len; + u8 key_idx; + struct crypto_tfm *tfm; +}; + + +static void * prism2_wep_init(int keyidx) +{ + struct prism2_wep_data *priv; + + priv = kmalloc(sizeof(*priv), GFP_ATOMIC); + if (priv == NULL) + goto fail; + memset(priv, 0, sizeof(*priv)); + priv->key_idx = keyidx; + + priv->tfm = crypto_alloc_tfm("arc4", 0); + if (priv->tfm == NULL) { + printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate " + "crypto API arc4\n"); + goto fail; + } + + /* start WEP IV from a random value */ + get_random_bytes(&priv->iv, 4); + + return priv; + +fail: + if (priv) { + if (priv->tfm) + crypto_free_tfm(priv->tfm); + kfree(priv); + } + return NULL; +} + + +static void prism2_wep_deinit(void *priv) +{ + struct prism2_wep_data *_priv = priv; + if (_priv && _priv->tfm) + crypto_free_tfm(_priv->tfm); + kfree(priv); +} + + +/* Perform WEP encryption on given skb that has at least 4 bytes of headroom + * for IV and 4 bytes of tailroom for ICV. Both IV and ICV will be transmitted, + * so the payload length increases with 8 bytes. + * + * WEP frame payload: IV + TX key idx, RC4(data), ICV = RC4(CRC32(data)) + */ +static int prism2_wep_encrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, len; + u8 key[WEP_KEY_LEN + 3]; + u8 *pos, *icv; + struct scatterlist sg; + + if (skb_headroom(skb) < 4 || skb_tailroom(skb) < 4 || + skb->len < hdr_len) + return -1; + + len = skb->len - hdr_len; + pos = skb_push(skb, 4); + memmove(pos, pos + 4, hdr_len); + pos += hdr_len; + + klen = 3 + wep->key_len; + + wep->iv++; + + /* Fluhrer, Mantin, and Shamir have reported weaknesses in the key + * scheduling algorithm of RC4. At least IVs (KeyByte + 3, 0xff, N) + * can be used to speedup attacks, so avoid using them. */ + if ((wep->iv & 0xff00) == 0xff00) { + u8 B = (wep->iv >> 16) & 0xff; + if (B >= 3 && B < klen) + wep->iv += 0x0100; + } + + /* Prepend 24-bit IV to RC4 key and TX frame */ + *pos++ = key[0] = (wep->iv >> 16) & 0xff; + *pos++ = key[1] = (wep->iv >> 8) & 0xff; + *pos++ = key[2] = wep->iv & 0xff; + *pos++ = wep->key_idx << 6; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Append little-endian CRC32 and encrypt it to produce ICV */ + crc = ~crc32_le(~0, pos, len); + icv = skb_put(skb, 4); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = len + 4; + crypto_cipher_encrypt(wep->tfm, &sg, &sg, len + 4); + + return 0; +} + + +/* Perform WEP decryption on given buffer. Buffer includes whole WEP part of + * the frame: IV (4 bytes), encrypted payload (including SNAP header), + * ICV (4 bytes). len includes both IV and ICV. + * + * Returns 0 if frame was decrypted successfully and ICV was correct and -1 on + * failure. If frame is OK, IV and ICV will be removed. + */ +static int prism2_wep_decrypt(struct sk_buff *skb, int hdr_len, void *priv) +{ + struct prism2_wep_data *wep = priv; + u32 crc, klen, plen; + u8 key[WEP_KEY_LEN + 3]; + u8 keyidx, *pos, icv[4]; + struct scatterlist sg; + + if (skb->len < hdr_len + 8) + return -1; + + pos = skb->data + hdr_len; + key[0] = *pos++; + key[1] = *pos++; + key[2] = *pos++; + keyidx = *pos++ >> 6; + if (keyidx != wep->key_idx) + return -1; + + klen = 3 + wep->key_len; + + /* Copy rest of the WEP key (the secret part) */ + memcpy(key + 3, wep->key, wep->key_len); + + /* Apply RC4 to data and compute CRC32 over decrypted data */ + plen = skb->len - hdr_len - 8; + + crypto_cipher_setkey(wep->tfm, key, klen); + sg.page = virt_to_page(pos); + sg.offset = offset_in_page(pos); + sg.length = plen + 4; + crypto_cipher_decrypt(wep->tfm, &sg, &sg, plen + 4); + + crc = ~crc32_le(~0, pos, plen); + icv[0] = crc; + icv[1] = crc >> 8; + icv[2] = crc >> 16; + icv[3] = crc >> 24; + if (memcmp(icv, pos + plen, 4) != 0) { + /* ICV mismatch - drop frame */ + return -2; + } + + /* Remove IV and ICV */ + memmove(skb->data + 4, skb->data, hdr_len); + skb_pull(skb, 4); + skb_trim(skb, skb->len - 4); + + return 0; +} + + +static int prism2_wep_set_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < 0 || len > WEP_KEY_LEN) + return -1; + + memcpy(wep->key, key, len); + wep->key_len = len; + + return 0; +} + + +static int prism2_wep_get_key(void *key, int len, u8 *seq, void *priv) +{ + struct prism2_wep_data *wep = priv; + + if (len < wep->key_len) + return -1; + + memcpy(key, wep->key, wep->key_len); + + return wep->key_len; +} + + +static char * prism2_wep_print_stats(char *p, void *priv) +{ + struct prism2_wep_data *wep = priv; + p += sprintf(p, "key[%d] alg=WEP len=%d\n", + wep->key_idx, wep->key_len); + return p; +} + + +static struct ieee80211_crypto_ops ieee80211_crypt_wep = { + .name = "WEP", + .init = prism2_wep_init, + .deinit = prism2_wep_deinit, + .encrypt_mpdu = prism2_wep_encrypt, + .decrypt_mpdu = prism2_wep_decrypt, + .encrypt_msdu = NULL, + .decrypt_msdu = NULL, + .set_key = prism2_wep_set_key, + .get_key = prism2_wep_get_key, + .print_stats = prism2_wep_print_stats, + .extra_prefix_len = 4, /* IV */ + .extra_postfix_len = 4, /* ICV */ + .owner = THIS_MODULE, +}; + + +static int __init ieee80211_crypto_wep_init(void) +{ + if (ieee80211_register_crypto_ops(&ieee80211_crypt_wep) < 0) + return -1; + + return 0; +} + + +static void __exit ieee80211_crypto_wep_exit(void) +{ + ieee80211_unregister_crypto_ops(&ieee80211_crypt_wep); +} + + +module_init(ieee80211_crypto_wep_init); +module_exit(ieee80211_crypto_wep_exit); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_rx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_rx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_rx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_rx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,1215 @@ +/* + * Original code based Host AP (software wireless LAN access point) driver + * for Intersil Prism2/2.5/3 - hostap.o module, common routines + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ieee80211.h" + +static inline void ieee80211_monitor_rx(struct ieee80211_device *ieee, + struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + u16 fc = le16_to_cpu(hdr->frame_ctl); + + skb->dev = ieee->dev; + skb->mac.raw = skb->data; + skb_pull(skb, ieee80211_get_hdrlen(fc)); + skb->pkt_type = PACKET_OTHERHOST; + skb->protocol = __constant_htons(ETH_P_80211_RAW); + memset(skb->cb, 0, sizeof(skb->cb)); + netif_rx(skb); +} + + +/* Called only as a tasklet (software IRQ) */ +static struct ieee80211_frag_entry * +ieee80211_frag_cache_find(struct ieee80211_device *ieee, unsigned int seq, + unsigned int frag, u8 *src, u8 *dst) +{ + struct ieee80211_frag_entry *entry; + int i; + + for (i = 0; i < IEEE80211_FRAG_CACHE_LEN; i++) { + entry = &ieee->frag_cache[i]; + if (entry->skb != NULL && + time_after(jiffies, entry->first_frag_time + 2 * HZ)) { + IEEE80211_DEBUG_FRAG( + "expiring fragment cache entry " + "seq=%u last_frag=%u\n", + entry->seq, entry->last_frag); + dev_kfree_skb_any(entry->skb); + entry->skb = NULL; + } + + if (entry->skb != NULL && entry->seq == seq && + (entry->last_frag + 1 == frag || frag == -1) && + memcmp(entry->src_addr, src, ETH_ALEN) == 0 && + memcmp(entry->dst_addr, dst, ETH_ALEN) == 0) + return entry; + } + + return NULL; +} + +/* Called only as a tasklet (software IRQ) */ +static struct sk_buff * +ieee80211_frag_cache_get(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + struct sk_buff *skb = NULL; + u16 sc; + unsigned int frag, seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + seq = WLAN_GET_SEQ_SEQ(sc); + + if (frag == 0) { + /* Reserve enough space to fit maximum frame length */ + skb = dev_alloc_skb(ieee->dev->mtu + + sizeof(struct ieee80211_hdr) + + 8 /* LLC */ + + 2 /* alignment */ + + 8 /* WEP */ + ETH_ALEN /* WDS */); + if (skb == NULL) + return NULL; + + entry = &ieee->frag_cache[ieee->frag_next_idx]; + ieee->frag_next_idx++; + if (ieee->frag_next_idx >= IEEE80211_FRAG_CACHE_LEN) + ieee->frag_next_idx = 0; + + if (entry->skb != NULL) + dev_kfree_skb_any(entry->skb); + + entry->first_frag_time = jiffies; + entry->seq = seq; + entry->last_frag = frag; + entry->skb = skb; + memcpy(entry->src_addr, hdr->addr2, ETH_ALEN); + memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN); + } else { + /* received a fragment of a frame for which the head fragment + * should have already been received */ + entry = ieee80211_frag_cache_find(ieee, seq, frag, hdr->addr2, + hdr->addr1); + if (entry != NULL) { + entry->last_frag = frag; + skb = entry->skb; + } + } + + return skb; +} + + +/* Called only as a tasklet (software IRQ) */ +static int ieee80211_frag_cache_invalidate(struct ieee80211_device *ieee, + struct ieee80211_hdr *hdr) +{ + u16 sc; + unsigned int seq; + struct ieee80211_frag_entry *entry; + + sc = le16_to_cpu(hdr->seq_ctl); + seq = WLAN_GET_SEQ_SEQ(sc); + + entry = ieee80211_frag_cache_find(ieee, seq, -1, hdr->addr2, + hdr->addr1); + + if (entry == NULL) { + IEEE80211_DEBUG_FRAG( + "could not invalidate fragment cache " + "entry (seq=%u)\n", seq); + return -1; + } + + entry->skb = NULL; + return 0; +} + + +#ifdef NOT_YET +/* ieee80211_rx_frame_mgtmt + * + * Responsible for handling management control frames + * + * Called by ieee80211_rx */ +static inline int +ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats, u16 type, + u16 stype) +{ + if (ieee->iw_mode == IW_MODE_MASTER) { + printk(KERN_DEBUG "%s: Master mode not yet suppported.\n", + ieee->dev->name); + return 0; +/* + hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr *) + skb->data);*/ + } + + if (ieee->hostapd && type == WLAN_FC_TYPE_MGMT) { + if (stype == WLAN_FC_STYPE_BEACON && + ieee->iw_mode == IW_MODE_MASTER) { + struct sk_buff *skb2; + /* Process beacon frames also in kernel driver to + * update STA(AP) table statistics */ + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2) + hostap_rx(skb2->dev, skb2, rx_stats); + } + + /* send management frames to the user space daemon for + * processing */ + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT); + return 0; + } + + if (ieee->iw_mode == IW_MODE_MASTER) { + if (type != WLAN_FC_TYPE_MGMT && type != WLAN_FC_TYPE_CTRL) { + printk(KERN_DEBUG "%s: unknown management frame " + "(type=0x%02x, stype=0x%02x) dropped\n", + skb->dev->name, type, stype); + return -1; + } + + hostap_rx(skb->dev, skb, rx_stats); + return 0; + } + + printk(KERN_DEBUG "%s: hostap_rx_frame_mgmt: management frame " + "received in non-Host AP mode\n", skb->dev->name); + return -1; +} +#endif + + +/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */ +/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ +static unsigned char rfc1042_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 }; +/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */ +static unsigned char bridge_tunnel_header[] = +{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 }; +/* No encapsulation header if EtherType < 0x600 (=length) */ + +#ifdef CONFIG_IEEE80211_CRYPT +/* Called by ieee80211_rx_frame_decrypt */ +static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, + struct sk_buff *skb) +{ + struct net_device *dev = ieee->dev; + u16 fc, ethertype; + struct ieee80211_hdr *hdr; + u8 *pos; + + if (skb->len < 24) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + fc = le16_to_cpu(hdr->frame_ctl); + + /* check that the frame is unicast frame to us */ + if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 && + memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) { + /* ToDS frame with own addr BSSID and DA */ + } else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_FROMDS && + memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) { + /* FromDS frame with own addr as DA */ + } else + return 0; + + if (skb->len < 24 + 8) + return 0; + + /* check for port access entity Ethernet type */ + pos = skb->data + 24; + ethertype = (pos[6] << 8) | pos[7]; + if (ethertype == ETH_P_PAE) + return 1; + + return 0; +} + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt(struct ieee80211_device* ieee, struct sk_buff *skb, + struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_mpdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + +#ifdef CONFIG_IEEE80211_WPA + if (ieee->tkip_countermeasures && + strcmp(crypt->ops->name, "TKIP") == 0) { + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "received packet from " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(hdr->addr2)); + } + return -1; + } +#endif + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_mpdu(skb, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + IEEE80211_DEBUG_DROP( + "decryption failed (SA=" MAC_FMT + ") res=%d\n", MAC_ARG(hdr->addr2), res); + if (res == -2) + IEEE80211_DEBUG_DROP("WEP decryption failed ICV " + "mismatch (key %d)\n", + skb->data[hdrlen + 3] >> 6); + ieee->ieee_stats.rx_discards_wep_undecryptable++; + return -1; + } + + return res; +} + + +/* Called only as a tasklet (software IRQ), by ieee80211_rx */ +static inline int +ieee80211_rx_frame_decrypt_msdu(struct ieee80211_device* ieee, struct sk_buff *skb, + int keyidx, struct ieee80211_crypt_data *crypt) +{ + struct ieee80211_hdr *hdr; + int res, hdrlen; + + if (crypt == NULL || crypt->ops->decrypt_msdu == NULL) + return 0; + + hdr = (struct ieee80211_hdr *) skb->data; + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + + atomic_inc(&crypt->refcnt); + res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv); + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed" + " (SA=" MAC_FMT " keyidx=%d)\n", + ieee->dev->name, MAC_ARG(hdr->addr2), keyidx); + return -1; + } + + return 0; +} +#endif /* CONFIG_IEEE80211_CRYPT */ + + +/* All received frames are sent to this function. @skb contains the frame in + * IEEE 802.11 format, i.e., in the format it was sent over air. + * This function is called only as a tasklet (software IRQ). */ +int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats) +{ + struct net_device *dev = ieee->dev; + struct ieee80211_hdr *hdr; + size_t hdrlen; + u16 fc, type, stype, sc; + struct net_device_stats *stats; + unsigned int frag; + u8 *payload; + u16 ethertype; +#ifdef NOT_YET + struct net_device *wds = NULL; + struct sk_buff *skb2 = NULL; + struct net_device *wds = NULL; + int frame_authorized = 0; + int from_assoc_ap = 0; + void *sta = NULL; +#endif + u8 dst[ETH_ALEN]; + u8 src[ETH_ALEN]; +#ifdef CONFIG_IEEE80211_CRYPT + struct ieee80211_crypt_data *crypt = NULL; + int keyidx = 0; +#endif + + hdr = (struct ieee80211_hdr *)skb->data; + stats = &ieee->stats; + + if (skb->len < 10) { + printk(KERN_INFO "%s: SKB length < 10\n", + dev->name); + goto rx_dropped; + } + + fc = le16_to_cpu(hdr->frame_ctl); + type = WLAN_FC_GET_TYPE(fc); + stype = WLAN_FC_GET_STYPE(fc); + sc = le16_to_cpu(hdr->seq_ctl); + frag = WLAN_GET_SEQ_FRAG(sc); + hdrlen = ieee80211_get_hdrlen(fc); + +#ifdef NOT_YET +#if WIRELESS_EXT > 15 + /* Put this code here so that we avoid duplicating it in all + * Rx paths. - Jean II */ +#ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */ + /* If spy monitoring on */ + if (iface->spy_data.spy_number > 0) { + struct iw_quality wstats; + wstats.level = rx_stats->signal; + wstats.noise = rx_stats->noise; + wstats.updated = 6; /* No qual value */ + /* Update spy records */ + wireless_spy_update(dev, hdr->addr2, &wstats); + } +#endif /* IW_WIRELESS_SPY */ +#endif /* WIRELESS_EXT > 15 */ + hostap_update_rx_stats(local->ap, hdr, rx_stats); +#endif + +#if WIRELESS_EXT > 15 + if (ieee->iw_mode == IW_MODE_MONITOR) { + ieee80211_monitor_rx(ieee, skb, rx_stats); + stats->rx_packets++; + stats->rx_bytes += skb->len; + return 1; + } +#endif + +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt) { + int idx = 0; + if (skb->len >= hdrlen + 3) + idx = skb->data[hdrlen + 3] >> 6; + crypt = ieee->crypt[idx]; +#ifdef NOT_YET + sta = NULL; + + /* Use station specific key to override default keys if the + * receiver address is a unicast address ("individual RA"). If + * bcrx_sta_key parameter is set, station specific key is used + * even with broad/multicast targets (this is against IEEE + * 802.11, but makes it easier to use different keys with + * stations that do not support WEP key mapping). */ + + if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key) + (void) hostap_handle_sta_crypto(local, hdr, &crypt, + &sta); +#endif + + /* allow NULL decrypt to indicate an station specific override + * for default encryption */ + if (crypt && (crypt->ops == NULL || + crypt->ops->decrypt_mpdu == NULL)) + crypt = NULL; + + if (!crypt && (fc & IEEE80211_FCTL_WEP)) { + /* This seems to be triggered by some (multicast?) + * frames from other than current BSS, so just drop the + * frames silently instead of filling system log with + * these reports. */ + IEEE80211_DEBUG_DROP("WEP decryption failed (not set)" + " (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + ieee->ieee_stats.rx_discards_wep_undecryptable++; + goto rx_dropped; + } + } +#endif /* CONFIG_IEEE80211_CRYPT */ + +#ifdef NOT_YET + if (type != WLAN_FC_TYPE_DATA) { + if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH && + fc & IEEE80211_FCTL_WEP && ieee->host_decrypt && + (keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0) + { + printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth " + "from " MAC_FMT "\n", dev->name, + MAC_ARG(hdr->addr2)); + /* TODO: could inform hostapd about this so that it + * could send auth failure report */ + goto rx_dropped; + } + + if (ieee80211_rx_frame_mgmt(ieee, skb, rx_stats, type, stype)) + goto rx_dropped; + else + goto rx_exit; + } +#endif + + /* Data frame - extract src/dst addresses */ + if (skb->len < IEEE80211_DATA_HDR3_LEN) + goto rx_dropped; + + switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { + case IEEE80211_FCTL_FROMDS: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr3, ETH_ALEN); + break; + case IEEE80211_FCTL_TODS: + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: + if (skb->len < IEEE80211_DATA_HDR4_LEN) + goto rx_dropped; + memcpy(dst, hdr->addr3, ETH_ALEN); + memcpy(src, hdr->addr4, ETH_ALEN); + break; + case 0: + memcpy(dst, hdr->addr1, ETH_ALEN); + memcpy(src, hdr->addr2, ETH_ALEN); + break; + } + +#ifdef NOT_YET + if (hostap_rx_frame_wds(ieee, hdr, fc, &wds)) + goto rx_dropped; + if (wds) { + skb->dev = dev = wds; + stats = hostap_get_stats(dev); + } + + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && + ieee->stadev && + memcmp(hdr->addr2, ieee->assoc_ap_addr, ETH_ALEN) == 0) { + /* Frame from BSSID of the AP for which we are a client */ + skb->dev = dev = ieee->stadev; + stats = hostap_get_stats(dev); + from_assoc_ap = 1; + } +#endif + + dev->last_rx = jiffies; + +#ifdef NOT_YET + if ((ieee->iw_mode == IW_MODE_MASTER || + ieee->iw_mode == IW_MODE_REPEAT) && + !from_assoc_ap) { + switch (hostap_handle_sta_rx(ieee, dev, skb, rx_stats, + wds != NULL)) { + case AP_RX_CONTINUE_NOT_AUTHORIZED: + frame_authorized = 0; + break; + case AP_RX_CONTINUE: + frame_authorized = 1; + break; + case AP_RX_DROP: + goto rx_dropped; + case AP_RX_EXIT: + goto rx_exit; + } + } +#endif + + /* Nullfunc frames may have PS-bit set, so they must be passed to + * hostap_handle_sta_rx() before being dropped here. */ + if (stype != IEEE80211_STYPE_DATA && + stype != IEEE80211_STYPE_DATA_CFACK && + stype != IEEE80211_STYPE_DATA_CFPOLL && + stype != IEEE80211_STYPE_DATA_CFACKPOLL) { + if (stype != IEEE80211_STYPE_NULLFUNC) + IEEE80211_DEBUG_DROP( + "RX: dropped data frame " + "with no data (type=0x%02x, " + "subtype=0x%02x, len=%d)\n", + type, stype, skb->len); + goto rx_dropped; + } + + /* skb: hdr + (possibly fragmented, possibly encrypted) payload */ + +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + (keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0) + goto rx_dropped; +#endif + hdr = (struct ieee80211_hdr *) skb->data; + + /* skb: hdr + (possibly fragmented) plaintext payload */ + // PR: FIXME: hostap has additional conditions in the "if" below: + // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) { + int flen; + struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr); + IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag); + + if (!frag_skb) { + IEEE80211_DEBUG(IEEE80211_DL_RX | IEEE80211_DL_FRAG, + "Rx cannot get skb from fragment " + "cache (morefrag=%d seq=%u frag=%u)\n", + (fc & IEEE80211_FCTL_MOREFRAGS) != 0, + WLAN_GET_SEQ_SEQ(sc), frag); + goto rx_dropped; + } + + flen = skb->len; + if (frag != 0) + flen -= hdrlen; + + if (frag_skb->tail + flen > frag_skb->end) { + printk(KERN_WARNING "%s: host decrypted and " + "reassembled frame did not fit skb\n", + dev->name); + ieee80211_frag_cache_invalidate(ieee, hdr); + goto rx_dropped; + } + + if (frag == 0) { + /* copy first fragment (including full headers) into + * beginning of the fragment cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data, flen); + } else { + /* append frame payload to the end of the fragment + * cache skb */ + memcpy(skb_put(frag_skb, flen), skb->data + hdrlen, + flen); + } + dev_kfree_skb_any(skb); + skb = NULL; + + if (fc & IEEE80211_FCTL_MOREFRAGS) { + /* more fragments expected - leave the skb in fragment + * cache for now; it will be delivered to upper layers + * after all fragments have been received */ + goto rx_exit; + } + + /* this was the last fragment and the frame will be + * delivered, so remove skb from fragment cache */ + skb = frag_skb; + hdr = (struct ieee80211_hdr *) skb->data; + ieee80211_frag_cache_invalidate(ieee, hdr); + } + + /* skb: hdr + (possible reassembled) full MSDU payload; possibly still + * encrypted/authenticated */ +#ifdef CONFIG_IEEE80211_CRYPT + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt)) + goto rx_dropped; + + hdr = (struct ieee80211_hdr *) skb->data; + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) { + if (/*ieee->ieee802_1x &&*/ + ieee80211_is_eapol_frame(ieee, skb)) { +#ifdef CONFIG_IEEE80211_DEBUG + /* pass unencrypted EAPOL frames even if encryption is + * configured */ + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); +#endif + } else { + IEEE80211_DEBUG_DROP( + "encryption configured, but RX " + "frame not encrypted (SA=" MAC_FMT ")\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } + } + +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !(fc & IEEE80211_FCTL_WEP) && + ieee80211_is_eapol_frame(ieee, skb)) { + struct eapol *eap = (struct eapol *)(skb->data + + 24); + IEEE80211_DEBUG_EAP("RX: IEEE 802.1X EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif + + if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep && + !ieee80211_is_eapol_frame(ieee, skb)) { + IEEE80211_DEBUG_DROP( + "dropped unencrypted RX data " + "frame from " MAC_FMT + " (drop_unencrypted=1)\n", + MAC_ARG(hdr->addr2)); + goto rx_dropped; + } +#endif /* CONFIG_IEEE80211_CRYPT */ + + /* skb: hdr + (possible reassembled) full plaintext payload */ + + payload = skb->data + hdrlen; + ethertype = (payload[6] << 8) | payload[7]; + +#ifdef NOT_YET + /* If IEEE 802.1X is used, check whether the port is authorized to send + * the received frame. */ + if (ieee->ieee802_1x && ieee->iw_mode == IW_MODE_MASTER) { + if (ethertype == ETH_P_PAE) { + printk(KERN_DEBUG "%s: RX: IEEE 802.1X frame\n", + dev->name); + if (ieee->hostapd && ieee->apdev) { + /* Send IEEE 802.1X frames to the user + * space daemon for processing */ + prism2_rx_80211(ieee->apdev, skb, rx_stats, + PRISM2_RX_MGMT); + ieee->apdevstats.rx_packets++; + ieee->apdevstats.rx_bytes += skb->len; + goto rx_exit; + } + } else if (!frame_authorized) { + printk(KERN_DEBUG "%s: dropped frame from " + "unauthorized port (IEEE 802.1X): " + "ethertype=0x%04x\n", + dev->name, ethertype); + goto rx_dropped; + } + } +#endif + + /* convert hdr + possible LLC headers into Ethernet header */ + if (skb->len - hdrlen >= 8 && + ((memcmp(payload, rfc1042_header, SNAP_SIZE) == 0 && + ethertype != ETH_P_AARP && ethertype != ETH_P_IPX) || + memcmp(payload, bridge_tunnel_header, SNAP_SIZE) == 0)) { + /* remove RFC1042 or Bridge-Tunnel encapsulation and + * replace EtherType */ + skb_pull(skb, hdrlen + SNAP_SIZE); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } else { + u16 len; + /* Leave Ethernet header part of hdr and full payload */ + skb_pull(skb, hdrlen); + len = htons(skb->len); + memcpy(skb_push(skb, 2), &len, 2); + memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); + memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); + } + +#ifdef NOT_YET + if (wds && ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == + IEEE80211_FCTL_TODS) && + skb->len >= ETH_HLEN + ETH_ALEN) { + /* Non-standard frame: get addr4 from its bogus location after + * the payload */ + memcpy(skb->data + ETH_ALEN, + skb->data + skb->len - ETH_ALEN, ETH_ALEN); + skb_trim(skb, skb->len - ETH_ALEN); + } +#endif + + stats->rx_packets++; + stats->rx_bytes += skb->len; + +#ifdef NOT_YET + if (ieee->iw_mode == IW_MODE_MASTER && !wds && + ieee->ap->bridge_packets) { + if (dst[0] & 0x01) { + /* copy multicast frame both to the higher layers and + * to the wireless media */ + ieee->ap->bridged_multicast++; + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 == NULL) + printk(KERN_DEBUG "%s: skb_clone failed for " + "multicast frame\n", dev->name); + } else if (hostap_is_sta_assoc(ieee->ap, dst)) { + /* send frame directly to the associated STA using + * wireless media and not passing to higher layers */ + ieee->ap->bridged_unicast++; + skb2 = skb; + skb = NULL; + } + } + + if (skb2 != NULL) { + /* send to wireless media */ + skb2->protocol = __constant_htons(ETH_P_802_3); + skb2->mac.raw = skb2->nh.raw = skb2->data; + /* skb2->nh.raw = skb2->data + ETH_HLEN; */ + skb2->dev = dev; + dev_queue_xmit(skb2); + } + +#endif + + if (skb) { + skb->protocol = eth_type_trans(skb, dev); + memset(skb->cb, 0, sizeof(skb->cb)); + skb->dev = dev; + skb->ip_summed = CHECKSUM_NONE; /* 802.11 crc not sufficient */ + netif_rx(skb); + } + + rx_exit: +#ifdef NOT_YET + if (sta) + hostap_handle_sta_release(sta); +#endif + return 1; + + rx_dropped: + stats->rx_dropped++; + + /* Returning 0 indicates to caller that we have not handled the SKB-- + * so it is still allocated and can be used again by underlying + * hardware as a DMA target */ + return 0; +} + +#define MGMT_FRAME_FIXED_PART_LENGTH 0x24 + +static inline int ieee80211_is_ofdm_rate(u8 rate) +{ + switch (rate & ~IEEE80211_BASIC_RATE_MASK) { + case IEEE80211_OFDM_RATE_6MB: + case IEEE80211_OFDM_RATE_9MB: + case IEEE80211_OFDM_RATE_12MB: + case IEEE80211_OFDM_RATE_18MB: + case IEEE80211_OFDM_RATE_24MB: + case IEEE80211_OFDM_RATE_36MB: + case IEEE80211_OFDM_RATE_48MB: + case IEEE80211_OFDM_RATE_54MB: + return 1; + } + return 0; +} + + +static inline int ieee80211_network_init( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_network *network, + struct ieee80211_rx_stats *stats) +{ +#ifdef CONFIG_IEEE80211_DEBUG + char rates_str[64]; + char *p; +#endif + struct ieee80211_info_element *info_element; + u16 left; + u8 i; + + /* Pull out fixed field data */ + memcpy(network->bssid, beacon->header.addr3, ETH_ALEN); + network->capability = beacon->capability; + network->last_scanned = jiffies; + network->time_stamp[0] = beacon->time_stamp[0]; + network->time_stamp[1] = beacon->time_stamp[1]; + network->beacon_interval = beacon->beacon_interval; + /* Where to pull this? beacon->listen_interval;*/ + network->listen_interval = 0x0A; + network->rates_len = network->rates_ex_len = 0; + network->last_associate = 0; + network->ssid_len = 0; + network->flags = 0; + network->atim_window = 0; + + if (stats->freq == IEEE80211_52GHZ_BAND) { + /* for A band (No DS info) */ + network->channel = stats->received_channel; + } else + network->flags |= NETWORK_HAS_CCK; + +#ifdef CONFIG_IEEE80211_WPA + network->wpa_ie_len = 0; + network->rsn_ie_len = 0; +#endif /* CONFIG_IEEE80211_WPA */ + + info_element = &beacon->info_element; + left = stats->len - ((void *)info_element - (void *)beacon); + while (left >= sizeof(struct ieee80211_info_element_hdr)) { + if (sizeof(struct ieee80211_info_element_hdr) + info_element->len > left) { + IEEE80211_DEBUG_SCAN("SCAN: parse failed: info_element->len + 2 > left : info_element->len+2=%d left=%d.\n", + info_element->len + sizeof(struct ieee80211_info_element), + left); + return 1; + } + + switch (info_element->id) { + case MFIE_TYPE_SSID: + if (ieee80211_is_empty_essid(info_element->data, + info_element->len)) { + network->flags |= NETWORK_EMPTY_ESSID; + break; + } + + network->ssid_len = min(info_element->len, + (u8)IW_ESSID_MAX_SIZE); + memcpy(network->ssid, info_element->data, network->ssid_len); + if (network->ssid_len < IW_ESSID_MAX_SIZE) + memset(network->ssid + network->ssid_len, 0, + IW_ESSID_MAX_SIZE - network->ssid_len); + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_SSID: '%s' len=%d.\n", + network->ssid, network->ssid_len); + break; + + case MFIE_TYPE_RATES: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_len = min(info_element->len, MAX_RATES_LENGTH); + for (i = 0; i < network->rates_len; i++) { + network->rates[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES: '%s' (%d)\n", + rates_str, network->rates_len); + break; + + case MFIE_TYPE_RATES_EX: +#ifdef CONFIG_IEEE80211_DEBUG + p = rates_str; +#endif + network->rates_ex_len = min(info_element->len, MAX_RATES_EX_LENGTH); + for (i = 0; i < network->rates_ex_len; i++) { + network->rates_ex[i] = info_element->data[i]; +#ifdef CONFIG_IEEE80211_DEBUG + p += snprintf(p, sizeof(rates_str) - (p - rates_str), "%02X ", network->rates[i]); +#endif + if (ieee80211_is_ofdm_rate(info_element->data[i])) { + network->flags |= NETWORK_HAS_OFDM; + if (info_element->data[i] & + IEEE80211_BASIC_RATE_MASK) + network->flags &= + ~NETWORK_HAS_CCK; + } + } + + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RATES_EX: '%s' (%d)\n", + rates_str, network->rates_ex_len); + break; + + case MFIE_TYPE_DS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_DS_SET: %d\n", + info_element->data[0]); + if (stats->freq == IEEE80211_24GHZ_BAND) + network->channel = info_element->data[0]; + break; + + case MFIE_TYPE_FH_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_FH_SET: ignored\n"); + break; + + case MFIE_TYPE_CF_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CF_SET: ignored\n"); + break; + + case MFIE_TYPE_TIM: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_TIM: ignored\n"); + break; + + case MFIE_TYPE_IBSS_SET: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_IBSS_SET: ignored\n"); + break; + + case MFIE_TYPE_CHALLENGE: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_CHALLENGE: ignored\n"); + break; + +#ifdef CONFIG_IEEE80211_WPA + case MFIE_TYPE_GENERIC: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_GENERIC: %d bytes\n", + info_element->len); + if (info_element->len >= 4 && + info_element->data[0] == 0x00 && + info_element->data[1] == 0x50 && + info_element->data[2] == 0xf2 && + info_element->data[3] == 0x01) { + network->wpa_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->wpa_ie, info_element, + network->wpa_ie_len); + } + break; + + case MFIE_TYPE_RSN: + IEEE80211_DEBUG_SCAN("MFIE_TYPE_RSN: %d bytes\n", + info_element->len); + network->rsn_ie_len = min(info_element->len + 2, + MAX_WPA_IE_LEN); + memcpy(network->rsn_ie, info_element, + network->rsn_ie_len); + break; +#endif + + default: + IEEE80211_DEBUG_SCAN("unsupported IE %d\n", + info_element->id); + break; + } + + left -= sizeof(struct ieee80211_info_element_hdr) + + info_element->len; + info_element = (struct ieee80211_info_element *) + &info_element->data[info_element->len]; + } + + network->mode = 0; + if (stats->freq == IEEE80211_52GHZ_BAND) { + network->mode = IEEE_A; + } else { + if (network->flags & NETWORK_HAS_OFDM) + network->mode |= IEEE_G; + if (network->flags & NETWORK_HAS_CCK) + network->mode |= IEEE_B; + } + + if (network->mode == 0) { + IEEE80211_DEBUG_SCAN("Filtered out '%s (" MAC_FMT ")' " + "network.\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid)); + return 1; + } + + if (ieee80211_is_empty_essid(network->ssid, network->ssid_len)) + network->flags |= NETWORK_EMPTY_ESSID; + + memcpy(&network->stats, stats, sizeof(network->stats)); + + return 0; +} + +static inline int is_same_network(struct ieee80211_network *src, + struct ieee80211_network *dst) +{ + /* A network is only a duplicate if the channel, BSSID, and ESSID + * all match. We treat all with the same BSSID and channel + * as one network */ + return ((src->ssid_len == dst->ssid_len) && + (src->channel == dst->channel) && + !memcmp(src->bssid, dst->bssid, ETH_ALEN) && + !memcmp(src->ssid, dst->ssid, src->ssid_len)); +} + +static inline void update_network(struct ieee80211_network *dst, + struct ieee80211_network *src) +{ + memcpy(&dst->stats, &src->stats, sizeof(struct ieee80211_rx_stats)); + dst->capability = src->capability; + memcpy(dst->rates, src->rates, src->rates_len); + dst->rates_len = src->rates_len; + memcpy(dst->rates_ex, src->rates_ex, src->rates_ex_len); + dst->rates_ex_len = src->rates_ex_len; + + dst->mode = src->mode; + dst->flags = src->flags; + dst->time_stamp[0] = src->time_stamp[0]; + dst->time_stamp[1] = src->time_stamp[1]; + + dst->beacon_interval = src->beacon_interval; + dst->listen_interval = src->listen_interval; + dst->atim_window = src->atim_window; + +#ifdef CONFIG_IEEE80211_WPA + memcpy(dst->wpa_ie, src->wpa_ie, src->wpa_ie_len); + dst->wpa_ie_len = src->wpa_ie_len; + memcpy(dst->rsn_ie, src->rsn_ie, src->rsn_ie_len); + dst->rsn_ie_len = src->rsn_ie_len; +#endif /* CONFIG_IEEE80211_WPA */ + + dst->last_scanned = jiffies; + /* dst->last_associate is not overwritten */ +} + +static inline void ieee80211_process_probe_response( + struct ieee80211_device *ieee, + struct ieee80211_probe_response *beacon, + struct ieee80211_rx_stats *stats) +{ + struct ieee80211_network network; + struct ieee80211_network *target; + struct ieee80211_network *oldest = NULL; +#ifdef CONFIG_IEEE80211_DEBUG + struct ieee80211_info_element *info_element = &beacon->info_element; +#endif + + IEEE80211_DEBUG_SCAN( + "'%s' (" MAC_FMT "): %c%c%c%c %c%c%c%c-%c%c%c%c %c%c%c%c\n", + escape_essid(info_element->data, info_element->len), + MAC_ARG(beacon->header.addr3), + (beacon->capability & BIT(0xf)) ? '1' : '0', + (beacon->capability & BIT(0xe)) ? '1' : '0', + (beacon->capability & BIT(0xd)) ? '1' : '0', + (beacon->capability & BIT(0xc)) ? '1' : '0', + (beacon->capability & BIT(0xb)) ? '1' : '0', + (beacon->capability & BIT(0xa)) ? '1' : '0', + (beacon->capability & BIT(0x9)) ? '1' : '0', + (beacon->capability & BIT(0x8)) ? '1' : '0', + (beacon->capability & BIT(0x7)) ? '1' : '0', + (beacon->capability & BIT(0x6)) ? '1' : '0', + (beacon->capability & BIT(0x5)) ? '1' : '0', + (beacon->capability & BIT(0x4)) ? '1' : '0', + (beacon->capability & BIT(0x3)) ? '1' : '0', + (beacon->capability & BIT(0x2)) ? '1' : '0', + (beacon->capability & BIT(0x1)) ? '1' : '0', + (beacon->capability & BIT(0x0)) ? '1' : '0'); + + if (ieee80211_network_init(ieee, beacon, &network, stats)) { + IEEE80211_DEBUG_SCAN("Dropped '%s' (" MAC_FMT ") via %s.\n", + escape_essid(info_element->data, + info_element->len), + MAC_ARG(beacon->header.addr3), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + return; + } + + /* The network parsed correctly -- so now we scan our known networks + * to see if we can find it in our list. + * + * NOTE: This search is definitely not optimized. Once its doing + * the "right thing" we'll optimize it for efficiency if + * necessary */ + + /* Search for this entry in the list and update it if it is + * already there. */ + list_for_each_entry(target, &ieee->network_list, list) { + if (is_same_network(target, &network)) + break; + + if ((oldest == NULL) || + (target->last_scanned < oldest->last_scanned)) + oldest = target; + } + + /* If we didn't find a match, then get a new network slot to initialize + * with this beacon's information */ + if (&target->list == &ieee->network_list) { + if (list_empty(&ieee->network_free_list)) { + /* If there are no more slots, expire the oldest */ + list_del(&oldest->list); + target = oldest; + IEEE80211_DEBUG_SCAN("Expired '%s' (" MAC_FMT ") from " + "network list.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid)); + } else { + /* Otherwise just pull from the free list */ + target = list_entry(ieee->network_free_list.next, + struct ieee80211_network, list); + list_del(ieee->network_free_list.next); + } + + +#ifdef CONFIG_IEEE80211_DEBUG + IEEE80211_DEBUG_SCAN("Adding '%s' (" MAC_FMT ") via %s.\n", + escape_essid(network.ssid, + network.ssid_len), + MAC_ARG(network.bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); +#endif + memcpy(target, &network, sizeof(*target)); + list_add_tail(&target->list, &ieee->network_list); + } else { + IEEE80211_DEBUG_SCAN("Updating '%s' (" MAC_FMT ") via %s.\n", + escape_essid(target->ssid, + target->ssid_len), + MAC_ARG(target->bssid), + WLAN_FC_GET_STYPE(beacon->header.frame_ctl) == + IEEE80211_STYPE_PROBE_RESP ? + "PROBE RESPONSE" : "BEACON"); + update_network(target, &network); + } +} + +void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats) +{ + switch (WLAN_FC_GET_STYPE(header->frame_ctl)) { + case IEEE80211_STYPE_ASSOC_RESP: + IEEE80211_DEBUG_MGMT("received ASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_REASSOC_RESP: + IEEE80211_DEBUG_MGMT("received REASSOCIATION RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + + case IEEE80211_STYPE_PROBE_RESP: + IEEE80211_DEBUG_MGMT("received PROBE RESPONSE (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Probe response\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + case IEEE80211_STYPE_BEACON: + IEEE80211_DEBUG_MGMT("received BEACON (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_DEBUG_SCAN("Beacon\n"); + ieee80211_process_probe_response( + ieee, (struct ieee80211_probe_response *)header, stats); + break; + + default: + IEEE80211_DEBUG_MGMT("received UNKNOWN (%d)\n", + WLAN_FC_GET_STYPE(header->frame_ctl)); + IEEE80211_WARNING("%s: Unknown management packet: %d\n", + ieee->dev->name, + WLAN_FC_GET_STYPE(header->frame_ctl)); + break; + } +} + + +EXPORT_SYMBOL(ieee80211_rx_mgt); +EXPORT_SYMBOL(ieee80211_rx); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_tx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_tx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_tx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_tx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,464 @@ +/****************************************************************************** + + Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved. + + 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 as + published by the Free Software Foundation. + + 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. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../ieee80211.h" + + +/* + + +802.11 Data Frame + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | Frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `--------------------------------------------------| |------' +Total: 28 non-data bytes `----.----' + | + .- 'Frame data' expands to <---------------------------' + | + V + ,---------------------------------------------------. +Bytes | 1 | 1 | 1 | 3 | 2 | 0-2304 | + |------|------|---------|----------|------|---------| +Desc. | SNAP | SNAP | Control |Eth Tunnel| Type | IP | + | DSAP | SSAP | | | | Packet | + | 0xAA | 0xAA |0x03 (UI)|0x00-00-F8| | | + `-----------------------------------------| | +Total: 8 non-data bytes `----.----' + | + .- 'IP Packet' expands, if WEP enabled, to <--' + | + V + ,-----------------------. +Bytes | 4 | 0-2296 | 4 | + |-----|-----------|-----| +Desc. | IV | Encrypted | ICV | + | | IP Packet | | + `-----------------------' +Total: 8 non-data bytes + + +802.3 Ethernet Data Frame + + ,-----------------------------------------. +Bytes | 6 | 6 | 2 | Variable | 4 | + |-------|-------|------|-----------|------| +Desc. | Dest. | Source| Type | IP Packet | fcs | + | MAC | MAC | | | | + `-----------------------------------------' +Total: 18 non-data bytes + +In the event that fragmentation is required, the incoming payload is split into +N parts of size ieee->fts. The first fragment contains the SNAP header and the +remaining packets are just data. + +If encryption is enabled, each fragment payload size is reduced by enough space +to add the prefix and postfix (IV and ICV totalling 8 bytes in the case of WEP) +So if you have 1500 bytes of payload with ieee->fts set to 500 without +encryption it will take 3 frames. With WEP it will take 4 frames as the +payload of each frame is reduced to 492 bytes. + +* SKB visualization +* +* ,- skb->data +* | +* | ETHERNET HEADER ,-<-- PAYLOAD +* | | 14 bytes from skb->data +* | 2 bytes for Type --> ,T. | (sizeof ethhdr) +* | | | | +* |,-Dest.--. ,--Src.---. | | | +* | 6 bytes| | 6 bytes | | | | +* v | | | | | | +* 0 | v 1 | v | v 2 +* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +* ^ | ^ | ^ | +* | | | | | | +* | | | | `T' <---- 2 bytes for Type +* | | | | +* | | '---SNAP--' <-------- 6 bytes for SNAP +* | | +* `-IV--' <-------------------- 4 bytes for IV (WEP) +* +* SNAP HEADER +* +*/ + +static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; +static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; + +static inline int ieee80211_put_snap(u8 *data, u16 h_proto) +{ + struct ieee80211_snap_hdr *snap; + u8 *oui; + + snap = (struct ieee80211_snap_hdr *)data; + snap->dsap = 0xaa; + snap->ssap = 0xaa; + snap->ctrl = 0x03; + + if (h_proto == 0x8137 || h_proto == 0x80f3) + oui = P802_1H_OUI; + else + oui = RFC1042_OUI; + snap->oui[0] = oui[0]; + snap->oui[1] = oui[1]; + snap->oui[2] = oui[2]; + + *(u16 *)(data + SNAP_SIZE) = htons(h_proto); + + return SNAP_SIZE + sizeof(u16); +} + +#ifdef CONFIG_IEEE80211_CRYPT +static inline int ieee80211_encrypt_fragment( + struct ieee80211_device *ieee, + struct sk_buff *frag, + int hdr_len) +{ + struct ieee80211_crypt_data* crypt = ieee->crypt[ieee->tx_keyidx]; + int res; +#ifdef CONFIG_IEEE80211_WPA + struct ieee80211_hdr *header; + + if (ieee->tkip_countermeasures && + crypt && crypt->ops && strcmp(crypt->ops->name, "TKIP") == 0) { + header = (struct ieee80211_hdr *) frag->data; + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " + "TX packet to " MAC_FMT "\n", + ieee->dev->name, MAC_ARG(header->addr1)); + } + return -1; + } +#endif + /* To encrypt, frame format is: + * IV (4 bytes), clear payload (including SNAP), ICV (4 bytes) */ + + // PR: FIXME: Copied from hostap. Check fragmentation/MSDU/MPDU encryption. + /* Host-based IEEE 802.11 fragmentation for TX is not yet supported, so + * call both MSDU and MPDU encryption functions from here. */ + atomic_inc(&crypt->refcnt); + res = 0; + if (crypt->ops->encrypt_msdu) + res = crypt->ops->encrypt_msdu(frag, hdr_len, crypt->priv); + if (res == 0 && crypt->ops->encrypt_mpdu) + res = crypt->ops->encrypt_mpdu(frag, hdr_len, crypt->priv); + + atomic_dec(&crypt->refcnt); + if (res < 0) { + printk(KERN_INFO "%s: Encryption failed: len=%d.\n", + ieee->dev->name, frag->len); + ieee->ieee_stats.tx_discards++; + return -1; + } + + return 0; +} +#endif + + +void ieee80211_txb_free(struct ieee80211_txb *txb) { + int i; + if (unlikely(!txb)) + return; + for (i = 0; i < txb->nr_frags; i++) + if (txb->fragments[i]) + dev_kfree_skb_any(txb->fragments[i]); + kfree(txb); +} + +struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size, + int gfp_mask) +{ + struct ieee80211_txb *txb; + int i; + txb = kmalloc( + sizeof(struct ieee80211_txb) + (sizeof(u8*) * nr_frags), + gfp_mask); + if (!txb) + return NULL; + + memset(txb, sizeof(struct ieee80211_txb), 0); + txb->nr_frags = nr_frags; + txb->frag_size = txb_size; + + for (i = 0; i < nr_frags; i++) { + txb->fragments[i] = dev_alloc_skb(txb_size); + if (unlikely(!txb->fragments[i])) { + i--; + break; + } + } + if (unlikely(i != nr_frags)) { + while (i >= 0) + dev_kfree_skb_any(txb->fragments[i--]); + kfree(txb); + return NULL; + } + return txb; +} + +/* SKBs are added to the ieee->tx_queue. */ +int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_txb *txb = NULL; + struct ieee80211_hdr *frag_hdr; + int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size; + unsigned long flags; + struct net_device_stats *stats = &ieee->stats; + int ether_type, encrypt; + int bytes, fc, hdr_len; + struct sk_buff *skb_frag; + struct ieee80211_hdr header; + u8 dest[ETH_ALEN], src[ETH_ALEN]; + +#ifdef CONFIG_IEEE80211_CRYPT + struct ieee80211_crypt_data* crypt; +#endif + + spin_lock_irqsave(&ieee->lock, flags); + + /* If there is no driver handler to take the TXB, dont' bother + * creating it... */ + if (!ieee->hard_start_xmit) { + printk(KERN_WARNING "%s: No xmit handler.\n", + ieee->dev->name); + goto success; + } + + if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { + printk(KERN_WARNING "%s: skb too small (%d).\n", + ieee->dev->name, skb->len); + goto success; + } + + ether_type = ntohs(((struct ethhdr *)skb->data)->h_proto); + +#ifndef CONFIG_IEEE80211_CRYPT + encrypt = 0; +#else /* CONFIG_IEEE80211_CRYPT */ + crypt = ieee->crypt[ieee->tx_keyidx]; + +#ifndef CONFIG_IEEE80211_WPA + encrypt = (ether_type != ETH_P_PAE) && + ieee->host_encrypt && crypt && crypt->ops; + +#else /* CONFIG_IEEE80211_WPA */ + encrypt = !(ether_type == ETH_P_PAE && ieee->ieee802_1x) && + ieee->host_encrypt && crypt && crypt->ops; + + if (!encrypt && ieee->ieee802_1x && + ieee->drop_unencrypted && ether_type != ETH_P_PAE) { + stats->tx_dropped++; + goto success; + } + +#endif /* CONFIG_IEEE80211_WPA */ +#ifdef CONFIG_IEEE80211_DEBUG + if (crypt && !encrypt && ether_type == ETH_P_PAE) { + struct eapol *eap = (struct eapol *)(skb->data + + sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16)); + IEEE80211_DEBUG_EAP("TX: IEEE 802.11 EAPOL frame: %s\n", + eap_get_type(eap->type)); + } +#endif +#endif /* CONFIG_IEEE80211_CRYPT */ + + /* Save source and destination addresses */ + memcpy(&dest, skb->data, ETH_ALEN); + memcpy(&src, skb->data+ETH_ALEN, ETH_ALEN); + + /* Advance the SKB to the start of the payload */ + skb_pull(skb, sizeof(struct ethhdr)); + + /* Determine total amount of storage required for TXB packets */ + bytes = skb->len + SNAP_SIZE + sizeof(u16); + + if (encrypt) + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | + IEEE80211_FCTL_WEP; + else + fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(&header.addr1, ieee->bssid, ETH_ALEN); + memcpy(&header.addr2, &src, ETH_ALEN); + memcpy(&header.addr3, &dest, ETH_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + memcpy(&header.addr1, dest, ETH_ALEN); + memcpy(&header.addr2, src, ETH_ALEN); + memcpy(&header.addr3, ieee->bssid, ETH_ALEN); + } + header.frame_ctl = cpu_to_le16(fc); + hdr_len = IEEE80211_3ADDR_LEN; + + /* Determine fragmentation size based on destination (multicast + * and broadcast are not fragmented) */ + if (is_multicast_ether_addr(dest) || + is_broadcast_ether_addr(dest)) + frag_size = MAX_FRAG_THRESHOLD; + else + frag_size = ieee->fts; + + /* Determine amount of payload per fragment. Regardless of if + * this stack is providing the full 802.11 header, one will + * eventually be affixed to this fragment -- so we must account for + * it when determining the amount of payload space. */ + bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN; + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + bytes_per_frag -= IEEE80211_FCS_LEN; + +#ifdef CONFIG_IEEE80211_CRYPT + /* Each fragment may need to have room for encryptiong pre/postfix */ + if (encrypt) + bytes_per_frag -= crypt->ops->extra_prefix_len + + crypt->ops->extra_postfix_len; +#endif + + /* Number of fragments is the total bytes_per_frag / + * payload_per_fragment */ + nr_frags = bytes / bytes_per_frag; + bytes_last_frag = bytes % bytes_per_frag; + if (bytes_last_frag) + nr_frags++; + else + bytes_last_frag = bytes_per_frag; + + /* When we allocate the TXB we allocate enough space for the reserve + * and full fragment bytes (bytes_per_frag doesn't include prefix, + * postfix, header, FCS, etc.) */ + txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC); + if (unlikely(!txb)) { + printk(KERN_WARNING "%s: Could not allocate TXB\n", + ieee->dev->name); + goto failed; + } + txb->encrypted = encrypt; + txb->payload_size = bytes; + + for (i = 0; i < nr_frags; i++) { + skb_frag = txb->fragments[i]; + +#ifdef CONFIG_IEEE80211_CRYPT + if (encrypt) + skb_reserve(skb_frag, crypt->ops->extra_prefix_len); +#endif + + frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); + memcpy(frag_hdr, &header, hdr_len); + + /* If this is not the last fragment, then add the MOREFRAGS + * bit to the frame control */ + if (i != nr_frags - 1) { + frag_hdr->frame_ctl = cpu_to_le16( + fc | IEEE80211_FCTL_MOREFRAGS); + bytes = bytes_per_frag; + } else { + /* The last fragment takes the remaining length */ + bytes = bytes_last_frag; + } + + /* Put a SNAP header on the first fragment */ + if (i == 0) { + ieee80211_put_snap( + skb_put(skb_frag, SNAP_SIZE + sizeof(u16)), + ether_type); + bytes -= SNAP_SIZE + sizeof(u16); + } + + memcpy(skb_put(skb_frag, bytes), skb->data, bytes); + + /* Advance the SKB... */ + skb_pull(skb, bytes); + +#ifdef CONFIG_IEEE80211_CRYPT + /* Encryption routine will move the header forward in order + * to insert the IV between the header and the payload */ + if (encrypt) + ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len); +#endif + if (ieee->config & + (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) + skb_put(skb_frag, 4); + } + + + success: + spin_unlock_irqrestore(&ieee->lock, flags); + + dev_kfree_skb_any(skb); + + if (txb) { + if ((*ieee->hard_start_xmit)(txb, dev) == 0) { + stats->tx_packets++; + stats->tx_bytes += txb->payload_size; + return 0; + } + ieee80211_txb_free(txb); + } + + return 0; + + failed: + spin_unlock_irqrestore(&ieee->lock, flags); + netif_stop_queue(dev); + stats->tx_errors++; + return 1; + +} + +EXPORT_SYMBOL(ieee80211_txb_free); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_wx.c netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_wx.c --- netdev-2.6/drivers/net/wireless/ieee80211/ieee80211_wx.c 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211/ieee80211_wx.c 2005-02-04 10:20:03 -06:00 @@ -0,0 +1,526 @@ +/****************************************************************************** + + Copyright(c) 2004 Intel Corporation. All rights reserved. + + Portions of this file are based on the WEP enablement code provided by the + Host AP project hostap-drivers v0.1.3 + Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + + Copyright (c) 2002-2003, Jouni Malinen + + 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 as + published by the Free Software Foundation. + + 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. + + Contact Information: + James P. Ketrenos + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +******************************************************************************/ +#include +#include +#include +#include + +#include "../ieee80211.h" +static const char *ieee80211_modes[] = { + "?", "a", "b", "ab", "g", "ag", "bg", "abg" +}; + +#if 0 +static u32 ieee80211_frequency(u8 channel, u8 mode) +{ + if (mode == IEEE_A) { + if (channel >= 8 && channel <= 161) + return 5000000 + 5000 * channel; + + if (channel >= 240 && channel <= 252) + return 4960000 + 5000 * (channel - 240); + } + + if (channel == 14) + return 2484000; + + if (channel >= 1 && channel <= 13) + return 2407000 + 5000 * channel; + + return 0; +} +#endif + +#define MAX_CUSTOM_LEN 64 +static inline char *ipw2100_translate_scan(struct ieee80211_device *ieee, + char *start, char *stop, + struct ieee80211_network *network) +{ + char custom[MAX_CUSTOM_LEN]; + char *p; + struct iw_event iwe; + int i, j; + u8 max_rate, rate; + + /* First entry *MUST* be the AP MAC address */ + iwe.cmd = SIOCGIWAP; + iwe.u.ap_addr.sa_family = ARPHRD_ETHER; + memcpy(iwe.u.ap_addr.sa_data, network->bssid, ETH_ALEN); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_ADDR_LEN); + + /* Remaining entries will be displayed in the order we provide them */ + + /* Add the ESSID */ + iwe.cmd = SIOCGIWESSID; + iwe.u.data.flags = 1; + if (network->flags & NETWORK_EMPTY_ESSID) { + iwe.u.data.length = sizeof(""); + start = iwe_stream_add_point(start, stop, &iwe, ""); + } else { + iwe.u.data.length = min(network->ssid_len, (u8)32); + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + } + + /* Add the protocol name */ + iwe.cmd = SIOCGIWNAME; + snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11%s", ieee80211_modes[network->mode]); + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_CHAR_LEN); + + /* Add mode */ + iwe.cmd = SIOCGIWMODE; + if (network->capability & + (WLAN_CAPABILITY_BSS | WLAN_CAPABILITY_IBSS)) { + if (network->capability & WLAN_CAPABILITY_BSS) + iwe.u.mode = IW_MODE_MASTER; + else + iwe.u.mode = IW_MODE_ADHOC; + + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_UINT_LEN); + } + + /* Add frequency/channel */ + iwe.cmd = SIOCGIWFREQ; +/* iwe.u.freq.m = ieee80211_frequency(network->channel, network->mode); + iwe.u.freq.e = 3; */ + iwe.u.freq.m = network->channel; + iwe.u.freq.e = 0; + iwe.u.freq.i = 0; + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_FREQ_LEN); + + /* Add encryption capability */ + iwe.cmd = SIOCGIWENCODE; + if (network->capability & WLAN_CAPABILITY_PRIVACY) + iwe.u.data.flags = IW_ENCODE_ENABLED | IW_ENCODE_NOKEY; + else + iwe.u.data.flags = IW_ENCODE_DISABLED; + iwe.u.data.length = 0; + start = iwe_stream_add_point(start, stop, &iwe, network->ssid); + + /* Add basic and extended rates */ + max_rate = 0; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), " Rates (Mb/s): "); + for (i = 0, j = 0; i < network->rates_len; ) { + if (j < network->rates_ex_len && + ((network->rates_ex[j] & 0x7F) < + (network->rates[i] & 0x7F))) + rate = network->rates_ex[j++] & 0x7F; + else + rate = network->rates[i++] & 0x7F; + if (rate > max_rate) + max_rate = rate; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + } + for (; j < network->rates_ex_len; j++) { + rate = network->rates_ex[j] & 0x7F; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + "%d%s ", rate >> 1, (rate & 1) ? ".5" : ""); + if (rate > max_rate) + max_rate = rate; + } + + iwe.cmd = SIOCGIWRATE; + iwe.u.bitrate.fixed = iwe.u.bitrate.disabled = 0; + iwe.u.bitrate.value = max_rate * 500000; + start = iwe_stream_add_event(start, stop, &iwe, + IW_EV_PARAM_LEN); + + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + /* Add quality statistics */ + /* TODO: Fix these values... */ + iwe.cmd = IWEVQUAL; + iwe.u.qual.qual = network->stats.signal; + iwe.u.qual.level = network->stats.rssi; + iwe.u.qual.noise = network->stats.noise; + iwe.u.qual.updated = network->stats.mask & IEEE80211_STATMASK_WEMASK; + if (!(network->stats.mask & IEEE80211_STATMASK_RSSI)) + iwe.u.qual.updated |= IW_QUAL_LEVEL_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_NOISE)) + iwe.u.qual.updated |= IW_QUAL_NOISE_INVALID; + if (!(network->stats.mask & IEEE80211_STATMASK_SIGNAL)) + iwe.u.qual.updated |= IW_QUAL_QUAL_INVALID; + + start = iwe_stream_add_event(start, stop, &iwe, IW_EV_QUAL_LEN); + + iwe.cmd = IWEVCUSTOM; + p = custom; + +#if 0 + if (network->stats.mask & IEEE80211_STATMASK_RSSI) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " RSSI: %-4d dBm ", + (s8)network->stats.rssi); + + if (network->stats.mask & IEEE80211_STATMASK_NOISE) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Noise: %-4d dBm ", + (s8)network->stats.noise); + + if (network->stats.mask & IEEE80211_STATMASK_SIGNAL) + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Signal: %-4d dBm ", + (s8)network->stats.signal); +#endif + + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + +#ifdef CONFIG_IEEE80211_WPA + if (ieee->wpa_enabled && network->wpa_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "wpa_ie="); + for (i = 0; i < network->wpa_ie_len; i++) { + p += sprintf(p, "%02x", network->wpa_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + + if (ieee->wpa_enabled && network->rsn_ie_len){ + char buf[MAX_WPA_IE_LEN * 2 + 30]; + + u8 *p = buf; + p += sprintf(p, "rsn_ie="); + for (i = 0; i < network->rsn_ie_len; i++) { + p += sprintf(p, "%02x", network->rsn_ie[i]); + } + + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + iwe.u.data.length = strlen(buf); + start = iwe_stream_add_point(start, stop, &iwe, buf); + } + +#endif /* CONFIG_IEEE80211_WPA */ + + /* Add EXTRA: Age to display seconds since last beacon/probe response + * for given network. */ + iwe.cmd = IWEVCUSTOM; + p = custom; + p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), + " Last beacon: %lums ago", (jiffies - network->last_scanned) / (HZ / 100)); + iwe.u.data.length = p - custom; + if (iwe.u.data.length) + start = iwe_stream_add_point(start, stop, &iwe, custom); + + + return start; +} + +int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *extra) +{ + struct ieee80211_network *network; + unsigned long flags; + + char *ev = extra; + char *stop = ev + IW_SCAN_MAX_DATA; + int i = 0; + + IEEE80211_DEBUG_WX("Getting scan\n"); + + spin_lock_irqsave(&ieee->lock, flags); + + list_for_each_entry(network, &ieee->network_list, list) { + i++; + if (ieee->scan_age == 0 || + time_after(network->last_scanned + ieee->scan_age, jiffies)) + ev = ipw2100_translate_scan(ieee, ev, stop, network); + else + IEEE80211_DEBUG_SCAN( + "Not showing network '%s (" + MAC_FMT ")' due to age (%lums).\n", + escape_essid(network->ssid, + network->ssid_len), + MAC_ARG(network->bssid), + (jiffies - network->last_scanned) / (HZ / 100)); + } + + spin_unlock_irqrestore(&ieee->lock, flags); + + wrqu->data.length = ev - extra; + wrqu->data.flags = 0; + + IEEE80211_DEBUG_WX("exit: %d networks returned.\n", i); + + return 0; +} + +int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); +#ifndef CONFIG_IEEE80211_CRYPT + if (erq->flags & IW_ENCODE_DISABLED) + return 0; + return -EOPNOTSUPP; +#else + struct net_device *dev = ieee->dev; + struct ieee80211_security sec = { + .flags = 0 + }; + int i, key, key_provided, len; + struct ieee80211_crypt_data **crypt; + + IEEE80211_DEBUG_WX("SET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + key_provided = 1; + } else { + key_provided = 0; + key = ieee->tx_keyidx; + } + + IEEE80211_DEBUG_WX("Key: %d [%s]\n", key, key_provided ? + "provided" : "default"); + + crypt = &ieee->crypt[key]; + + if (erq->flags & IW_ENCODE_DISABLED) { + if (key_provided && *crypt) { + IEEE80211_DEBUG_WX("Disabling encryption on key %d.\n", + key); + ieee80211_crypt_delayed_deinit(ieee, crypt); + } else + IEEE80211_DEBUG_WX("Disabling encryption.\n"); + + /* Check all the keys to see if any are still configured, + * and if no key index was provided, de-init them all */ + for (i = 0; i < WEP_KEYS; i++) { + if (ieee->crypt[i] != NULL) { + if (key_provided) + break; + ieee80211_crypt_delayed_deinit( + ieee, &ieee->crypt[i]); + } + } + + if (i == WEP_KEYS) { + sec.enabled = 0; + sec.level = SEC_LEVEL_0; + sec.flags |= SEC_ENABLED | SEC_LEVEL; + } + + goto done; + } + + + + sec.enabled = 1; + sec.flags |= SEC_ENABLED; + + if (*crypt != NULL && (*crypt)->ops != NULL && + strcmp((*crypt)->ops->name, "WEP") != 0) { + /* changing to use WEP; deinit previously used algorithm + * on this key */ + ieee80211_crypt_delayed_deinit(ieee, crypt); + } + + if (*crypt == NULL) { + struct ieee80211_crypt_data *new_crypt; + + /* take WEP into use */ + new_crypt = kmalloc(sizeof(struct ieee80211_crypt_data), + GFP_KERNEL); + if (new_crypt == NULL) + return -ENOMEM; + memset(new_crypt, 0, sizeof(struct ieee80211_crypt_data)); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + if (!new_crypt->ops) { + request_module("ieee80211_crypt_wep"); + new_crypt->ops = ieee80211_get_crypto_ops("WEP"); + } + + if (new_crypt->ops && try_module_get(new_crypt->ops->owner)) + new_crypt->priv = new_crypt->ops->init(key); + + if (!new_crypt->ops || !new_crypt->priv) { + kfree(new_crypt); + new_crypt = NULL; + + printk(KERN_WARNING "%s: could not initialize WEP: " + "load module ieee80211_crypt_wep\n", + dev->name); + return -EOPNOTSUPP; + } + *crypt = new_crypt; + } + + /* If a new key was provided, set it up */ + if (erq->length > 0) { + len = erq->length <= 5 ? 5 : 13; + memcpy(sec.keys[key], keybuf, erq->length); + if (len > erq->length) + memset(sec.keys[key] + erq->length, 0, + len - erq->length); + IEEE80211_DEBUG_WX("Setting key %d to '%s' (%d:%d bytes)\n", + key, escape_essid(sec.keys[key], len), + erq->length, len); + sec.key_sizes[key] = len; + (*crypt)->ops->set_key(sec.keys[key], len, NULL, + (*crypt)->priv); + sec.flags |= (1 << key); + /* This ensures a key will be activated if no key is + * explicitely set */ + if (key == sec.active_key) + sec.flags |= SEC_ACTIVE_KEY; + } else { + len = (*crypt)->ops->get_key(sec.keys[key], WEP_KEY_LEN, + NULL, (*crypt)->priv); + if (len == 0) { + /* Set a default key of all 0 */ + IEEE80211_DEBUG_WX("Setting key %d to all zero.\n", + key); + memset(sec.keys[key], 0, 13); + (*crypt)->ops->set_key(sec.keys[key], 13, NULL, + (*crypt)->priv); + sec.key_sizes[key] = 13; + sec.flags |= (1 << key); + } + + /* No key data - just set the default TX key index */ + if (key_provided) { + IEEE80211_DEBUG_WX( + "Setting key %d to default Tx key.\n", key); + ieee->tx_keyidx = key; + sec.active_key = key; + sec.flags |= SEC_ACTIVE_KEY; + } + } + + done: + ieee->open_wep = !(erq->flags & IW_ENCODE_RESTRICTED); + sec.auth_mode = ieee->open_wep ? WLAN_AUTH_OPEN : WLAN_AUTH_SHARED_KEY; + sec.flags |= SEC_AUTH_MODE; + IEEE80211_DEBUG_WX("Auth: %s\n", sec.auth_mode == WLAN_AUTH_OPEN ? + "OPEN" : "SHARED KEY"); + + /* For now we just support WEP, so only set that security level... + * TODO: When WPA is added this is one place that needs to change */ + sec.flags |= SEC_LEVEL; + sec.level = SEC_LEVEL_1; /* 40 and 104 bit WEP */ + + if (ieee->set_security) + ieee->set_security(dev, &sec); + + /* Do not reset port if card is in Managed mode since resetting will + * generate new IEEE 802.11 authentication which may end up in looping + * with IEEE 802.1X. If your hardware requires a reset after WEP + * configuration (for example... Prism2), implement the reset_port in + * the callbacks structures used to initialize the 802.11 stack. */ + if (ieee->reset_on_keychange && + ieee->iw_mode != IW_MODE_INFRA && + ieee->reset_port && ieee->reset_port(dev)) { + printk(KERN_DEBUG "%s: reset_port failed\n", dev->name); + return -EINVAL; + } + return 0; +#endif +} + +int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *keybuf) +{ + struct iw_point *erq = &(wrqu->encoding); +#ifndef CONFIG_IEEE80211_CRYPT + printk(KERN_WARNING "%s: Encryption requested but not enabled in " + "build.\n", ieee->dev->name); + erq->length = 0; + erq->flags = IW_ENCODE_DISABLED; + return 0; +#else + int len, key; + struct ieee80211_crypt_data *crypt; + + IEEE80211_DEBUG_WX("GET_ENCODE\n"); + + key = erq->flags & IW_ENCODE_INDEX; + if (key) { + if (key > WEP_KEYS) + return -EINVAL; + key--; + } else + key = ieee->tx_keyidx; + + crypt = ieee->crypt[key]; + erq->flags = key + 1; + + if (crypt == NULL || crypt->ops == NULL) { + erq->length = 0; + erq->flags |= IW_ENCODE_DISABLED; + return 0; + } + + if (strcmp(crypt->ops->name, "WEP") != 0) { + /* only WEP is supported with wireless extensions, so just + * report that encryption is used */ + erq->length = 0; + erq->flags |= IW_ENCODE_ENABLED; + return 0; + } + + len = crypt->ops->get_key(keybuf, WEP_KEY_LEN, NULL, crypt->priv); + erq->length = (len >= 0 ? len : 0); + + erq->flags |= IW_ENCODE_ENABLED; + + if (ieee->open_wep) + erq->flags |= IW_ENCODE_OPEN; + else + erq->flags |= IW_ENCODE_RESTRICTED; + + return 0; +#endif +} + +EXPORT_SYMBOL(ieee80211_wx_get_scan); +EXPORT_SYMBOL(ieee80211_wx_set_encode); +EXPORT_SYMBOL(ieee80211_wx_get_encode); diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/drivers/net/wireless/ieee80211.h netdev-2.6-ipw/drivers/net/wireless/ieee80211.h --- netdev-2.6/drivers/net/wireless/ieee80211.h 1969-12-31 18:00:00 -06:00 +++ netdev-2.6-ipw/drivers/net/wireless/ieee80211.h 2005-02-04 10:20:02 -06:00 @@ -0,0 +1,888 @@ +/* + * Merged with mainline ieee80211.h in Aug 2004. Original ieee802_11 + * remains copyright by the original authors + * + * Portions of the merged code are based on Host AP (software wireless + * LAN access point) driver for Intersil Prism2/2.5/3. + * + * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen + * + * Copyright (c) 2002-2003, Jouni Malinen + * + * Adaption to a generic IEEE 802.11 stack by James Ketrenos + * + * Copyright (c) 2004, Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. See README and COPYING for + * more details. + */ +#ifndef IEEE80211_H +#define IEEE80211_H +#include /* ETH_ALEN */ +#include /* ARRAY_SIZE */ + +#if WIRELESS_EXT < 17 +#define IW_QUAL_QUAL_INVALID 0x10 +#define IW_QUAL_LEVEL_INVALID 0x20 +#define IW_QUAL_NOISE_INVALID 0x40 +#define IW_QUAL_QUAL_UPDATED 0x1 +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define IW_QUAL_NOISE_UPDATED 0x4 +#endif + +#define IEEE80211_DATA_LEN 2304 +/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section + 6.2.1.1.2. + + The figure in section 7.1.2 suggests a body size of up to 2312 + bytes is allowed, which is a bit confusing, I suspect this + represents the 2304 bytes of real data, plus a possible 8 bytes of + WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ + + +#define IEEE80211_HLEN 30 +#define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN) + +struct ieee80211_hdr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; + u8 addr4[ETH_ALEN]; +} __attribute__ ((packed)); + +struct ieee80211_hdr_3addr { + u16 frame_ctl; + u16 duration_id; + u8 addr1[ETH_ALEN]; + u8 addr2[ETH_ALEN]; + u8 addr3[ETH_ALEN]; + u16 seq_ctl; +} __attribute__ ((packed)); + +static const char *eap_types[] = { + "EAP-Packet", "EAPOL-Start", "EAPOL-Logoff", "EAPOL-Key", + "EAPOL-Encap-ASF-Alert", "Unknown" +}; + +static inline const char *eap_get_type(int type) +{ + if (type > ARRAY_SIZE(eap_types)) + type = ARRAY_SIZE(eap_types) - 1; + return eap_types[type]; +} + +struct eapol { + u8 snap[6]; + u16 ethertype; + u8 version; + u8 type; + u16 length; +} __attribute__ ((packed)); + +#define IEEE80211_3ADDR_LEN (24) +#define IEEE80211_4ADDR_LEN (30) +#define IEEE80211_FCS_LEN (4) + +#define MIN_FRAG_THRESHOLD 256U +#define MAX_FRAG_THRESHOLD 2346U + +/* Frame control field constants */ +#define IEEE80211_FCTL_VERS 0x0002 +#define IEEE80211_FCTL_FTYPE 0x000c +#define IEEE80211_FCTL_STYPE 0x00f0 +#define IEEE80211_FCTL_TODS 0x0100 +#define IEEE80211_FCTL_FROMDS 0x0200 +#define IEEE80211_FCTL_MOREFRAGS 0x0400 +#define IEEE80211_FCTL_RETRY 0x0800 +#define IEEE80211_FCTL_PM 0x1000 +#define IEEE80211_FCTL_MOREDATA 0x2000 +#define IEEE80211_FCTL_WEP 0x4000 +#define IEEE80211_FCTL_ORDER 0x8000 + +#define IEEE80211_FTYPE_MGMT 0x0000 +#define IEEE80211_FTYPE_CTL 0x0004 +#define IEEE80211_FTYPE_DATA 0x0008 + +/* management */ +#define IEEE80211_STYPE_ASSOC_REQ 0x0000 +#define IEEE80211_STYPE_ASSOC_RESP 0x0010 +#define IEEE80211_STYPE_REASSOC_REQ 0x0020 +#define IEEE80211_STYPE_REASSOC_RESP 0x0030 +#define IEEE80211_STYPE_PROBE_REQ 0x0040 +#define IEEE80211_STYPE_PROBE_RESP 0x0050 +#define IEEE80211_STYPE_BEACON 0x0080 +#define IEEE80211_STYPE_ATIM 0x0090 +#define IEEE80211_STYPE_DISASSOC 0x00A0 +#define IEEE80211_STYPE_AUTH 0x00B0 +#define IEEE80211_STYPE_DEAUTH 0x00C0 + +/* control */ +#define IEEE80211_STYPE_PSPOLL 0x00A0 +#define IEEE80211_STYPE_RTS 0x00B0 +#define IEEE80211_STYPE_CTS 0x00C0 +#define IEEE80211_STYPE_ACK 0x00D0 +#define IEEE80211_STYPE_CFEND 0x00E0 +#define IEEE80211_STYPE_CFENDACK 0x00F0 + +/* data */ +#define IEEE80211_STYPE_DATA 0x0000 +#define IEEE80211_STYPE_DATA_CFACK 0x0010 +#define IEEE80211_STYPE_DATA_CFPOLL 0x0020 +#define IEEE80211_STYPE_DATA_CFACKPOLL 0x0030 +#define IEEE80211_STYPE_NULLFUNC 0x0040 +#define IEEE80211_STYPE_CFACK 0x0050 +#define IEEE80211_STYPE_CFPOLL 0x0060 +#define IEEE80211_STYPE_CFACKPOLL 0x0070 + +#define IEEE80211_SCTL_FRAG 0x000F +#define IEEE80211_SCTL_SEQ 0xFFF0 + + +/* debug macros */ + +#ifdef CONFIG_IEEE80211_DEBUG +extern u32 ieee80211_debug_level; +#define IEEE80211_DEBUG(level, fmt, args...) \ +do { if (ieee80211_debug_level & (level)) \ + printk(KERN_DEBUG "ieee80211: %c %s " fmt, \ + in_interrupt() ? 'I' : 'U', __FUNCTION__ , ## args); } while (0) +#else +#define IEEE80211_DEBUG(level, fmt, args...) do {} while (0); +#endif /* CONFIG_IEEE80211_DEBUG */ + +/* + * To use the debug system; + * + * If you are defining a new debug classification, simply add it to the #define + * list here in the form of: + * + * #define IEEE80211_DL_xxxx VALUE + * + * shifting value to the left one bit from the previous entry. xxxx should be + * the name of the classification (for example, WEP) + * + * You then need to either add a IEEE80211_xxxx_DEBUG() macro definition for your + * classification, or use IEEE80211_DEBUG(IEEE80211_DL_xxxx, ...) whenever you want + * to send output to that classification. + * + * To add your debug level to the list of levels seen when you perform + * + * % cat /proc/net/ipw/debug_level + * + * you simply need to add your entry to the ipw_debug_levels array. + * + * If you do not see debug_level in /proc/net/ipw then you do not have + * CONFIG_IEEE80211_DEBUG defined in your kernel configuration + * + */ + +#define IEEE80211_DL_INFO BIT(0) +#define IEEE80211_DL_WX BIT(1) +#define IEEE80211_DL_SCAN BIT(2) +#define IEEE80211_DL_STATE BIT(3) +#define IEEE80211_DL_MGMT BIT(4) +#define IEEE80211_DL_FRAG BIT(5) +#define IEEE80211_DL_EAP BIT(6) +#define IEEE80211_DL_DROP BIT(7) + +#define IEEE80211_DL_TX BIT(8) +#define IEEE80211_DL_RX BIT(9) + +#define IEEE80211_ERROR(f, a...) printk(KERN_ERR "ieee80211: " f, ## a) +#define IEEE80211_WARNING(f, a...) printk(KERN_WARNING "ieee80211: " f, ## a) +#define IEEE80211_DEBUG_INFO(f, a...) IEEE80211_DEBUG(IEEE80211_DL_INFO, f, ## a) + +#define IEEE80211_DEBUG_WX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_WX, f, ## a) +#define IEEE80211_DEBUG_SCAN(f, a...) IEEE80211_DEBUG(IEEE80211_DL_SCAN, f, ## a) +#define IEEE80211_DEBUG_STATE(f, a...) IEEE80211_DEBUG(IEEE80211_DL_STATE, f, ## a) +#define IEEE80211_DEBUG_MGMT(f, a...) IEEE80211_DEBUG(IEEE80211_DL_MGMT, f, ## a) +#define IEEE80211_DEBUG_FRAG(f, a...) IEEE80211_DEBUG(IEEE80211_DL_FRAG, f, ## a) +#define IEEE80211_DEBUG_EAP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_EAP, f, ## a) +#define IEEE80211_DEBUG_DROP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_DROP, f, ## a) +#define IEEE80211_DEBUG_TX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_TX, f, ## a) +#define IEEE80211_DEBUG_RX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_RX, f, ## a) +#include +#include +#include /* ARPHRD_ETHER */ + +#ifndef WIRELESS_SPY +#define WIRELESS_SPY // enable iwspy support +#endif +#include // new driver API + +#define BIT(x) (1 << (x)) +#ifndef ETH_P_PAE +#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ +#endif /* ETH_P_PAE */ + +#define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ + +#ifndef ETH_P_80211_RAW +#define ETH_P_80211_RAW (ETH_P_ECONET + 1) +#endif + +/* IEEE 802.11 defines */ + +#define P80211_OUI_LEN 3 + +struct ieee80211_snap_hdr { + + u8 dsap; /* always 0xAA */ + u8 ssap; /* always 0xAA */ + u8 ctrl; /* always 0x03 */ + u8 oui[P80211_OUI_LEN]; /* organizational universal id */ + +} __attribute__ ((packed)); + +#define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) + +#define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) +#define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) + +#define WLAN_GET_SEQ_FRAG(seq) ((seq) & IEEE80211_SCTL_FRAG) +#define WLAN_GET_SEQ_SEQ(seq) ((seq) & IEEE80211_SCTL_SEQ) + +/* Authentication algorithms */ +#define WLAN_AUTH_OPEN 0 +#define WLAN_AUTH_SHARED_KEY 1 + +#define WLAN_AUTH_CHALLENGE_LEN 128 + +#define WLAN_CAPABILITY_BSS BIT(0) +#define WLAN_CAPABILITY_IBSS BIT(1) +#define WLAN_CAPABILITY_CF_POLLABLE BIT(2) +#define WLAN_CAPABILITY_CF_POLL_REQUEST BIT(3) +#define WLAN_CAPABILITY_PRIVACY BIT(4) +#define WLAN_CAPABILITY_SHORT_PREAMBLE BIT(5) +#define WLAN_CAPABILITY_PBCC BIT(6) +#define WLAN_CAPABILITY_CHANNEL_AGILITY BIT(7) + +/* Status codes */ +#define WLAN_STATUS_SUCCESS 0 +#define WLAN_STATUS_UNSPECIFIED_FAILURE 1 +#define WLAN_STATUS_CAPS_UNSUPPORTED 10 +#define WLAN_STATUS_REASSOC_NO_ASSOC 11 +#define WLAN_STATUS_ASSOC_DENIED_UNSPEC 12 +#define WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG 13 +#define WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION 14 +#define WLAN_STATUS_CHALLENGE_FAIL 15 +#define WLAN_STATUS_AUTH_TIMEOUT 16 +#define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17 +#define WLAN_STATUS_ASSOC_DENIED_RATES 18 +/* 802.11b */ +#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19 +#define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20 +#define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21 + +/* Reason codes */ +#define WLAN_REASON_UNSPECIFIED 1 +#define WLAN_REASON_PREV_AUTH_NOT_VALID 2 +#define WLAN_REASON_DEAUTH_LEAVING 3 +#define WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY 4 +#define WLAN_REASON_DISASSOC_AP_BUSY 5 +#define WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA 6 +#define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7 +#define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8 +#define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 + + +/* Information Element IDs */ +#define WLAN_EID_SSID 0 +#define WLAN_EID_SUPP_RATES 1 +#define WLAN_EID_FH_PARAMS 2 +#define WLAN_EID_DS_PARAMS 3 +#define WLAN_EID_CF_PARAMS 4 +#define WLAN_EID_TIM 5 +#define WLAN_EID_IBSS_PARAMS 6 +#define WLAN_EID_CHALLENGE 16 +#define WLAN_EID_RSN 48 +#define WLAN_EID_GENERIC 221 + +#define IEEE80211_MGMT_HDR_LEN 24 +#define IEEE80211_DATA_HDR3_LEN 24 +#define IEEE80211_DATA_HDR4_LEN 30 + + +#define IEEE80211_STATMASK_SIGNAL BIT(0) +#define IEEE80211_STATMASK_RSSI BIT(1) +#define IEEE80211_STATMASK_NOISE BIT(2) +#define IEEE80211_STATMASK_RATE BIT(3) +#define IEEE80211_STATMASK_WEMASK 0x7 + + +#define IEEE80211_CCK_MODULATION BIT(0) +#define IEEE80211_OFDM_MODULATION BIT(1) + +#define IEEE80211_24GHZ_BAND BIT(0) +#define IEEE80211_52GHZ_BAND BIT(1) + +#define IEEE80211_CCK_RATE_1MB 0x02 +#define IEEE80211_CCK_RATE_2MB 0x04 +#define IEEE80211_CCK_RATE_5MB 0x0B +#define IEEE80211_CCK_RATE_11MB 0x16 +#define IEEE80211_OFDM_RATE_6MB 0x0C +#define IEEE80211_OFDM_RATE_9MB 0x12 +#define IEEE80211_OFDM_RATE_12MB 0x18 +#define IEEE80211_OFDM_RATE_18MB 0x24 +#define IEEE80211_OFDM_RATE_24MB 0x30 +#define IEEE80211_OFDM_RATE_36MB 0x48 +#define IEEE80211_OFDM_RATE_48MB 0x60 +#define IEEE80211_OFDM_RATE_54MB 0x6C +#define IEEE80211_BASIC_RATE_MASK 0x80 + +#define IEEE80211_CCK_RATE_1MB_MASK BIT(0) +#define IEEE80211_CCK_RATE_2MB_MASK BIT(1) +#define IEEE80211_CCK_RATE_5MB_MASK BIT(2) +#define IEEE80211_CCK_RATE_11MB_MASK BIT(3) +#define IEEE80211_OFDM_RATE_6MB_MASK BIT(4) +#define IEEE80211_OFDM_RATE_9MB_MASK BIT(5) +#define IEEE80211_OFDM_RATE_12MB_MASK BIT(6) +#define IEEE80211_OFDM_RATE_18MB_MASK BIT(7) +#define IEEE80211_OFDM_RATE_24MB_MASK BIT(8) +#define IEEE80211_OFDM_RATE_36MB_MASK BIT(9) +#define IEEE80211_OFDM_RATE_48MB_MASK BIT(10) +#define IEEE80211_OFDM_RATE_54MB_MASK BIT(11) + +#define IEEE80211_CCK_RATES_MASK 0x0000000F +#define IEEE80211_CCK_BASIC_RATES_MASK (IEEE80211_CCK_RATE_1MB_MASK | \ + IEEE80211_CCK_RATE_2MB_MASK) +#define IEEE80211_CCK_DEFAULT_RATES_MASK (IEEE80211_CCK_BASIC_RATES_MASK | \ + IEEE80211_CCK_RATE_5MB_MASK | \ + IEEE80211_CCK_RATE_11MB_MASK) + +#define IEEE80211_OFDM_RATES_MASK 0x00000FF0 +#define IEEE80211_OFDM_BASIC_RATES_MASK (IEEE80211_OFDM_RATE_6MB_MASK | \ + IEEE80211_OFDM_RATE_12MB_MASK | \ + IEEE80211_OFDM_RATE_24MB_MASK) +#define IEEE80211_OFDM_DEFAULT_RATES_MASK (IEEE80211_OFDM_BASIC_RATES_MASK | \ + IEEE80211_OFDM_RATE_9MB_MASK | \ + IEEE80211_OFDM_RATE_18MB_MASK | \ + IEEE80211_OFDM_RATE_36MB_MASK | \ + IEEE80211_OFDM_RATE_48MB_MASK | \ + IEEE80211_OFDM_RATE_54MB_MASK) +#define IEEE80211_DEFAULT_RATES_MASK (IEEE80211_OFDM_DEFAULT_RATES_MASK | \ + IEEE80211_CCK_DEFAULT_RATES_MASK) + +#define IEEE80211_NUM_OFDM_RATES 8 +#define IEEE80211_NUM_CCK_RATES 4 +#define IEEE80211_OFDM_SHIFT_MASK_A 4 + + + + +/* NOTE: This data is for statistical purposes; not all hardware provides this + * information for frames received. Not setting these will not cause + * any adverse affects. */ +struct ieee80211_rx_stats { + u32 mac_time; + s8 rssi; + u8 signal; + u8 noise; + u16 rate; /* in 100 kbps */ + u8 received_channel; + u8 control; + u8 mask; + u8 freq; + u16 len; +}; + +/* IEEE 802.11 requires that STA supports concurrent reception of at least + * three fragmented frames. This define can be increased to support more + * concurrent frames, but it should be noted that each entry can consume about + * 2 kB of RAM and increasing cache size will slow down frame reassembly. */ +#define IEEE80211_FRAG_CACHE_LEN 4 + +struct ieee80211_frag_entry { + unsigned long first_frag_time; + unsigned int seq; + unsigned int last_frag; + struct sk_buff *skb; + u8 src_addr[ETH_ALEN]; + u8 dst_addr[ETH_ALEN]; +}; + +struct ieee80211_stats { + unsigned int tx_unicast_frames; + unsigned int tx_multicast_frames; + unsigned int tx_fragments; + unsigned int tx_unicast_octets; + unsigned int tx_multicast_octets; + unsigned int tx_deferred_transmissions; + unsigned int tx_single_retry_frames; + unsigned int tx_multiple_retry_frames; + unsigned int tx_retry_limit_exceeded; + unsigned int tx_discards; + unsigned int rx_unicast_frames; + unsigned int rx_multicast_frames; + unsigned int rx_fragments; + unsigned int rx_unicast_octets; + unsigned int rx_multicast_octets; + unsigned int rx_fcs_errors; + unsigned int rx_discards_no_buffer; + unsigned int tx_discards_wrong_sa; + unsigned int rx_discards_wep_undecryptable; + unsigned int rx_message_in_msg_fragments; + unsigned int rx_message_in_bad_msg_fragments; +}; + +struct ieee80211_device; + +#include "ieee80211_crypt.h" + +#define SEC_KEY_1 BIT(0) +#define SEC_KEY_2 BIT(1) +#define SEC_KEY_3 BIT(2) +#define SEC_KEY_4 BIT(3) +#define SEC_ACTIVE_KEY BIT(4) +#define SEC_AUTH_MODE BIT(5) +#define SEC_UNICAST_GROUP BIT(6) +#define SEC_LEVEL BIT(7) +#define SEC_ENABLED BIT(8) + +#define SEC_LEVEL_0 0 /* None */ +#define SEC_LEVEL_1 1 /* WEP 40 and 104 bit */ +#define SEC_LEVEL_2 2 /* Level 1 + TKIP */ +#define SEC_LEVEL_2_CKIP 3 /* Level 1 + CKIP */ +#define SEC_LEVEL_3 4 /* Level 2 + CCMP */ + +#define WEP_KEYS 4 +#define WEP_KEY_LEN 13 + +struct ieee80211_security { + u16 active_key:2, + enabled:1, + auth_mode:2, + auth_algo:4, + unicast_uses_group:1; + u8 key_sizes[WEP_KEYS]; + u8 keys[WEP_KEYS][WEP_KEY_LEN]; + u8 level; + u16 flags; +} __attribute__ ((packed)); + + +/* + + 802.11 data frame from AP + + ,-------------------------------------------------------------------. +Bytes | 2 | 2 | 6 | 6 | 6 | 2 | 0..2312 | 4 | + |------|------|---------|---------|---------|------|---------|------| +Desc. | ctrl | dura | DA/RA | TA | SA | Sequ | frame | fcs | + | | tion | (BSSID) | | | ence | data | | + `-------------------------------------------------------------------' + +Total: 28-2340 bytes + +*/ + +struct ieee80211_header_data { + u16 frame_ctl; + u16 duration_id; + u8 addr1[6]; + u8 addr2[6]; + u8 addr3[6]; + u16 seq_ctrl; +}; + +#define BEACON_PROBE_SSID_ID_POSITION 12 + +/* Management Frame Information Element Types */ +#define MFIE_TYPE_SSID 0 +#define MFIE_TYPE_RATES 1 +#define MFIE_TYPE_FH_SET 2 +#define MFIE_TYPE_DS_SET 3 +#define MFIE_TYPE_CF_SET 4 +#define MFIE_TYPE_TIM 5 +#define MFIE_TYPE_IBSS_SET 6 +#define MFIE_TYPE_CHALLENGE 16 +#define MFIE_TYPE_RSN 48 +#define MFIE_TYPE_RATES_EX 50 +#define MFIE_TYPE_GENERIC 221 + +struct ieee80211_info_element_hdr { + u8 id; + u8 len; +} __attribute__ ((packed)); + +struct ieee80211_info_element { + u8 id; + u8 len; + u8 data[0]; +} __attribute__ ((packed)); + +/* + * These are the data types that can make up management packets + * + u16 auth_algorithm; + u16 auth_sequence; + u16 beacon_interval; + u16 capability; + u8 current_ap[ETH_ALEN]; + u16 listen_interval; + struct { + u16 association_id:14, reserved:2; + } __attribute__ ((packed)); + u32 time_stamp[2]; + u16 reason; + u16 status; +*/ + +struct ieee80211_authentication { + struct ieee80211_header_data header; + u16 algorithm; + u16 transaction; + u16 status; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + + +struct ieee80211_probe_response { + struct ieee80211_header_data header; + u32 time_stamp[2]; + u16 beacon_interval; + u16 capability; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_request_frame { + u16 capability; + u16 listen_interval; + u8 current_ap[ETH_ALEN]; + struct ieee80211_info_element info_element; +} __attribute__ ((packed)); + +struct ieee80211_assoc_response_frame { + struct ieee80211_hdr_3addr header; + u16 capability; + u16 status; + u16 aid; + struct ieee80211_info_element info_element; /* supported rates */ +} __attribute__ ((packed)); + + +struct ieee80211_txb { + u8 nr_frags; + u8 encrypted; + u16 reserved; + u16 frag_size; + u16 payload_size; + struct sk_buff *fragments[0]; +}; + + +/* SWEEP TABLE ENTRIES NUMBER*/ +#define MAX_SWEEP_TAB_ENTRIES 42 +#define MAX_SWEEP_TAB_ENTRIES_PER_PACKET 7 +/* MAX_RATES_LENGTH needs to be 12. The spec says 8, and many APs + * only use 8, and then use extended rates for the remaining supported + * rates. Other APs, however, stick all of their supported rates on the + * main rates information element... */ +#define MAX_RATES_LENGTH ((u8)12) +#define MAX_RATES_EX_LENGTH ((u8)16) +#define MAX_NETWORK_COUNT 128 + +#define CRC_LENGTH 4U + +#define MAX_WPA_IE_LEN 64 + +#define NETWORK_EMPTY_ESSID BIT(0) +#define NETWORK_HAS_OFDM BIT(1) +#define NETWORK_HAS_CCK BIT(2) + +struct ieee80211_network { + /* These entries are used to identify a unique network */ + u8 bssid[ETH_ALEN]; + u8 channel; + /* Ensure null-terminated for any debug msgs */ + u8 ssid[IW_ESSID_MAX_SIZE + 1]; + u8 ssid_len; + + /* These are network statistics */ + struct ieee80211_rx_stats stats; + u16 capability; + u8 rates[MAX_RATES_LENGTH]; + u8 rates_len; + u8 rates_ex[MAX_RATES_EX_LENGTH]; + u8 rates_ex_len; + unsigned long last_scanned; + u8 mode; + u8 flags; + u32 last_associate; + u32 time_stamp[2]; + u16 beacon_interval; + u16 listen_interval; + u16 atim_window; +#ifdef CONFIG_IEEE80211_WPA + u8 wpa_ie[MAX_WPA_IE_LEN]; + size_t wpa_ie_len; + u8 rsn_ie[MAX_WPA_IE_LEN]; + size_t rsn_ie_len; +#endif /* CONFIG_IEEE80211_WPA */ + struct list_head list; +}; + +enum ieee80211_state { + IEEE80211_UNINITIALIZED = 0, + IEEE80211_INITIALIZED, + IEEE80211_ASSOCIATING, + IEEE80211_ASSOCIATED, + IEEE80211_AUTHENTICATING, + IEEE80211_AUTHENTICATED, + IEEE80211_SHUTDOWN +}; + +#define DEFAULT_MAX_SCAN_AGE (15 * HZ) +#define DEFAULT_FTS 2346 +#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x" +#define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5] + + +extern inline int is_multicast_ether_addr(const u8 *addr) +{ + return ((addr[0] != 0xff) && (0x01 & addr[0])); +} + +extern inline int is_broadcast_ether_addr(const u8 *addr) +{ + return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) && \ + (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff)); +} + +#define CFG_IEEE80211_RESERVE_FCS BIT(0) +#define CFG_IEEE80211_COMPUTE_FCS BIT(1) + +struct ieee80211_device { + struct net_device *dev; + + /* Bookkeeping structures */ + struct net_device_stats stats; + struct ieee80211_stats ieee_stats; + + /* Probe / Beacon management */ + struct list_head network_free_list; + struct list_head network_list; + struct ieee80211_network *networks; + int scans; + int scan_age; + + int iw_mode; /* operating mode (IW_MODE_*) */ + + spinlock_t lock; + + int tx_headroom; /* Set to size of any additional room needed at front + * of allocated Tx SKBs */ + u32 config; + + /* WEP and other encryption related settings at the device level */ + int open_wep; /* Set to 1 to allow unencrypted frames */ + + int reset_on_keychange; /* Set to 1 if the HW needs to be reset on + * WEP key changes */ + + /* If the host performs {en,de}cryption, then set to 1 */ + int host_encrypt; + int host_decrypt; + int ieee802_1x; /* is IEEE 802.1X used */ + +#ifdef CONFIG_IEEE80211_WPA + /* WPA data */ + int wpa_enabled; + int drop_unencrypted; + int tkip_countermeasures; + int privacy_invoked; + size_t wpa_ie_len; + u8 *wpa_ie; +#endif /* CONFIG_IEEE80211_WPA */ + + struct list_head crypt_deinit_list; + struct ieee80211_crypt_data *crypt[WEP_KEYS]; + int tx_keyidx; /* default TX key index (crypt[tx_keyidx]) */ + struct timer_list crypt_deinit_timer; + + int bcrx_sta_key; /* use individual keys to override default keys even + * with RX of broad/multicast frames */ + + /* Fragmentation structures */ + struct ieee80211_frag_entry frag_cache[IEEE80211_FRAG_CACHE_LEN]; + unsigned int frag_next_idx; + u16 fts; /* Fragmentation Threshold */ + + /* Association info */ + u8 bssid[ETH_ALEN]; + + enum ieee80211_state state; + + int mode; /* A, B, G */ + int modulation; /* CCK, OFDM */ + int freq_band; /* 2.4Ghz, 5.2Ghz, Mixed */ + int abg_ture; /* ABG flag */ + + /* Callback functions */ + void (*set_security)(struct net_device *dev, + struct ieee80211_security *sec); + int (*hard_start_xmit)(struct ieee80211_txb *txb, + struct net_device *dev); + int (*reset_port)(struct net_device *dev); + + /* This must be the last item so that it points to the data + * allocated beyond this structure by alloc_ieee80211 */ + u8 priv[0]; +}; + +#define IEEE_A BIT(0) +#define IEEE_B BIT(1) +#define IEEE_G BIT(2) +#define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G) + +extern inline void *ieee80211_priv(struct net_device *dev) +{ + return ((struct ieee80211_device *)netdev_priv(dev))->priv; +} + +extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len) +{ + /* Single white space is for Linksys APs */ + if (essid_len == 1 && essid[0] == ' ') + return 1; + + /* Otherwise, if the entire essid is 0, we assume it is hidden */ + while (essid_len) { + essid_len--; + if (essid[essid_len] != '\0') + return 0; + } + + return 1; +} + +extern inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode) +{ + /* + * It is possible for both access points and our device to support + * combinations of modes, so as long as there is one valid combination + * of ap/device supported modes, then return success + * + */ + if ((mode & IEEE_A) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_52GHZ_BAND)) + return 1; + + if ((mode & IEEE_G) && + (ieee->modulation & IEEE80211_OFDM_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + if ((mode & IEEE_B) && + (ieee->modulation & IEEE80211_CCK_MODULATION) && + (ieee->freq_band & IEEE80211_24GHZ_BAND)) + return 1; + + return 0; +} + +extern inline int ieee80211_get_hdrlen(u16 fc) +{ + int hdrlen = 24; + + switch (WLAN_FC_GET_TYPE(fc)) { + case IEEE80211_FTYPE_DATA: + if ((fc & IEEE80211_FCTL_FROMDS) && (fc & IEEE80211_FCTL_TODS)) + hdrlen = 30; /* Addr4 */ + break; + case IEEE80211_FTYPE_CTL: + switch (WLAN_FC_GET_STYPE(fc)) { + case IEEE80211_STYPE_CTS: + case IEEE80211_STYPE_ACK: + hdrlen = 10; + break; + default: + hdrlen = 16; + break; + } + break; + } + + return hdrlen; +} + + + +/* ieee80211.c */ +extern void free_ieee80211(struct net_device *dev); +extern struct net_device *alloc_ieee80211(int sizeof_priv); + +extern int ieee80211_set_encryption(struct ieee80211_device *ieee); + +/* ieee80211_tx.c */ + + +extern int ieee80211_xmit(struct sk_buff *skb, + struct net_device *dev); +extern void ieee80211_txb_free(struct ieee80211_txb *); + + +/* ieee80211_rx.c */ +extern int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, + struct ieee80211_rx_stats *rx_stats); +extern void ieee80211_rx_mgt(struct ieee80211_device *ieee, + struct ieee80211_hdr *header, + struct ieee80211_rx_stats *stats); + +/* iee80211_wx.c */ +extern int ieee80211_wx_get_scan(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_set_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); +extern int ieee80211_wx_get_encode(struct ieee80211_device *ieee, + struct iw_request_info *info, + union iwreq_data *wrqu, char *key); + + +extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee) +{ + ieee->scans++; +} + +extern inline int ieee80211_get_scans(struct ieee80211_device *ieee) +{ + return ieee->scans; +} + +static inline const char *escape_essid(const char *essid, u8 essid_len) { + static char escaped[IW_ESSID_MAX_SIZE * 2 + 1]; + const char *s = essid; + char *d = escaped; + + if (ieee80211_is_empty_essid(essid, essid_len)) { + memcpy(escaped, "", sizeof("")); + return escaped; + } + + essid_len = min(essid_len, (u8)IW_ESSID_MAX_SIZE); + while (essid_len--) { + if (*s == '\0') { + *d++ = '\\'; + *d++ = '0'; + s++; + } else { + *d++ = *s++; + } + } + *d = '\0'; + return escaped; +} + +#ifndef offset_in_page +#define offset_in_page(p) ((unsigned long)(p) & ~PAGE_MASK) +#endif + +#endif /* IEEE80211_H */ --------------040601040104090008060909-- From chas@cmf.nrl.navy.mil Fri Feb 4 10:50:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 10:50:47 -0800 (PST) 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 j14IoeuZ001242 for ; Fri, 4 Feb 2005 10:50:40 -0800 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 j14IoFU0021526; Fri, 4 Feb 2005 13:50:16 -0500 (EST) Message-Id: <200502041850.j14IoFU0021526@ginger.cmf.nrl.navy.mil> To: matthieu castet cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-Reply-To: Message from matthieu castet of "Fri, 04 Feb 2005 19:27:07 +0100." <4203BE7B.2030503@free.fr> Date: Fri, 04 Feb 2005 13:50:16 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1281 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: 293 Lines: 6 In message <4203BE7B.2030503@free.fr>,matthieu castet writes: >Shouldn't adev->signal == ATM_PHY_SIG_FOUND ? 1 : 0); be better : in the >case of ATM_PHY_SIG_UNKNOWN, it return 1... its intentional. if the atm device cant track the state of the link its probably best to just assume its up. From rkagan@mail.ru Fri Feb 4 12:13:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 12:13:31 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14KDNV9003332 for ; Fri, 4 Feb 2005 12:13:26 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id E8F684E0C4E; Fri, 4 Feb 2005 23:13:21 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.20.224] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 395828339; Fri, 04 Feb 2005 23:13:21 +0300 Date: Fri, 4 Feb 2005 23:13:27 +0300 From: Roman Kagan To: chas williams - CONTRACTOR Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050204201327.GA2439@katya> Mail-Followup-To: Roman Kagan , chas williams - CONTRACTOR , netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org References: <20050121085123.GA2471@katya> <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502041811.j14IBOna020338@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 3679 Lines: 110 Hi Chas, On Fri, Feb 04, 2005 at 01:11:25PM -0500, chas williams - CONTRACTOR wrote: > In message <20050121085123.GA2471@katya>,Roman Kagan writes: > >The patch is against 2.6.10. Please comment. > > i guess i would prefer that entries be named typeN, like he0 > instead of just a number. I'm fine with it. > if !CONFIG_SYSFS, then __free_atm_dev() is going to need to do the > kfree. Right, I forgot that sysfs was still optional. Below is the patch on top of yours to add this conditional to a few other places. > i added some other fields that i think are interesting. As a matter of fact that's what I hoped for :) > +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); Maybe it should better be "esi", to match the name in struct atm_dev? Besides, I've encountered a problem with hotplug being called from atm_dev_register: the device actually becomes usable only when the driver sets .dev_data, which may happen after hotplug has been called. E.g. if I call br2684ctl in my hotplug script, and it happens to attempt to open a socket on the device before .dev_data is set, br2684ctl fails (rather disgracefully BTW, forgetting to cleanup nasX). I had to work around it by adding a sleep for a couple of seconds to the hotplug script, and hoping that was enough for the driver to complete initializing atm_dev. I suspect the only way to fix it is to split the atm_dev initialization into two stages, allocation and registration, as it is done for net_device. Cheers, Roman. diff -ruNp linux-2.6.10.atm/net/atm/common.h linux-2.6.10.atm.new/net/atm/common.h --- linux-2.6.10.atm/net/atm/common.h 2005-02-04 21:46:52.084591328 +0300 +++ linux-2.6.10.atm.new/net/atm/common.h 2005-02-04 22:19:41.962124424 +0300 @@ -28,8 +28,21 @@ int atmpvc_init(void); void atmpvc_exit(void); int atmsvc_init(void); void atmsvc_exit(void); + +#ifdef CONFIG_SYSFS int atm_sysfs_init(void); void atm_sysfs_exit(void); +#else +static inline int atm_sysfs_init(void) +{ + return 0; +} + +static inline void atm_sysfs_exit(void) +{ + /* nothing */ +} +#endif /* CONFIG_SYSFS */ #ifdef CONFIG_PROC_FS int atm_proc_init(void); diff -ruNp linux-2.6.10.atm/net/atm/Makefile linux-2.6.10.atm.new/net/atm/Makefile --- linux-2.6.10.atm/net/atm/Makefile 2005-02-04 21:46:51.966609264 +0300 +++ linux-2.6.10.atm.new/net/atm/Makefile 2005-02-04 22:19:07.025435608 +0300 @@ -2,7 +2,7 @@ # Makefile for the ATM Protocol Families. # -atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o atm_sysfs.o +atm-y := addr.o pvc.o signaling.o svc.o ioctl.o common.o atm_misc.o raw.o resources.o mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o obj-$(CONFIG_ATM) += atm.o @@ -12,6 +12,7 @@ obj-$(CONFIG_ATM_BR2684) += br2684.o atm-$(subst m,y,$(CONFIG_ATM_BR2684)) += ipcommon.o atm-$(subst m,y,$(CONFIG_NET_SCH_ATM)) += ipcommon.o atm-$(CONFIG_PROC_FS) += proc.o +atm-$(CONFIG_SYSFS) += atm_sysfs.o obj-$(CONFIG_ATM_LANE) += lec.o obj-$(CONFIG_ATM_MPOA) += mpoa.o diff -ruNp linux-2.6.10.atm/net/atm/resources.h linux-2.6.10.atm.new/net/atm/resources.h --- linux-2.6.10.atm/net/atm/resources.h 2005-02-04 21:46:52.263564120 +0300 +++ linux-2.6.10.atm.new/net/atm/resources.h 2005-02-04 22:19:19.766498672 +0300 @@ -43,7 +43,21 @@ static inline void atm_proc_dev_deregist #endif /* CONFIG_PROC_FS */ +#ifdef CONFIG_SYSFS int atm_register_sysfs(struct atm_dev *adev); void atm_unregister_sysfs(struct atm_dev *adev); +#else + +static inline int atm_register_sysfs(struct atm_dev *dev) +{ + return 0; +} + +static inline void atm_deregister_sysfs(struct atm_dev *dev) +{ + /* nothing */ +} + +#endif /* CONFIG_SYSFS */ #endif From jgarzik@pobox.com Fri Feb 4 13:07:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:07:37 -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 j14L7W5S008317 for ; Fri, 4 Feb 2005 13:07:33 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CxAfo-0002ny-Fh; Fri, 04 Feb 2005 21:07:28 +0000 Message-ID: <4203E3FE.2090806@pobox.com> Date: Fri, 04 Feb 2005 16:07:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: maxer CC: linux-kernel@vger.kernel.org, Netdev Subject: Re: SysKonnect sk98lin Gigabit lan missing in action from 2.6.10 on References: <42038994.20401@xmission.com> In-Reply-To: <42038994.20401@xmission.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 681 Lines: 22 maxer wrote: > What is the status of sk98lin? Do we have to wait until Syskonnect gets > their act together > and write a new driver for 2.6.10? > > Their latest is Oct 2004 and not at all compatible with 2.6.10 and beyond. I've been telling SysKonnect for _years_ that they need to split up their patches, but they still keep sending ever-larger jumbo driver update patches. Stephen Hemminger split up their patch into a bunch of patches, and I applied several of those. Apparently, Stephen also got sick of trying to patch and clean sk98lin, so he went and wrote his own "skge" driver. It's available in my netdev-2.6 queue, and should be in the latest -mm. Jeff From schwab@suse.de Fri Feb 4 13:30:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:30:50 -0800 (PST) Received: from lisa.goe.net (lisa.JS.Jura.Uni-Goettingen.de [134.76.166.209]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14LUgJX009121 for ; Fri, 4 Feb 2005 13:30:43 -0800 Received: from mutter.goe.net (mail@mutter-lisa0.a11.private [192.168.31.26]) by lisa.goe.net (8.13.1/8.13.1) with ESMTP id j14LTonY004736; Fri, 4 Feb 2005 22:29:51 +0100 Received: from igel.a11.private ([192.168.31.91] helo=igel.home) by mutter.goe.net with esmtp (Exim 4.42) id 1CxB1S-0008BZ-6U; Fri, 04 Feb 2005 22:29:50 +0100 Received: by igel.home (Postfix, from userid 500) id B6D2910C283; Fri, 4 Feb 2005 22:29:49 +0100 (CET) To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [XFRM] Probe selected algorithm only References: <20050121101938.GA1133@gondor.apana.org.au> From: Andreas Schwab X-Yow: --Hello, POLICE? I"ve got ABBOTT & COSTELLO here on suspicion of HIGHWAY ROBBERY!! Date: Fri, 04 Feb 2005 22:29:49 +0100 In-Reply-To: <20050121101938.GA1133@gondor.apana.org.au> (Herbert Xu's message of "Fri, 21 Jan 2005 21:19:38 +1100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j14LUgJX009121 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: schwab@suse.de Precedence: bulk X-list: netdev Content-Length: 1944 Lines: 66 Herbert Xu writes: > ===== net/xfrm/xfrm_algo.c 1.15 vs edited ===== > --- 1.15/net/xfrm/xfrm_algo.c 2004-12-28 13:33:32 +11:00 > +++ edited/net/xfrm/xfrm_algo.c 2005-01-21 21:17:12 +11:00 > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) > #include > @@ -346,58 +347,48 @@ > return NULL; > } > > -struct xfrm_algo_desc *xfrm_aalg_get_byname(char *name) > +static struct xfrm_algo_desc *xfrm_get_byname(struct xfrm_algo_desc *list, > + int entries, char *name, > + int probe) > { > - int i; > + int i, status; > > if (!name) > return NULL; > > - for (i=0; i < aalg_entries(); i++) { > - if (strcmp(name, aalg_list[i].name) == 0) { > - if (aalg_list[i].available) > - return &aalg_list[i]; > - else > - break; > - } > + for (i = 0; i < entries; i++) { > + if (!strcmp(name, list[i].name)) > + continue; You probably didn't mean this. :-) Return the first matching entry in xfrm_get_byname instead of the first non-matching one. Signed-off-by: Andreas Schwab --- linux-2.6.11-rc3/net/xfrm/xfrm_algo.c.~1~ 2005-02-03 22:54:42.000000000 +0100 +++ linux-2.6.11-rc3/net/xfrm/xfrm_algo.c 2005-02-04 21:56:11.000000000 +0100 @@ -357,7 +357,7 @@ static struct xfrm_algo_desc *xfrm_get_b return NULL; for (i = 0; i < entries; i++) { - if (!strcmp(name, list[i].name)) + if (strcmp(name, list[i].name) != 0) continue; if (list[i].available) Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From herbert@gondor.apana.org.au Fri Feb 4 13:32:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 13:32: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 j14LWlEi009593 for ; Fri, 4 Feb 2005 13:32:48 -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 1CxB46-0006wi-00; Sat, 05 Feb 2005 08:32:34 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxB3j-0004N1-00; Sat, 05 Feb 2005 08:32:11 +1100 Date: Sat, 5 Feb 2005 08:32:11 +1100 To: Andreas Schwab Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [XFRM] Probe selected algorithm only Message-ID: <20050204213211.GA16788@gondor.apana.org.au> References: <20050121101938.GA1133@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+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 459 Lines: 14 On Fri, Feb 04, 2005 at 10:29:49PM +0100, Andreas Schwab wrote: > > Return the first matching entry in xfrm_get_byname instead of the first > non-matching one. Yes you're totally right. Dave has already added a fix for this to his tree. 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 lawrence@the-penguin.otak.com Fri Feb 4 14:28:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 14:28:35 -0800 (PST) Received: from the-penguin.otak.com (Debian-exim@the-penguin.otak.com [65.37.126.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14MSTml011132 for ; Fri, 4 Feb 2005 14:28:30 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 4.44) id 1CxBwA-0002ET-1a; Fri, 04 Feb 2005 14:28:26 -0800 Date: Fri, 4 Feb 2005 14:28:26 -0800 From: Lawrence Walton To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, Netdev Subject: Re: SysKonnect sk98lin Gigabit lan missing in action from 2.6.10 on Message-ID: <20050204222825.GA8533@the-penguin.otak.com> References: <42038994.20401@xmission.com> <4203E3FE.2090806@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203E3FE.2090806@pobox.com> X-Operating-System: Linux 2.6.11-rc3-mm1 on an i686 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: lawrence@the-penguin.otak.com Precedence: bulk X-list: netdev Content-Length: 1390 Lines: 44 Jeff Garzik [jgarzik@pobox.com] wrote: > maxer wrote: > >What is the status of sk98lin? Do we have to wait until Syskonnect gets > >their act together > >and write a new driver for 2.6.10? > > > >Their latest is Oct 2004 and not at all compatible with 2.6.10 and beyond. > > I've been telling SysKonnect for _years_ that they need to split up > their patches, but they still keep sending ever-larger jumbo driver > update patches. > > Stephen Hemminger split up their patch into a bunch of patches, and I > applied several of those. > > Apparently, Stephen also got sick of trying to patch and clean sk98lin, > so he went and wrote his own "skge" driver. It's available in my > netdev-2.6 queue, and should be in the latest -mm. > > Jeff > > > > - > 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/ I have a SysKonnect card, and tried the skge driver (it's in the mm tree), with nominal testing I'd have to say it works well, if not better then the sk98lin driver. -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://the-penguin.otak.com/~lawrence -------------------------------------- - - - - - - O t a k i n c . - - - - - From jgarzik@pobox.com Fri Feb 4 14:48:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 14:48:44 -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 j14MmeKB012023 for ; Fri, 4 Feb 2005 14:48:40 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CxCFj-0004Ut-1B; Fri, 04 Feb 2005 22:48:39 +0000 Message-ID: <4203FBB8.7000507@pobox.com> Date: Fri, 04 Feb 2005 17:48:24 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com 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: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1359 Lines: 35 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) All this sounds great. I (and others) will be reviewing, and hope to get this into netdev-2.6 very soon. Thanks much, Jeff From shemminger@osdl.org Fri Feb 4 15:31:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 15:31:17 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14NVDht013541 for ; Fri, 4 Feb 2005 15:31:13 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j14NUwl19801; Fri, 4 Feb 2005 15:30:58 -0800 Date: Fri, 4 Feb 2005 15:31:08 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: js si , netem@lists.osdl.org, netdev@oss.sgi.com Subject: [PATCH] netem: memory leak Message-ID: <20050204153108.703ea71b@dxpl.pdx.osdl.net> In-Reply-To: <20050204231103.33325.qmail@web41510.mail.yahoo.com> References: <20050204231103.33325.qmail@web41510.mail.yahoo.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.0 (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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 474 Lines: 14 Good catch.. netem needs to free skb's that are dropped due to loss simulation. diff -Nru a/net/sched/sch_netem.c b/net/sched/sch_netem.c --- a/net/sched/sch_netem.c 2005-02-04 15:30:13 -08:00 +++ b/net/sched/sch_netem.c 2005-02-04 15:30:13 -08:00 @@ -177,6 +177,7 @@ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { pr_debug("netem_enqueue: random loss\n"); sch->qstats.drops++; + kfree_skb(skb); return 0; /* lie about loss so TCP doesn't know */ } From davem@davemloft.net Fri Feb 4 15:56:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 15:56:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14NueW2014379 for ; Fri, 4 Feb 2005 15:56:45 -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 1CxDC3-00086I-00; Fri, 04 Feb 2005 15:48:55 -0800 Date: Fri, 4 Feb 2005 15:48:55 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050204154855.79340cdb.davem@davemloft.net> In-Reply-To: <20050204113305.GA12764@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1589 Lines: 73 On Fri, 4 Feb 2005 22:33:05 +1100 Herbert Xu wrote: > I think you should probably note that some sort of locking or RCU > scheme is required to make this safe. As it is the atomic_inc > and the list_add can be reordered such that the atomic_inc occurs > after the atomic_dec_and_test. > > Either that or you can modify the example to add an > smp_mb__after_atomic_inc(). That'd be a good way to > demonstrate its use. Yeah, this example is totally bogus. I'll make it match the neighbour cache case which started this discussion. Which is something like: static void obj_list_add(struct obj *obj) { obj->active = 1; list_add(&obj->list); } static void obj_list_del(struct obj *obj) { list_del(&obj->list); obj->active = 0; } static void obj_destroy(struct obj *obj) { BUG_ON(obj->active); kfree(obj); } struct obj *obj_list_peek(struct list_head *head) { if (!list_empty(head)) { struct obj *obj; obj = list_entry(head->next, struct obj, list); atomic_inc(&obj->refcnt); return obj; } return NULL; } void obj_poke(void) { struct obj *obj; spin_lock(&global_list_lock); obj = obj_list_peek(&global_list); spin_unlock(&global_list_lock); if (obj) { obj->ops->poke(obj); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } } void obj_timeout(struct obj *obj) { spin_lock(&global_list_lock); obj_list_del(obj); spin_unlock(&global_list_lock); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } Something like that. I'll update the atomic_ops.txt doc and post and updated version later tonight. From dcbw@redhat.com Fri Feb 4 18:47:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 18:48:03 -0800 (PST) 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 j152lvmL021424 for ; Fri, 4 Feb 2005 18:47:58 -0800 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 j152jtbZ031902; Fri, 4 Feb 2005 21:45:55 -0500 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 j152jtO31038; Fri, 4 Feb 2005 21:45:55 -0500 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 j152jtb9004775; Fri, 4 Feb 2005 21:45:55 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j152jteG004771; Fri, 4 Feb 2005 21:45:55 -0500 Date: Fri, 4 Feb 2005 21:45:55 -0500 (EST) From: Dan Williams To: jt@hpl.hp.com cc: netdev@oss.sgi.com Subject: WEXT quality specification Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279707962-1533241267-1107571555=:4701" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 10814 Lines: 186 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --279707962-1533241267-1107571555=:4701 Content-Type: TEXT/PLAIN; charset=US-ASCII Jean, I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an attempt to concretely specify what drivers need to do for quality. I do this so that all ambiguity about signal quality will hopefully be gone, and so that both driver writers and user-application writers know their responsibilities. Please look it over and comment (diff attached). Its a bit long, but I feel that it has to be to adequately explain the system. I also feel that if its separate from wireless.h, people won't be bothered to go find the documentation, though if you feel strongly that it shouldn't be there then its fine to move it elsewhere. Thanks! Dan --279707962-1533241267-1107571555=:4701 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="wireless-quality-exp.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="wireless-quality-exp.diff" LS0tIHdpcmVsZXNzLjE3LmguYmFrCTIwMDUtMDItMDQgMjA6Mjg6MDMuMDAw MDAwMDAwIC0wNTAwDQorKysgd2lyZWxlc3MuMTcuaAkyMDA1LTAyLTA0IDIx OjI5OjI2LjAwMDAwMDAwMCAtMDUwMA0KQEAgLTE4NCw2ICsxODQsMTA4IEBA DQogICoJLSBBZGQgc3VwcG9ydCBmb3IgcmVsYXRpdmUgVHhQb3dlciAoeWlj ayAhKQ0KICAqLw0KIA0KKy8qDQorICogRXhwbGFuYXRpb24gb2YgV0lSRUxF U1MgUVVBTElUWQ0KKyAqIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCisgKg0KKyAqIFdpcmVsZXNzIHF1YWxpdHkgaXMgbWF5IGJlIG1lYXN1 cmVkIGluIHR3byBtZXRob2RzLCBkcml2ZXJzIG11c3QgUElDSyBPTkUNCisg KiBhbmQgdXNlIGl0IGNvbnNpc3RlbnRseSB0aHJvdWdob3V0IHRoZSBkcml2 ZXItPnVzZXJzcGFjZSBBUEk6DQorICoNCisgKiAxKSBUaGUgZmlyc3QsIHJl cXVpcmVkIGJ5IHRoZSA4MDIuMTFiIHNwZWNpZmljYXRpb24sIGlzIFJlbGF0 aXZlIFNpZ25hbA0KKyAqIFN0cmVuZ3RoIEluZGljYXRvciAoUlNTSSksIHdo aWNoIGlzIG51bWJlciBiZXR3ZWVuIDAgYW5kIE1BWF9SU1NJDQorICogaW5j bHVzaXZlLiBNYW51ZmFjdHVyZXJzIHVzZSBkaWZmZXJlbnQgbnVtYmVycyBm b3IgTUFYX1JTU0ksIHRob3VnaCBNQVhfUlNTSQ0KKyAqIGNhbm5vdCBiZSBs YXJnZXIgdGhhbiAyNTUuICBGb3IgcXVhbGl0aWVzIG1lYXN1cmVkIGluIFJT U0ksIHRoZSBsb3dlciBib3VuZA0KKyAqIGlzIF9hbHdheXNfIDAsIGFuZCB0 aGUgdXBwZXIgYm91bmQgaXMgX2Fsd2F5c18gTUFYX1JTU0kuDQorICoNCisg KiAyKSBUaGUgc2Vjb25kIG1lYXN1cmUgaXMgZGVjaWJlbCBtaWxsaXZvbHRz LCBvciBkQm0uICBUaGlzIGlzIGNhbGN1bGF0ZWQgZnJvbQ0KKyAqIHRoZSBS U1NJIG9mIGVhY2ggcGFja2V0IGJhc2VkIG9uIGxvb2t1cCB0YWJsZXMgb3Ig Y29udmVyc2lvbiBjb25zdGFudHMNCisgKiBzcGVjaWZpZWQgYnkgZWFjaCBt YW51ZmFjdHVyZXIuICBkQm0gaXMgYW4gYWJzb2x1dGUgbWVhc3VyZW1lbnQg b2YgZWxlY3RyaWNhbA0KKyAqIHBvd2VyIGdlbmVyYXRlZCBieSB0aGUgcmFk aW8gc2lnbmFscyBpbiB0aGUgcmVjZWl2ZSBjaXJjdWl0cnkgb2YgdGhlIGNh cmQuDQorICogSXQgaXMgZXhwcmVzc2VkIGluIF9uZWdhdGl2ZV8gbnVtYmVy cywgd2hlcmUgMGRCbSA9IDFtVi4gIFRoZSB1cHBlciBib3VuZA0KKyAqIGlz IF9hbHdheXNfIDAsIGFuZCB0aGUgbG93ZXIgYm91bmQgaXMgZGV0ZXJtaW5l ZCBieSB0aGUgcmVjZWl2ZXIgc2Vuc2l0aXZpdHkNCisgKiBvZiB0aGUgZWxl Y3RyaWNhbCBlcXVpcG1lbnQgb24gdGhlIGNhcmQuDQorICoNCisgKiBJZiB0 aGUgZHJpdmVyIGRvZXMgbm90IGtub3cgd2hhdCB2YWx1ZSB0byBwdXQgaW4g YSBmaWVsZCwgaXQgTVVTVCBpbmRpY2F0ZQ0KKyAqIHRoYXQgdGhlIGZpZWxk IGlzIGludmFsaWQgYnkgYml0d2lzZS1PUi1pbmcgdGhlIC51cGRhdGVkIGZp ZWxkIHdpdGggdGhlDQorICogYXBwcm9wcmlhdGUgSVdfUVVBTF8qX0lOVkFM SUQgY29uc3RhbnQgc3BlY2lmaWVkIGJlbG93LiAgU2ltcGx5IHNldHRpbmcg dGhlDQorICogZmllbGQgdG8gMCBpcyBub3Qgc3VmZmljaWVudCB0byBzcGVj aWZ5IHRoYXQgdGhlIHZhbHVlIGlzIHVua25vd24uDQorICoNCisgKiANCisg KiBUaGUgJ3F1YWwnIGZpZWxkcyBhcmUgbWV0aG9kIGluZGVwZW5kZW50LCBh bmQgYXJlIHNwZWNpZmllZCBhcyBmb2xsb3dzOg0KKyAqDQorICogbWF4X3F1 YWwucXVhbDogICAocmFuZ2UgaXMgMCAtPiAyNTUpIHVwcGVyIGJvdW5kIG9m IHN1YmplY3RpdmUgcXVhbGl0eQ0KKyAqICAgICAgICAgICAgICAgICAgbGV2 ZWxzLiAgT3RoZXIgLnF1YWwgZmllbGRzIE1VU1QgYmUgbGVzcyB0aGFuIHRo aXMgbnVtYmVyLg0KKyAqDQorICogcXVhbC5xdWFsOiAgICAgICAocmFuZ2Ug aXMgMCAtPiBtYXhfcXVhbC5xdWFsKSBRdWFsaXR5IG9mIHRoZSByZWNlaXZl ZCBwYWNrZXQNCisgKiAgICAgICAgICAgICAgICAgIGFzIGRldGVybWluZWQg YnkgdGhlIGRyaXZlci4gIFRoZSBvbmx5IHJlc3RyaWN0aW9uIGlzIHRoYXQN CisgKiAgICAgICAgICAgICAgICAgIHVzZXIgYXBwbGljYXRpb25zIE1VU1Qg YmUgYWJsZSB0byBkZXJpdmUgYSBwZXJjZW50YWdlIHZhbHVlDQorICogICAg ICAgICAgICAgICAgICBieSBkb2luZyB0aGUgZm9sbG93aW5nIGNhbGN1bGF0 aW9uOg0KKyAqICAgICAgICAgICAgICAgICAgICAgICAgICBwZXJjZW50ID0g IDEwMCAqIChxdWFsLnF1YWwgLyBtYXhfcXVhbC5xdWFsKQ0KKyAqICAgICAg ICAgICAgICAgICAgRHJpdmVycyBtYXkgZmFjdG9yIG90aGVyIHN0YXRpc3Rp Y3MsIHN1Y2ggYXMgcmVjZWl2ZSBwYWNrZXQNCisgKiAgICAgICAgICAgICAg ICAgIGVycm9ycywgIyBjb2xsaXNpb25zLCBub2lzZSBsZXZlbHMsIGV0Yywg aW50byB0aGUgdmFsdWUuDQorICoNCisgKiBPbmNlIGEgZHJpdmVyIGhhcyBQ SUNLRUQgT05FIG1ldGhvZCBvZiBtZWFzdXJlbWVudCwgdGhlIHF1YWxpdHkg ZmllbGRzIG11c3QNCisgKiBiZSBmaWxsZWQgYXMgZm9sbG93cy4gIFJlbWVt YmVyLCBhbGwgZmllbGRzIGFyZSA4LWJpdHMgd2lkZSBhbmQgYXJlIHRyZWF0 ZWQNCisgKiBhcyBzaWduZWQgb3IgdW5zaWduZWQgYmFzZWQgb24gdGhlIG1l dGhvZCBvZiBxdWFsaXR5IG1lYXN1cmVtZW50IGFib3ZlLg0KKyAqDQorICoN CisgKiBSU1NJIE1FVEhPRCAoc2V0IG1heF9xdWFsLmxldmVsID4gMCBhcyBl eHBsYWluZWQgYmVsb3cpDQorICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKyAqIG1heF9xdWFs LmxldmVsOiAgKHJhbmdlIGlzIDEgLT4gMjU1KSB1cHBlciBib3VuZCBvZiB0 aGUgUlNTSSBvZiBhbnkgcmVjZWl2ZWQNCisgKiAgICAgICAgICAgICAgICAg IHBhY2tldCwgZGV0ZXJtaW5lZCBieSB0aGUgY2FyZCdzIGhhcmR3YXJlLiAg VXN1YWxseQ0KKyAqICAgICAgICAgICAgICAgICAgc3BlY2lmaWVkIGluIHRl Y2huaWNhbCBsaXRlcmF0dXJlIGZyb20gbWFudWZhY3R1cmVyLCBvcg0KKyAq ICAgICAgICAgICAgICAgICAgcHJvdmlkZWQgYnkgcmVnaXN0ZXJzIG9uIHRo ZSBjYXJkLg0KKyAqICAgICAgICAgICAgICAgICAgICBOT1RFOiB0byBzcGVj aWZ5IHRoYXQgdmFsdWVzIGFyZSBpbiBSU1NJLCBtYXhfcXVhbC5sZXZlbA0K KyAqICAgICAgICAgICAgICAgICAgICAgICAgICBNVVNUIGJlIGxhcmdlciB0 aGFuIDAuDQorICoNCisgKiBtYXhfcXVhbC5ub2lzZTogIChyYW5nZSBpcyAw IC0+IDI1NSkgbG93ZXIgYm91bmQgb2Ygbm9pc2UsIGllIHRoZSByZWNlaXZl ZA0KKyAqICAgICAgICAgICAgICAgICAgc2lnbmFsIG11c3Qgbm90IGRyb3Ag YmVsb3cgdGhpcyBsZXZlbCBvciBpdCBjYW5ub3QgYmUNCisgKiAgICAgICAg ICAgICAgICAgIGRpc3Rpbmd1aXNoZWQuICBVc3VhbGx5IHNwZWNpZmllZCBi eSB0aGUgbWFudWZhY3R1cmVyLiAgSWYNCisgKiAgICAgICAgICAgICAgICAg IGhhcmR3YXJlIGRvZXMgbm90IHByb3ZpZGUgcGVyLXBhY2tldCBub2lzZSBp bmZvcm1hdGlvbiwgdGhlbg0KKyAqICAgICAgICAgICAgICAgICAgdGhlcmUg TVVTVCBiZSBhIHZhbHVlIGluIHRoaXMgZmllbGQuDQorICoNCisgKiBxdWFs LmxldmVsOiAgICAgIChyYW5nZSBpcyAwIC0+IG1heF9xdWFsLmxldmVsKSBh Y3R1YWwgUlNTSSB0YWtlbiBmcm9tDQorICogICAgICAgICAgICAgICAgICB0 aGUgcmVjZWl2ZXIgaGFyZHdhcmUgZm9yIGVhY2ggcGFja2V0Lg0KKyAqDQor ICogcXVhbC5ub2lzZTogICAgICAocmFuZ2UgaXMgMCAtPiBtYXhfcXVhbC5s ZXZlbCkgbm9pc2UgUlNTSSB2YWx1ZSB0YWtlbiBmcm9tDQorICogICAgICAg ICAgICAgICAgICB0aGUgcmVjZWl2ZSBoYXJkd2FyZSBpbiBSU1NJIGZvciBl YWNoIHBhY2tldC4gIElmIGhhcmR3YXJlDQorICogICAgICAgICAgICAgICAg ICBkb2VzIG5vdCBwcm92aWRlIHRoaXMgdmFsdWUgZm9yIGVhY2ggcGFja2V0 LCBzZXQgdG8gMCBhbmQNCisgKiAgICAgICAgICAgICAgICAgIHNldCAncXVh bC51cGRhdGVkIHw9IElXX1FVQUxfTk9JU0VfSU5WQUxJRCcuICBZb3UgbXVz dCB0aGVuDQorICogICAgICAgICAgICAgICAgICBwcm92aWRlIGEgdmFsdWUg aW4gbWF4X3F1YWwubm9pc2UgaW5zdGVhZC4NCisgKg0KKyAqIEluIHRoZSBS U1NJIG1ldGhvZCwgdmFsdWVzIGFyZSBfYWx3YXlzXyBwb3NpdGl2ZSBudW1i ZXJzLg0KKyAqDQorICoNCisgKiBkQm0gTUVUSE9EIChzZXQgbWF4X3F1YWwu bGV2ZWwgPSAwKQ0KKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQorICogbWF4X3F1YWwubGV2ZWwgICBNVVNUIGJlIHNldCB0byAw IHRvIHNwZWNpZnkgZEJtIG1ldGhvZA0KKyAqDQorICogbWF4X3F1YWwubm9p c2UgICAocmFuZ2UgaXMgLTI1NSAtPiAwKSBsb3dlciBib3VuZCBvZiBub2lz ZSBpbiBkQm0sIHNpZ25hbCBkQm0NCisgKiAgICAgICAgICAgICAgICAgIG1h eSBub3QgZHJvcCBiZWxvdyB0aGlzIGxldmVsIG9yIHRoZSBzaWduYWwgY2Fu bm90IGJlDQorICogICAgICAgICAgICAgICAgICBkaXN0aW5ndWlzaGVkIGZy b20gYmFja2dyb3VuZCBub2lzZSBieSB0aGUgcmVjZWl2ZXIuDQorICogICAg ICAgICAgICAgICAgICBVc3VhbGx5IHNwZWNpZmllZCBieSB0aGUgbWFudWZh Y3R1cmVyLiAgSWYgaGFyZHdhcmUgZG9lcyBub3QNCisgKiAgICAgICAgICAg ICAgICAgIHByb3ZpZGUgcGVyLXBhY2tldCBub2lzZSBpbmZvcm1hdGlvbiwg dGhlbiB0aGVyZSBNVVNUIGJlIGENCisgKiAgICAgICAgICAgICAgICAgIHZh bHVlIGluIHRoaXMgZmllbGQuDQorICoNCisgKiBxdWFsLmxldmVsICAgICAg IChyYW5nZSBpcyBtYXhfcXVhbC5ub2lzZSAtPiAwKSBzaWduYWwgbGV2ZWwg aW4gZEJtIHRha2VuDQorICogICAgICAgICAgICAgICAgICBmcm9tIHRoZSBy ZWNlaXZlciBoYXJkd2FyZSBmb3IgZWFjaCBwYWNrZXQuDQorICoNCisgKiBx dWFsLm5vaXNlICAgICAgIChyYW5nZSBpcyBtYXhfcXVhbC5ub2lzZSAtPiAw KSBub2lzZSBsZXZlbCBpbiBkQm0gdGFrZW4gZnJvbQ0KKyAqICAgICAgICAg ICAgICAgICAgdGhlIHJlY2VpdmVyIGhhcmR3YXJlIGZvciBlYWNoIHBhY2tl dC4gIElmIGhhcmR3YXJlDQorICogICAgICAgICAgICAgICAgICBkb2VzIG5v dCBwcm92aWRlIHRoaXMgdmFsdWUgZm9yIGVhY2ggcGFja2V0LCBzZXQgdG8g MCBhbmQNCisgKiAgICAgICAgICAgICAgICAgIHNldCAncXVhbC51cGRhdGVk IHw9IElXX1FVQUxfTk9JU0VfSU5WQUxJRCcuICBZb3UgbXVzdCB0aGVuDQor ICogICAgICAgICAgICAgICAgICBwcm92aWRlIGEgdmFsdWUgaW4gbWF4X3F1 YWwubm9pc2UgaW5zdGVhZC4NCisgKg0KKyAqIEluIHRoZSBkQm0gTUVUSE9E LCB2YWx1ZXMgYXJlIF9hbHdheXNfIG5lZ2F0aXZlIG51bWJlcnMgKG9yIDAp LiAgRXZlbiB0aG91Z2gNCisgKiB0aGUgYWN0dWFsIGZpZWxkcyB0aGVtc2Vs dmVzIGFyZSA4LWJpdCB1bnNpZ25lZCwgdGhlIG51bWJlcnMgYXJlIHRyZWF0 ZWQgYXMNCisgKiBuZWdhdGl2ZSwgd2hlcmUgMHgxMDAgPT0gMjU2ID09IDAu ICBWYWx1ZXMgYXJlIHBhc3NlZCB0byB1c2VyIGFwcGxpY2F0aW9ucw0KKyAq IGFmdGVyIGJlaW5nIGFkZGVkIHRvIDI1NiBpbiB0aGUgX2RyaXZlcl8uICBG b3IgZXhhbXBsZToNCisgKg0KKyAqICAgIC01NCBkQm0gPSAyMDIgICAoLTU0 IGRCbSArIDI1NiA9IDIwMikNCisgKiAgICAtMTA0IGRCbSA9IDE1MiAgKC0x MDQgZEJtICsgMjU2ID0gMTUyKQ0KKyAqDQorICovIA0KKw0KIC8qKioqKioq KioqKioqKioqKioqKioqKioqKioqIENPTlNUQU5UUyAqKioqKioqKioqKioq KioqKioqKioqKioqKioqLw0KIA0KIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIElPQ1RMIExJU1QgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g Ki8NCkBAIC0zNjAsNiArNDYyLDcgQEANCiAjZGVmaW5lIElXX01PREVfTU9O SVRPUgk2CS8qIFBhc3NpdmUgbW9uaXRvciAobGlzdGVuIG9ubHkpICovDQog DQogLyogU3RhdGlzdGljcyBmbGFncyAoYml0bWFzayBpbiB1cGRhdGVkKSAq Lw0KKy8qIFNlZSBhbHNvIFdJUkVMRVNTIFFVQUxJVFkgYWJvdmUgKi8NCiAj ZGVmaW5lIElXX1FVQUxfUVVBTF9VUERBVEVECTB4MQkvKiBWYWx1ZSB3YXMg dXBkYXRlZCBzaW5jZSBsYXN0IHJlYWQgKi8NCiAjZGVmaW5lIElXX1FVQUxf TEVWRUxfVVBEQVRFRAkweDINCiAjZGVmaW5lIElXX1FVQUxfTk9JU0VfVVBE QVRFRAkweDQNCkBAIC01MDAsNiArNjAzLDggQEANCiANCiAvKg0KICAqCVF1 YWxpdHkgb2YgdGhlIGxpbmsNCisgKg0KKyAqIFNlZSBXSVJFTEVTUyBRVUFM SVRZIGFib3ZlLg0KICAqLw0KIHN0cnVjdAlpd19xdWFsaXR5DQogew0KQEAg LTY1OCwxMCArNzYzLDEwIEBADQogDQogCS8qIFF1YWxpdHkgb2YgbGluayAm IFNOUiBzdHVmZiAqLw0KIAkvKiBRdWFsaXR5IHJhbmdlIChsaW5rLCBsZXZl bCwgbm9pc2UpDQotCSAqIElmIHRoZSBxdWFsaXR5IGlzIGFic29sdXRlLCBp dCB3aWxsIGJlIGluIHRoZSByYW5nZSBbMCA7IG1heF9xdWFsXSwNCi0JICog aWYgdGhlIHF1YWxpdHkgaXMgZEJtLCBpdCB3aWxsIGJlIGluIHRoZSByYW5n ZSBbbWF4X3F1YWwgOyAwXS4NCi0JICogRG9uJ3QgZm9yZ2V0IHRoYXQgd2Ug dXNlIDggYml0IGFyaXRobWV0aWNzLi4uICovDQorCSAqDQorCSAqIFNlZSBX SVJFTEVTUyBRVUFMSVRZIGFib3ZlLiAqLw0KIAlzdHJ1Y3QgaXdfcXVhbGl0 eQltYXhfcXVhbDsJLyogUXVhbGl0eSBvZiB0aGUgbGluayAqLw0KKw0KIAkv KiBUaGlzIHNob3VsZCBjb250YWluIHRoZSBhdmVyYWdlL3R5cGljYWwgdmFs dWVzIG9mIHRoZSBxdWFsaXR5DQogCSAqIGluZGljYXRvci4gVGhpcyBzaG91 bGQgYmUgdGhlIHRocmVzaG9sZCBiZXR3ZWVuIGEgImdvb2QiIGFuZA0KIAkg KiBhICJiYWQiIGxpbmsgKGV4YW1wbGUgOiBtb25pdG9yIGdvaW5nIGZyb20g Z3JlZW4gdG8gb3JhbmdlKS4NCg== --279707962-1533241267-1107571555=:4701-- From herbert@gondor.apana.org.au Fri Feb 4 21:25:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:25:30 -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 j155PL1L028731 for ; Fri, 4 Feb 2005 21:25: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 1CxIRC-0001Mj-00; Sat, 05 Feb 2005 16:24:54 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIQR-0004W4-00; Sat, 05 Feb 2005 16:24:07 +1100 Date: Sat, 5 Feb 2005 16:24:07 +1100 To: Mirko Parthey Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , YOSHIFUJI Hideaki , Stephen Hemminger Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205052407.GA17266@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3218 Lines: 92 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 31, 2005 at 04:22:02PM +0000, Mirko Parthey wrote: > > How to reproduce the problem (I tried this on a Pentium 4 machine): > > boot: linux init=/bin/bash > [...booting...] > # mount proc -t proc /proc > # ifconfig lo 127.0.0.1 > # brctl addbr br0 > # modprobe e100 # also reproducible with 3c5x9 > # brctl addif br0 eth0 > # ifconfig br0 192.168.1.1 > # ifconfig eth0 up > # ifconfig lo down This is the key to the problem. It took me a while to find the cause of this. Along the way I found a few other ref counting bugs in this area as well. All of these bugs stem from the idev reference held in rtable/rt6_info. Looking back in my mailbox, it's amazing how many problems this piece of infrastructure has caused since it was installed last June. AFAIK to this day there is still no code in the kernel that actually uses this infrastructure. Anyway, this particular problem is due to IPv6 adding local addresses with split devices. That is, routes to local addresses are added with rt6i_dev set to &loopback_dev and rt6i_idev set to the idev of the device where the address is added. This is just not going to work unless IPv6 creates its own dst garbage collection routine since the generic GC in net/core/dst.c has no way of finding all the rt6_info's referring to a specific net_device through rt6i_idev. It is also different from the IPv4 behaviour where we set both dev and idev to loopback_dev. Now this stuff is apparently going to be used for IP statistics. As it is packets sent to/received from local addresses are counted against the loopback device. Linux has behaved this way for a long time. So when these statistics actually get implemented it will be very strange if they were accounted to the device owning the local addresses instead of loopback. It also goes against the Linux philosophy where the addresses are owned by the host, not the interface. Therefore I propose the simple solution of not doing the split device accounting in rt6_info. Signed-off-by: Herbert Xu I will send the patches for the other bugs separately. 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 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=q ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00 +++ edited/net/ipv6/route.c 2005-02-05 16:10:19 +11:00 @@ -1395,13 +1395,12 @@ return ERR_PTR(-ENOMEM); dev_hold(&loopback_dev); - in6_dev_hold(idev); rt->u.dst.flags = DST_HOST; rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = idev; + rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --dDRMvlgZJXvWKvBx-- From jm@jm.kir.nu Fri Feb 4 21:29:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:30:01 -0800 (PST) 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 j155Trdu029244 for ; Fri, 4 Feb 2005 21:29:55 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CxITw-0003sZ-Vl; Fri, 04 Feb 2005 21:27:44 -0800 Date: Fri, 4 Feb 2005 21:27:44 -0800 From: Jouni Malinen To: Dan Williams Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification Message-ID: <20050205052744.GD9685@jm.kir.nu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 4794 Lines: 94 On Fri, Feb 04, 2005 at 09:45:55PM -0500, Dan Williams wrote: > I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an > attempt to concretely specify what drivers need to do for quality. Nice to see more documentation on this area. I would consider moving this to somewhere else or adding a separate document (Documentation/networking/wireless/... ?) though, since I would hope to eventually see detailed (and in practice, quite long) explanation for all areas of the wireless extensions, not just signal quality. Comments in C header files may not be the nicest format for editing such specification.. > + * Explanation of WIRELESS QUALITY Maybe change that to wireless signal quality? > + * Wireless quality is may be measured in two methods, drivers must PICK ONE > + * and use it consistently throughout the driver->userspace API: Unfortunately, this may not be possible with some (well, maybe even most) hardware models. It is quite common to configure TX power in dBm and report signal strength for received frames in RSSI. Even if this part is left out and this is only about signal strength/quality of received frames, some cards have different mechanism for reporting quality for 1) received packets, 2) current BSS (average), 3) scan results. Another common example is in reporting received signal strength in RSSI and noise level in dBm. > + * 2) The second measure is decibel millivolts, or dBm. This is calculated from milliwatts (i.e., power, not potential) > + * the RSSI of each packet based on lookup tables or conversion constants > + * specified by each manufacturer. dBm is an absolute measurement of electrical > + * power generated by the radio signals in the receive circuitry of the card. > + * It is expressed in _negative_ numbers, where 0dBm = 1mV. The upper bound 1 mW > + * is _always_ 0, and the lower bound is determined by the receiver sensitivity When setting TX power, these numbers are (in most cases) positive, e.g., 16 dBm. Again, this could be considered to be outside the scope of this description, but should be kept in mind for other parts of wireless extensions. Another example would be non-802.11 wireless device that could potentially receive signals with higher power than 0 dBm.. > + * The 'qual' fields are method independent, and are specified as follows: > + * > + * max_qual.qual: (range is 0 -> 255) upper bound of subjective quality > + * levels. Other .qual fields MUST be less than this number. > + * > + * qual.qual: (range is 0 -> max_qual.qual) Quality of the received packet > + * as determined by the driver. The only restriction is that > + * user applications MUST be able to derive a percentage value > + * by doing the following calculation: > + * percent = 100 * (qual.qual / max_qual.qual) > + * Drivers may factor other statistics, such as receive packet > + * errors, # collisions, noise levels, etc, into the value. Is this restriction to linear value ok? Many other values are in logarithmic scale. What does this "percentage" really mean and what is it used for? The current wireless.h defines quality as percentage of retries or missed beacons, or SNR.. > + * Once a driver has PICKED ONE method of measurement, the quality fields must > + * be filled as follows. Remember, all fields are 8-bits wide and are treated > + * as signed or unsigned based on the method of quality measurement above. > + * > + * > + * RSSI METHOD (set max_qual.level > 0 as explained below) > + *-------------------------------------------------------- > + * max_qual.level: (range is 1 -> 255) upper bound of the RSSI of any received > + * packet, determined by the card's hardware. Usually > + * specified in technical literature from manufacturer, or > + * provided by registers on the card. > + * NOTE: to specify that values are in RSSI, max_qual.level > + * MUST be larger than 0. So, if the hardware reports RSSI in 0..70, both values 0 and 1 should be stored as 1? Actually, I've seen one hardware where reported RSSI values are dropping below zero every now and then.. > + * max_qual.noise: (range is 0 -> 255) lower bound of noise, ie the received Why is there a different range for noise? Is only max_qual.level used to select the RSSI/dBm method and this max_qual.noise would be, e.g., the current noise floor (which, btw, is often presented in dBm, not RSSI). Is this a new mechanism for reporting noise floor? I don't remember seeing this kind of definition before. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Fri Feb 4 21:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:31:19 -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 j155VAl2029742 for ; Fri, 4 Feb 2005 21:31:11 -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 1CxIWx-0001Nu-00; Sat, 05 Feb 2005 16:30:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIWc-0004XY-00; Sat, 05 Feb 2005 16:30:30 +1100 Date: Sat, 5 Feb 2005 16:30:30 +1100 To: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [IPV4] Make loopback idev stick around Message-ID: <20050205053030.GA17412@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2307 Lines: 89 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: As it is when loopback_dev loses all of its IPv4 addresses its corresponding idev will be destroyed. Unfortunately as of last August route.c relies on the loopback idev to kill references to other idev objects. The end result is that when you do ip a f dev lo, unregistering other devices will hang until those dst objects referring to their idev objects die of natural causes. Of course this may never happen if the processes holding those references get dead-locked by invoking an operation that takes the RTNL. A simple solution is to make sure that loopback's idev sticks around all the time. Incidentally this also fixes the setting of some flags on the loopback idev object as currently the code that does it won't be called if you add the addresses to lo after bring it up. 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 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=idev-1 ===== net/ipv4/devinet.c 1.42 vs edited ===== --- 1.42/net/ipv4/devinet.c 2005-01-11 08:43:25 +11:00 +++ edited/net/ipv4/devinet.c 2005-02-05 14:25:56 +11:00 @@ -187,6 +187,10 @@ ASSERT_RTNL(); + dev = in_dev->dev; + if (dev == &loopback_dev) + return; + in_dev->dead = 1; ip_mc_destroy_dev(in_dev); @@ -200,7 +204,6 @@ devinet_sysctl_unregister(&in_dev->cnf); #endif - dev = in_dev->dev; dev->ip_ptr = NULL; #ifdef CONFIG_SYSCTL @@ -943,8 +946,16 @@ ASSERT_RTNL(); - if (!in_dev) + if (!in_dev) { + if (event == NETDEV_REGISTER && dev == &loopback_dev) { + in_dev = inetdev_init(dev); + if (!in_dev) + panic("devinet: Failed to create loopback\n"); + in_dev->cnf.no_xfrm = 1; + in_dev->cnf.no_policy = 1; + } goto out; + } switch (event) { case NETDEV_REGISTER: @@ -967,8 +978,6 @@ memcpy(ifa->ifa_label, dev->name, IFNAMSIZ); inet_insert_ifa(ifa); } - in_dev->cnf.no_xfrm = 1; - in_dev->cnf.no_policy = 1; } ip_mc_up(in_dev); break; --AhhlLboLdkugWU4S-- From herbert@gondor.apana.org.au Fri Feb 4 21:35:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:35:53 -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 j155ZkQa030273 for ; Fri, 4 Feb 2005 21:35:47 -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 1CxIba-0001PQ-00; Sat, 05 Feb 2005 16:35:38 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxIbU-0004f5-00; Sat, 05 Feb 2005 16:35:32 +1100 Date: Sat, 5 Feb 2005 16:35:32 +1100 To: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [IPV4] Make loopback idev stick around Message-ID: <20050205053532.GA17474@gondor.apana.org.au> References: <20050205053030.GA17412@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20050205053030.GA17412@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1683 Lines: 63 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Feb 05, 2005 at 04:30:30PM +1100, herbert wrote: > > As it is when loopback_dev loses all of its IPv4 addresses its > corresponding idev will be destroyed. Unfortunately as of last > August route.c relies on the loopback idev to kill references > to other idev objects. The same problem exists for IPv6. 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 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=idev-2 ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 08:13:31 +11:00 +++ edited/net/ipv6/addrconf.c 2005-02-05 16:32:34 +11:00 @@ -1914,6 +1914,11 @@ struct inet6_dev *idev = __in6_dev_get(dev); switch(event) { + case NETDEV_REGISTER: + if (dev == &loopback_dev && !ipv6_find_idev(dev)) + panic("addrconf: Failed to create loopback\n"); + break; + case NETDEV_UP: switch(dev->type) { case ARPHRD_SIT: @@ -1998,6 +2003,9 @@ ASSERT_RTNL(); + if (dev == &loopback_dev) + how = 0; + rt6_ifdown(dev); neigh_ifdown(&nd_tbl, dev); @@ -3445,8 +3453,6 @@ */ rtnl_lock(); addrconf_notify(&ipv6_dev_notf, NETDEV_REGISTER, &loopback_dev); - if (loopback_dev.flags & IFF_UP) - addrconf_notify(&ipv6_dev_notf, NETDEV_UP, &loopback_dev); rtnl_unlock(); register_netdevice_notifier(&ipv6_dev_notf); --wRRV7LY7NUeQGEoC-- From davem@davemloft.net Fri Feb 4 21:45:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 21:46:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j155jwHF031038 for ; Fri, 4 Feb 2005 21:45:58 -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 1CxIe5-00013M-00; Fri, 04 Feb 2005 21:38:13 -0800 Date: Fri, 4 Feb 2005 21:38:13 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050204213813.4bd642ad.davem@davemloft.net> In-Reply-To: <20050205052407.GA17266@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 37 On Sat, 5 Feb 2005 16:24:07 +1100 Herbert Xu wrote: > This is the key to the problem. ... > All of these bugs stem from the idev reference held in rtable/rt6_info. ... > Anyway, this particular problem is due to IPv6 adding local addresses > with split devices. That is, routes to local addresses are added with > rt6i_dev set to &loopback_dev and rt6i_idev set to the idev of the > device where the address is added. ... > It also goes against the Linux philosophy where the addresses are owned > by the host, not the interface. > > Therefore I propose the simple solution of not doing the split device > accounting in rt6_info. I agree with your analysis, however... this change is not sufficient. You have to then walk over all the uses of rt6i_dev and sanitize the cases that still expect the split semantics. For example, things like this piece of coe in rt6_device_match(): if (dev->flags & IFF_LOOPBACK) { if (sprt->rt6i_idev == NULL || sprt->rt6i_idev->dev->ifindex != oif) { if (strict && oif) continue; if (local && (!oif || local->rt6i_idev->dev->ifindex == oif)) continue; } local = sprt; } It is just the first such thing I found, scanning rt6i_idev uses will easily find several others. From dcbw@redhat.com Fri Feb 4 22:06:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:06:51 -0800 (PST) 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 j1566km6031887 for ; Fri, 4 Feb 2005 22:06:47 -0800 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 j1564gg6008742; Sat, 5 Feb 2005 01:04:42 -0500 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 j1564gO05847; Sat, 5 Feb 2005 01:04:42 -0500 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 j1564gxr012922; Sat, 5 Feb 2005 01:04:42 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j1564gwh012918; Sat, 5 Feb 2005 01:04:42 -0500 Date: Sat, 5 Feb 2005 01:04:42 -0500 (EST) From: Dan Williams To: Jouni Malinen cc: Dan Williams , jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification In-Reply-To: <20050205052744.GD9685@jm.kir.nu> Message-ID: References: <20050205052744.GD9685@jm.kir.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 8584 Lines: 155 On Fri, 4 Feb 2005, Jouni Malinen wrote: > On Fri, Feb 04, 2005 at 09:45:55PM -0500, Dan Williams wrote: > > > I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an > > attempt to concretely specify what drivers need to do for quality. > > Nice to see more documentation on this area. I would consider moving > this to somewhere else or adding a separate document > (Documentation/networking/wireless/... ?) though, since I would hope to > eventually see detailed (and in practice, quite long) explanation for > all areas of the wireless extensions, not just signal quality. Comments > in C header files may not be the nicest format for editing such > specification.. > > > + * Explanation of WIRELESS QUALITY > > Maybe change that to wireless signal quality? > > > + * Wireless quality is may be measured in two methods, drivers must PICK ONE > > + * and use it consistently throughout the driver->userspace API: > > Unfortunately, this may not be possible with some (well, maybe even > most) hardware models. It is quite common to configure TX power in dBm > and report signal strength for received frames in RSSI. Even if this > part is left out and this is only about signal strength/quality of > received frames, some cards have different mechanism for reporting > quality for 1) received packets, 2) current BSS (average), 3) scan > results. Another common example is in reporting received signal strength > in RSSI and noise level in dBm. Note that I understand that determining a % value for "signal quality" is quite subjective, but the idea here is be able to give users a "your connection is x%" value (qual.qual), _in addition_ to being able to give them raw signal strength values (qual.level/qual.noise). At this point we're just talking about received signal quality/level. The point here is that there are two different "types" of quality that the driver must report, (1) subjective signal quality (qual.qual), and (2) electrical signal levels (qual.level). WRT the different mechanisms, there _needs_ to be consistency among drivers. Otherwise, user-space applications are left to guess what the heck each and every driver is using for units. Which just doesn't work. For your signal mechanisms, there is a place for all of them. But there needs to be consistency between 2 & 3. In the current WEXT API, there is no ability to set separate max quality & signal levels for each, there is only one max signal & quality level structure. Reporting received signal strength in RSSI and noise level in dBm won't really work well. Manufacturers usually provide an RSSI->dBm conversion, but where they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, there is no way for user applications to know the bounds of these values and determine a signal quality % from them. Again, this is all about consistency, and we need a stable, well-defined API that doesn't depend on user-applications special-casing drivers just to get usable information out of them. If the driver cannot provide usable information of some sort, it shouldn't even be trying to provide that information at all really. > > + * 2) The second measure is decibel millivolts, or dBm. This is calculated from > > milliwatts (i.e., power, not potential) Correct, it was late :) My mistake. > > + * is _always_ 0, and the lower bound is determined by the receiver sensitivity > > When setting TX power, these numbers are (in most cases) positive, e.g., > 16 dBm. Again, this could be considered to be outside the scope of this > description, but should be kept in mind for other parts of wireless > extensions. Another example would be non-802.11 wireless device that > could potentially receive signals with higher power than 0 dBm.. Again, we're not talking about TX power yet... The non-802.11 point is valid, but at this time WEXT is so geared toward 802.11 devices that more significant changes would need to take place to apply WEXT to them. I'm not sure that time has come yet. > > > + * The 'qual' fields are method independent, and are specified as follows: > > + * > > + * max_qual.qual: (range is 0 -> 255) upper bound of subjective quality > > + * levels. Other .qual fields MUST be less than this number. > > + * > > + * qual.qual: (range is 0 -> max_qual.qual) Quality of the received packet > > + * as determined by the driver. The only restriction is that > > + * user applications MUST be able to derive a percentage value > > + * by doing the following calculation: > > + * percent = 100 * (qual.qual / max_qual.qual) > > + * Drivers may factor other statistics, such as receive packet > > + * errors, # collisions, noise levels, etc, into the value. > > Is this restriction to linear value ok? Many other values are in > logarithmic scale. What does this "percentage" really mean and what is > it used for? The current wireless.h defines quality as percentage of > retries or missed beacons, or SNR.. qual.qual must be linear (because it should be able to be converted to a percentage value, its a _subjective_ measure of quality composed of a number of different quality statistics). qual.level & qual.noise may not necessarily be linear since they are measures of electrical power (either RSSI or dBm). > > > + * Once a driver has PICKED ONE method of measurement, the quality fields must > > + * be filled as follows. Remember, all fields are 8-bits wide and are treated > > + * as signed or unsigned based on the method of quality measurement above. > > + * > > + * > > + * RSSI METHOD (set max_qual.level > 0 as explained below) > > + *-------------------------------------------------------- > > + * max_qual.level: (range is 1 -> 255) upper bound of the RSSI of any received > > + * packet, determined by the card's hardware. Usually > > + * specified in technical literature from manufacturer, or > > + * provided by registers on the card. > > + * NOTE: to specify that values are in RSSI, max_qual.level > > + * MUST be larger than 0. > > So, if the hardware reports RSSI in 0..70, both values 0 and 1 should be > stored as 1? Actually, I've seen one hardware where reported RSSI values > are dropping below zero every now and then.. The current WEXT API provides _no_ way to specify whether the returned values are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've brought that up with Jean and he's agreed that it may need some clarification. There isn't really a "qual.type = dBm" bit anywhere in the quality structures, though that would be quite helpful (and was my suggestion). But here we're talking about max_qual.level, remember its the upper bound and will never have a value of 0. If the card's MAX_RSSI is 0, something is horribly wrong with the card since that indicates that it cannot receieve any signal at all. If the card actually has an interesting max_qual.level in dBm (say, -10 dBm), we cannot encode that value using WEXT at this time. > > > + * max_qual.noise: (range is 0 -> 255) lower bound of noise, ie the received > > Why is there a different range for noise? Is only max_qual.level used to > select the RSSI/dBm method and this max_qual.noise would be, e.g., the > current noise floor (which, btw, is often presented in dBm, not RSSI). > Is this a new mechanism for reporting noise floor? I don't remember > seeing this kind of definition before. See above, technically you could have a noise floor of 0 I guess, and the current WEXT API has no way of specifying different units for use in noise and level at this time. Hence, the noise value can actually mean something when using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). This is really an attempt to clarify the rules as I understand them (and after a couple discussions with Jean about the quality stuff). I've looked over almost every wireless/802.11 driver that exists for Linux, and none of them implement the standard correctly, probably becuase its a bit ambiguous and nobody could quite understand what they were supposed to do in the quality space. We need to bring some coherency to drivers in this regard, if only so that people can get their pretty little signal bars in the UI. Dan From herbert@gondor.apana.org.au Fri Feb 4 22:11:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:12:03 -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 j156BrnQ032592 for ; Fri, 4 Feb 2005 22:11: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 1CxJAL-0001YM-00; Sat, 05 Feb 2005 17:11:33 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJ9y-0004qB-00; Sat, 05 Feb 2005 17:11:10 +1100 Date: Sat, 5 Feb 2005 17:11:10 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205061110.GA18275@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20050204213813.4bd642ad.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4003 Lines: 129 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > > It is just the first such thing I found, scanning rt6i_idev uses > will easily find several others. You're right of course. I thought they were all harmless but I was obviously wrong about this one. So here is a patch that essentially reverts the split devices semantics introduced by these two changesets: [IPV6] addrconf_dst_alloc() to allocate new route for local address. [IPV6] take rt6i_idev into account when looking up routes. Signed-off-by: Herbert Xu ~{PmV>HI~} 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 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/ip6_route.h 1.21 vs edited ===== --- 1.21/include/net/ip6_route.h 2004-10-26 14:27:49 +10:00 +++ edited/include/net/ip6_route.h 2005-02-05 17:02:36 +11:00 @@ -74,8 +74,7 @@ extern int ndisc_dst_gc(int *more); extern void fib6_force_start_gc(void); -extern struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev, - const struct in6_addr *addr, +extern struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr, int anycast); /* ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 08:13:31 +11:00 +++ edited/net/ipv6/addrconf.c 2005-02-05 17:02:00 +11:00 @@ -509,7 +509,7 @@ goto out; } - rt = addrconf_dst_alloc(idev, addr, 0); + rt = addrconf_dst_alloc(addr, 0); if (IS_ERR(rt)) { err = PTR_ERR(rt); goto out; ===== net/ipv6/anycast.c 1.19 vs edited ===== --- 1.19/net/ipv6/anycast.c 2005-01-15 08:30:07 +11:00 +++ edited/net/ipv6/anycast.c 2005-02-05 17:01:47 +11:00 @@ -340,7 +340,7 @@ goto out; } - rt = addrconf_dst_alloc(idev, addr, 1); + rt = addrconf_dst_alloc(addr, 1); if (IS_ERR(rt)) { kfree(aca); err = PTR_ERR(rt); ===== net/ipv6/ip6_fib.c 1.34 vs edited ===== --- 1.34/net/ipv6/ip6_fib.c 2005-01-14 15:41:06 +11:00 +++ edited/net/ipv6/ip6_fib.c 2005-02-05 17:04:02 +11:00 @@ -450,7 +450,6 @@ */ if (iter->rt6i_dev == rt->rt6i_dev && - iter->rt6i_idev == rt->rt6i_idev && ipv6_addr_equal(&iter->rt6i_gateway, &rt->rt6i_gateway)) { if (!(iter->rt6i_flags&RTF_EXPIRES)) ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00 +++ edited/net/ipv6/route.c 2005-02-05 17:01:23 +11:00 @@ -189,17 +189,8 @@ struct net_device *dev = sprt->rt6i_dev; if (dev->ifindex == oif) return sprt; - if (dev->flags & IFF_LOOPBACK) { - if (sprt->rt6i_idev == NULL || - sprt->rt6i_idev->dev->ifindex != oif) { - if (strict && oif) - continue; - if (local && (!oif || - local->rt6i_idev->dev->ifindex == oif)) - continue; - } + if (dev->flags & IFF_LOOPBACK) local = sprt; - } } if (local) @@ -1385,8 +1376,7 @@ * Allocate a dst for local (unicast / anycast) address. */ -struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev, - const struct in6_addr *addr, +struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr, int anycast) { struct rt6_info *rt = ip6_dst_alloc(); @@ -1395,13 +1385,12 @@ return ERR_PTR(-ENOMEM); dev_hold(&loopback_dev); - in6_dev_hold(idev); rt->u.dst.flags = DST_HOST; rt->u.dst.input = ip6_input; rt->u.dst.output = ip6_output; rt->rt6i_dev = &loopback_dev; - rt->rt6i_idev = idev; + rt->rt6i_idev = in6_dev_get(&loopback_dev); rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); --5vNYLRcllDrimb99-- From rddunlap@osdl.org Fri Feb 4 22:17:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:17:15 -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 j156HAkJ000652 for ; Fri, 4 Feb 2005 22:17:11 -0800 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 j156H1uM020874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Feb 2005 22:17:03 -0800 Message-ID: <420462BC.6010903@osdl.org> Date: Fri, 04 Feb 2005 22:07:56 -0800 From: "Randy.Dunlap" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem References: <4203C32A.70402@linux.intel.com> In-Reply-To: <4203C32A.70402@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.101 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 3956 Lines: 126 James Ketrenos wrote: > Attached is the patch against 2.6.11-rc3-mm1 that adds the ieee80211 > subsystem used by the ipw2100 and ipw2200 projects. > > I'll be sending out the patches for ipw2100-1.0.0 and ipw2200-1.0.0 that > use thist stack to the list on Monday. > > In terms of what the stack currently does: > > * HW independent -- it only knows about 802.11 data and structures > * Performs an 802.3 <-> 802.11 transform for data Tx/Rx > * Host based support for fragmentation, WEP, and WPA using the kernel's > crypto functions > * Beacon and probe response collection and parsing > * Default implementation of some of the WE handlers that can be managed > without hardware knowledge > > We are working to merge in Dave Miller's p80211 code into the ieee80211 > subsystem so that it hooks into the kernel as a true network layer as > opposed to a mutated offspring of ethernet. > Once that is done, hopefully the skb to txb code can be reworked and > 802.11 fragments can be treated either as normal skbs, or skbs can be > modified to directly support them (ideally so that encrypted 802.11 > frames in support of IP packets can be cached by the stack instead of > having to be re-encrypted on TCP retries) > > Support for HW/FW crypto and fragmentation offload, in a HW independent > fashion, is also on the short-term list. > > When you look through the patch you'll likely notice the #ifdef > NOTYET/#endif sequences surrounding portions of code from the hostap > project. Portions of this subsystem were based on an earlier version of > the hostap project. Those areas that weren't directly supported by the > ipw* projects weren't ported to be completely hardware independent > (since I don't have the hardware to test it), and so are still wrapped > in the ifdefs. These sections mainly cover support for MASTER and WDS > modes. > > Anyway, please let me know what you think. Hopefully I built the patch > right... It applies fine. A few comments: 1. config IEEE80211_DEBUG bool "Enable full debugging output" depends on IEEE80211 + /proc/net/ieee80211/debug_level + + For example: + + % echo 0x00000FFO > /sys/bus/pci/drivers/ipw2200/debug_level I get the impression that one of these file names is incorrect: /proc vs. /sys..... + % . idvals + + From within drivers/net/wireless/ipw2200 Is there some good place for this other than in drivers/net/wireless? I don't know. + If you are not trying to debug or develop the IPW2200 driver, + you + most likely want to say N here. Combine those last 2 lines. 2. This can be compiled as a modules and it will be called + "ieee80211_crypt.ko". Don't use the ".ko" suffix at all (anywhere). 3. +static int __init ieee80211_crypto_init(void) + (void) ieee80211_register_crypto_ops(&ieee80211_crypt_null); That register call can fail, so I'd rather see it checked, as in all of the other similar register calls. 4. +static void * ieee80211_ccmp_init(int key_idx) + if (priv == NULL) { + goto fail; + } Lose the braces. Same for: ieee80211_ccmp_init() 5. +static void ccmp_init_blocks() + /* CCM Initial Block: + * Flag (Include authentication header, M=3 (8-octet MIC), + * L=1 (2-octet Dlen)) + * Nonce: 0x00 | A2 | PN + * Dlen */ Kernel long comment style begins with "/*" by itself and ends with "*/" by itself. 6. +struct ieee80211_ccmp_data { + u32 dot11RSNAStatsCCMPFormatErrors; + u32 dot11RSNAStatsCCMPReplays; + u32 dot11RSNAStatsCCMPDecryptErrors; Are these MIB-mandated names? otherwise the studlyCaps should go. 7. +static int ieee80211_ccmp_decrypt() Does anything care about the various negative/error case return values? 8. What calls the .print_stats functions? static char * ieee80211_ccmp_print_stats() Is it possible to use seq_file there instead of sprintf(), or is this in /sysfs (so seq_file is not possible)? Are there any overflow possibilities? Enough for tonight... -- ~Randy From davem@davemloft.net Fri Feb 4 22:21:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:21:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156LFLe001310 for ; Fri, 4 Feb 2005 22:21:15 -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 1CxJCS-0001E6-00; Fri, 04 Feb 2005 22:13:44 -0800 Date: Fri, 4 Feb 2005 22:13:44 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050204221344.247548cb.davem@davemloft.net> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1254 Lines: 34 On Sat, 5 Feb 2005 17:11:10 +1100 Herbert Xu wrote: > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: > > [IPV6] addrconf_dst_alloc() to allocate new route for local address. > [IPV6] take rt6i_idev into account when looking up routes. > > Signed-off-by: Herbert Xu ~{PmV>HI~} Ok. But Herbert, let's take a step back real quick because I want to point something out. IPv6 does try to handle the dangling mismatched idev's, in route.c:ip6_dst_ifdown(), this is called via net/core/dst.c:dst_ifdown(), and this releases the ipv6 idev correctly in the split device case. Did your analysis of this bridging release bug take this into account? That's why we added this dst->ops method, specifically to handle this problem. This was added by Yoshifuji-san in ChangeSet 1.1722.137.17 which has the checking comment: [NET]: Add dst->ifdown callback. Use it to release protocol specific objects that may be tied to a dst cache object, at ifdown time. Currently this is used to release ipv4/ipv6 specific device state. From davem@davemloft.net Fri Feb 4 22:32:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:32:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j156W6gc001905 for ; Fri, 4 Feb 2005 22:32:07 -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 1CxJMq-0001FW-00; Fri, 04 Feb 2005 22:24:28 -0800 Date: Fri, 4 Feb 2005 22:24:28 -0800 From: "David S. Miller" To: "David S. Miller" Cc: herbert@gondor.apana.org.au, anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050204222428.1a13a482.davem@davemloft.net> In-Reply-To: <20050204154855.79340cdb.davem@davemloft.net> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 11885 Lines: 350 On Fri, 4 Feb 2005 15:48:55 -0800 "David S. Miller" wrote: > Something like that. I'll update the atomic_ops.txt > doc and post and updated version later tonight. Ok, as promised, here is the updated doc. Who should I author this as? Perhaps "Anton's evil twin" :-) --- atomic_ops.txt --- This document is intended to serve as a guide to Linux port maintainers on how to implement atomic counter and bitops operations properly. The atomic_t type should be defined as a signed integer. Also, it should be made opaque such that any kind of cast to a normal C integer type will fail. Something like the following should suffice: typedef struct { volatile int counter; } atomic_t; The first operations to implement for atomic_t's are the initializers and plain reads. #define ATOMIC_INIT(i) { (i) } #define atomic_set(v, i) ((v)->counter = (i)) The first macro is used in definitions, such as: static atomic_t my_counter = ATOMIC_INIT(1); The second interface can be used at runtime, as in: k = kmalloc(sizeof(*k), GFP_KERNEL); if (!k) return -ENOMEM; atomic_set(&k->counter, 0); Next, we have: #define atomic_read(v) ((v)->counter) which simply reads the current value of the counter. Now, we move onto the actual atomic operation interfaces. void atomic_add(int i, atomic_t *v); void atomic_sub(int i, atomic_t *v); void atomic_inc(atomic_t *v); void atomic_dec(atomic_t *v); These four routines add and subtract integral values to/from the given atomic_t value. The first two routines pass explicit integers by which to make the adjustment, whereas the latter two use an implicit adjustment value of "1". One very important aspect of these two routines is that they DO NOT require any explicit memory barriers. They need only perform the atomic_t counter update in an SMP safe manner. Next, we have: int atomic_inc_return(atomic_t *v); int atomic_dec_return(atomic_t *v); These routines add 1 and subtract 1, respectively, from the given atomic_t and return the new counter value after the operation is performed. Unlike the above routines, it is required that explicit memory barriers are performed before and after the operation. It must be done such that all memory operations before and after the atomic operation calls are strongly ordered with respect to the atomic operation itself. For example, it should behave as if a smp_mb() call existed both before and after the atomic operation. If the atomic instructions used in an implementation provide explicit memory barrier semantics which satisfy the above requirements, that is fine as well. Let's move on: int atomic_add_return(int i, atomic_t *v); int atomic_sub_return(int i, atomic_t *v); These behave just like atomic_{inc,dec}_return() except that an explicit counter adjustment is given instead of the implicit "1". This means that like atomic_{inc,dec}_return(), the memory barrier semantics are required. Next: int atomic_inc_and_test(atomic_t *v); int atomic_dec_and_test(atomic_t *v); These two routines increment and decrement by 1, respectively, the given atomic counter. They return a boolean indicating whether the resulting counter value was zero or not. It requires explicit memory barrier semantics around the operation as above. int atomic_sub_and_test(int i, atomic_t *v); This is identical to atomic_dec_and_test() except that an explicit decrement is given instead of the implicit "1". It requires explicit memory barrier semantics around the operation. int atomic_add_negative(int i, atomic_t *v); The given increment is added to the given atomic counter value. A boolean is return which indicates whether the resulting counter value is negative. It requires explicit memory barrier semantics around the operation. If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: void smb_mb__before_atomic_dec(void); void smb_mb__after_atomic_dec(void); void smb_mb__before_atomic_inc(void); void smb_mb__after_atomic_dec(void); For example, smb_mb__before_atomic_dec() can be used like so: obj->dead = 1; smb_mb__before_atomic_dec(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceeding the atomic_dec() call are strongly ordered with respect to the atomic counter operation. In the above example, it guarentees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. Without the explicitl smb_mb__before_atomic_dec() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. The other three interfaces listed are used to provide explicit ordering with respect to memory operations after an atomic_dec() call (smb_mb__after_atomic_dec()) and around atomic_inc() calls (smb_mb__{before,after}_atomic_inc()). A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disasterous results. Here is an example, which follows a pattern occuring frequently in the Linux kernel. It is the use of atomic counters to implement reference counting, and it works such that once the counter falls to zero it can be guarenteed that no other entity can be accessing the object: static void obj_list_add(struct obj *obj) { obj->active = 1; list_add(&obj->list); } static void obj_list_del(struct obj *obj) { list_del(&obj->list); obj->active = 0; } static void obj_destroy(struct obj *obj) { BUG_ON(obj->active); kfree(obj); } struct obj *obj_list_peek(struct list_head *head) { if (!list_empty(head)) { struct obj *obj; obj = list_entry(head->next, struct obj, list); atomic_inc(&obj->refcnt); return obj; } return NULL; } void obj_poke(void) { struct obj *obj; spin_lock(&global_list_lock); obj = obj_list_peek(&global_list); spin_unlock(&global_list_lock); if (obj) { obj->ops->poke(obj); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } } void obj_timeout(struct obj *obj) { spin_lock(&global_list_lock); obj_list_del(obj); spin_unlock(&global_list_lock); if (atomic_dec_and_test(&obj->refcnt)) obj_destroy(obj); } (This is a simplification of the ARP queue management in the generic neighbour discover code of the networking. Olaf Kirch found a bug wrt. memory barriers in kfree_skb() that exposed the atomic_t memory barrier requirements quite clearly.) Given the above scheme, it must be the case that the obj->active update done by the obj list deletion be visible to other processors before the atomic counter decrement is performed. Otherwise, the counter could fall to zero, yet obj->active would still be set, thus triggering the assertion in obj_destroy(). The error sequence looks like this: cpu 0 cpu 1 obj_poke() obj_timeout() obj = obj_list_peek(); ... gains ref to obj, refcnt=2 obj_list_del(obj); obj->active = 0 ... ... visibility delayed ... atomic_dec_and_test() ... refcnt drops to 1 ... atomic_dec_and_test() ... refcount drops to 0 ... obj_destroy() BUG() triggers since obj->active still seen as one obj->active update visibility occurs With the memory barrier semantics required of the atomic_t operations which return values, the above sequence of memory visibility can never happen. Specifically, in the above case the atomic_dec_and_test() counter decrement would not become globally visible until the obj->active update does. We will now cover the atomic bitmask operations. You will find that their SMP and memory barrier semantics are similar in shape and scope to the atomic_t ops above. Native atomic bit operations are defined to operate on objects aligned to the size of an "unsigned long" C data type, and are least of that size. The endianness of the bits within each "unsigned long" are the native endianness of the cpu. void set_bit(unsigned long nr, volatils unsigned long *addr); void clear_bit(unsigned long nr, volatils unsigned long *addr); void change_bit(unsigned long nr, volatils unsigned long *addr); These routines set, clear, and change, respectively, the bit number indicated by "nr" on the bit mask pointed to by "ADDR". They must execute atomically, yet there are no implicit memory barrier semantics required of these interfaces. long test_and_set_bit(unsigned long nr, volatils unsigned long *addr); long test_and_clear_bit(unsigned long nr, volatils unsigned long *addr); long test_and_change_bit(unsigned long nr, volatils unsigned long *addr); Like the above, except that these routines return a boolean which indicates whether the changed bit was set _BEFORE_ the atomic bit operation. WARNING! It is incredibly important that the value be a boolean, ie. "0" or "1". Do not try to be fancy and save a few instructions by just returning something like "old_val & mask" because that will not work. For one thing, this return value gets truncated to int in many code paths, so on 64-bit if the bit is set in the upper 32-bits then testers will never see that. One great example of where this problem crops up are the thread_info flag operations. Routines such as test_and_set_ti_thread_flag() chop the return value into an int. There are other places where things like this occur as well. These routines, like the atomic_t counter operations returning values, require explicit memory barrier semantics around their execution. All memory operations before the atomic bit operation call must be made visible globally before the atomic bit operation is made visible. Likewise, the atomic bit operation must be visible globally before any subsequent memory operation is made visible. For example: obj->dead = 1; if (test_and_set_bit(0, &obj->flags)) /* ... */; obj->killed = 1; The implementation of test_and_set_bit() must guarentee that "obj->dead = 1;" is visible to cpus before the atomic memory operation done by test_and_set_bit() becomes visible. Likewise, the atomic memory operation done by test_and_set_bit() must become visible before "obj->killed = 1;" is visible. Finally there is the basic operation: long test_bit(unsigned long nr, __const__ volatile unsigned long *addr); Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". If explicit memory barriers are required around clear_bit() (which does not return a value, and thus does not need to provide memory barrier semantics), two interfaces are provided: void smp_mb__before_clear_bit(void); void smp_mb__after_clear_bit(void); They are used as follows, and are akin to their atomic_t operation brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ smp_mb__before_clear_bit(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ smp_mb__after_clear_bit(); Finally, there are non-atomic versions of the bitmask operations provided. They are used in contexts where some other higher-level SMP locking scheme is being used to protect the bitmask, and thus less expensive non-atomic operations may be used in the implementation. They have names similar to the above bitmask operation interfaces, except that two underscores are prefixed to the interface name. void __set_bit(unsigned long nr, volatile unsigned long *addr); void __clear_bit(unsigned long nr, volatile unsigned long *addr); void __change_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_set_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr); long __test_and_change_bit(unsigned long nr, volatile unsigned long *addr); These non-atomic variants also do not require any special memory barrier semantics. From jm@jm.kir.nu Fri Feb 4 22:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:41:03 -0800 (PST) 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 j156ewRA002527 for ; Fri, 4 Feb 2005 22:40:59 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1CxJao-0003ym-OY; Fri, 04 Feb 2005 22:38:54 -0800 Date: Fri, 4 Feb 2005 22:38:54 -0800 From: Jouni Malinen To: Dan Williams Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification Message-ID: <20050205063854.GE9685@jm.kir.nu> References: <20050205052744.GD9685@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 3358 Lines: 57 On Sat, Feb 05, 2005 at 01:04:42AM -0500, Dan Williams wrote: > Reporting received signal strength in RSSI and noise level in dBm won't really > work well. Manufacturers usually provide an RSSI->dBm conversion, but where > they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, > there is no way for user applications to know the bounds of these values and > determine a signal quality % from them. Again, this is all about consistency, > and we need a stable, well-defined API that doesn't depend on user-applications > special-casing drivers just to get usable information out of them. If the > driver cannot provide usable information of some sort, it shouldn't even be > trying to provide that information at all really. Agreed, there should be no special cases based on driver in user space. However, the API definition should not make it too difficult for the drivers to implement the interface. If many cards use dBm for noise and RSSI for received frames, it would sound like the API definition should take this into account and not require the drivers either not to report values or do some conversion which may not always be that clear. > qual.qual must be linear (because it should be able to be converted to a > percentage value, its a _subjective_ measure of quality composed of a number of > different quality statistics). qual.level & qual.noise may not necessarily be > linear since they are measures of electrical power (either RSSI or dBm). How would this value be determined for cards that have RSSI for received packets and noise floor in dBm? Using a table of values? > The current WEXT API provides _no_ way to specify whether the returned values > are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and > max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've > brought that up with Jean and he's agreed that it may need some clarification. > There isn't really a "qual.type = dBm" bit anywhere in the quality structures, > though that would be quite helpful (and was my suggestion). > See above, technically you could have a noise floor of 0 I guess, and the > current WEXT API has no way of specifying different units for use in noise and > level at this time. Hence, the noise value can actually mean something when > using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). Isn't the 'max_qual.level == 0 means dBm' similar to saying 'max_qual.noise == 0 means dBm' for noise. In other words, max_qual.level == 70 and max_qual.noise == 0 could mean RSSI for signal strength and dBm for noise. Using max_qual.noise to report global noise value (noise floor?) sound somewhat confusing. > This is really an attempt to clarify the rules as I understand them (and after a > couple discussions with Jean about the quality stuff). I've looked over almost > every wireless/802.11 driver that exists for Linux, and none of them > implement the standard correctly, probably becuase its a bit ambiguous and > nobody could quite understand what they were supposed to do in the quality > space. We need to bring some coherency to drivers in this regard, if only so > that people can get their pretty little signal bars in the UI. Agreed. -- Jouni Malinen PGP id EFC895FA From herbert@gondor.apana.org.au Fri Feb 4 22:47:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:47:32 -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 j156lN6W003075 for ; Fri, 4 Feb 2005 22:47: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 1CxJij-0001ry-00; Sat, 05 Feb 2005 17:47:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJiN-0007kl-00; Sat, 05 Feb 2005 17:46:43 +1100 Date: Sat, 5 Feb 2005 17:46:43 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205064643.GA29758@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204221344.247548cb.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1550 Lines: 36 On Fri, Feb 04, 2005 at 10:13:44PM -0800, David S. Miller wrote: > > But Herbert, let's take a step back real quick because I want > to point something out. IPv6 does try to handle the dangling > mismatched idev's, in route.c:ip6_dst_ifdown(), this is called > via net/core/dst.c:dst_ifdown(), and this releases the ipv6 > idev correctly in the split device case. > > Did your analysis of this bridging release bug take this into > account? That's why we added this dst->ops method, specifically > to handle this problem. This doesn't work because net/core/dst.c can only search based on dst->dev. For the split device case, dst->dev is set to loopback_dev while rt6i_idev is set to the real device. Therefore net/core/dst.c stands no chance of finding the correct local address routes that it needs to process. If we wanted to preserve the split device semantics, then we can create a local GC list in IPv6 so that it can search based on rt6i_idev as well as the other keys. Alternatively we can remove the dst->dev == dev check in dst_dev_event and dst_ifdown and move that test down to the individual ifdown functions. However, IMHO the split device semantics is inconsistent with the philosphy that addresses belong to the host and not the interface. So it doesn't really make sense in the current networking stack. 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 Feb 4 22:51:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Feb 2005 22:51: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 j156peIw003615 for ; Fri, 4 Feb 2005 22:51:41 -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 1CxJmp-0001ta-00; Sat, 05 Feb 2005 17:51:19 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxJmL-0007lO-00; Sat, 05 Feb 2005 17:50:49 +1100 Date: Sat, 5 Feb 2005 17:50:49 +1100 To: "David S. Miller" Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-ID: <20050205065049.GB29758@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203150821.2321130b.davem@davemloft.net> <20050204113305.GA12764@gondor.apana.org.au> <20050204154855.79340cdb.davem@davemloft.net> <20050204222428.1a13a482.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204222428.1a13a482.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 353 Lines: 10 On Fri, Feb 04, 2005 at 10:24:28PM -0800, David S. Miller wrote: > > Ok, as promised, here is the updated doc. Who should Looks good David. -- 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 SRS0+e0c8477f4186490ff880+531+infradead.org+hch@pentafluge.srs.infradead.org Sat Feb 5 00:13:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 00:13:31 -0800 (PST) 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 j158DLiN005492 for ; Sat, 5 Feb 2005 00:13:24 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1CxL4C-0008SW-JH; Sat, 05 Feb 2005 08:13:20 +0000 Date: Sat, 5 Feb 2005 08:13:20 +0000 From: Christoph Hellwig To: James Ketrenos Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ieee80211 subsystem Message-ID: <20050205081320.GA32490@infradead.org> References: <4203C32A.70402@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203C32A.70402@linux.intel.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 version 0.81, clamav-milter version 0.81b 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: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 97 Lines: 3 haven't looked ar the code much yet, but I think this should go under net/ and not drivers/net/ From herbert@gondor.apana.org.au Sat Feb 5 02:47:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 02:47:16 -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 j15Al5Ou014693 for ; Sat, 5 Feb 2005 02:47:06 -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 1CxNSS-0002rT-00; Sat, 05 Feb 2005 21:46:32 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxNRv-000840-00; Sat, 05 Feb 2005 21:45:59 +1100 Date: Sat, 5 Feb 2005 21:45:59 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205104559.GA30981@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 679 Lines: 16 On Sat, Feb 05, 2005 at 05:46:43PM +1100, herbert wrote: > > This doesn't work because net/core/dst.c can only search based > on dst->dev. For the split device case, dst->dev is set to > loopback_dev while rt6i_idev is set to the real device. Although I still think this is a bug, I'm now starting to suspect that there is another bug around as well. There is probably an ifp leak which in turn leads to a split dst leak that allows the first bug to make its mark. -- 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 Sat Feb 5 02:49:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 02:49:46 -0800 (PST) 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 j15AngdL015059 for ; Sat, 5 Feb 2005 02:49:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 47E1633CC2; Sat, 5 Feb 2005 19:50:41 +0900 (JST) Date: Sat, 05 Feb 2005 19:50:39 +0900 (JST) Message-Id: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 607 Lines: 15 In article <20050205064643.GA29758@gondor.apana.org.au> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu says: > If we wanted to preserve the split device semantics, then we > can create a local GC list in IPv6 so that it can search based > on rt6i_idev as well as the other keys. Alternatively we can > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > and move that test down to the individual ifdown functions. Yes, IPv6 needs "split device" semantics (for per-device statistics such as Ip6InDelivers etc), and I like later solution. Thanks. --yoshfuji From andre@tomt.net Sat Feb 5 03:14:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:14:14 -0800 (PST) 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 j15BE8dn016320 for ; Sat, 5 Feb 2005 03:14:08 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id B05AB884FC; Sat, 5 Feb 2005 12:14:06 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id B8673884ED; Sat, 5 Feb 2005 12:14:04 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 27A4422895; Sat, 5 Feb 2005 12:14:04 +0100 (CET) Message-ID: <4204AA7C.9010509@tomt.net> Date: Sat, 05 Feb 2005 12:14:04 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no 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: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 620 Lines: 19 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > >>It is just the first such thing I found, scanning rt6i_idev uses >>will easily find several others. > > > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: <..> This patch fixes my problems with hangs when dot1q VLAN interfaces gets removed when loopback is down, as reported in the thread "2.6.10 ipv6/8021q lockup on vconfig on interface removal". Yay :) From yoshfuji@linux-ipv6.org Sat Feb 5 03:38:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:38:08 -0800 (PST) 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 j15Bc2ho017244 for ; Sat, 5 Feb 2005 03:38:02 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 54BEB33CC2; Sat, 5 Feb 2005 20:39:01 +0900 (JST) Date: Sat, 05 Feb 2005 20:39:00 +0900 (JST) Message-Id: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4204AA7C.9010509@tomt.net> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 525 Lines: 15 In article <4204AA7C.9010509@tomt.net> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt says: > This patch fixes my problems with hangs when dot1q VLAN interfaces gets > removed when loopback is down, as reported in the thread "2.6.10 > ipv6/8021q lockup on vconfig on interface removal". Please tell me, why your lo is down... Anyway, if we really want to "fix" this, we should do in other way. I think "Make loopback idev stick around" patches (for IPv4 and IPv6) could be start of that. --yoshfuji From andre@tomt.net Sat Feb 5 03:48:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:48:25 -0800 (PST) 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 j15BmIfs017888 for ; Sat, 5 Feb 2005 03:48:18 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 1966D884FC; Sat, 5 Feb 2005 12:48:17 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 134E5884F6; Sat, 5 Feb 2005 12:48:15 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id CC1AE22895; Sat, 5 Feb 2005 12:48:14 +0100 (CET) Message-ID: <4204B27F.5040202@tomt.net> Date: Sat, 05 Feb 2005 12:48:15 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org Cc: andre@tomt.net, herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> In-Reply-To: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no 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: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 705 Lines: 19 YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <4204AA7C.9010509@tomt.net> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt says: > > >>This patch fixes my problems with hangs when dot1q VLAN interfaces gets >>removed when loopback is down, as reported in the thread "2.6.10 >>ipv6/8021q lockup on vconfig on interface removal". > > > Please tell me, why your lo is down... > > Anyway, if we really want to "fix" this, > we should do in other way. > > I think "Make loopback idev stick around" patches > (for IPv4 and IPv6) could be start of that. "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in Debian brings down loopback before any other interfaces. From yoshfuji@linux-ipv6.org Sat Feb 5 03:54:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 03:54:18 -0800 (PST) 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 j15BsAVq018538 for ; Sat, 5 Feb 2005 03:54:10 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C933133CE2; Sat, 5 Feb 2005 20:55:09 +0900 (JST) Date: Sat, 05 Feb 2005 20:55:07 +0900 (JST) Message-Id: <20050205.205507.75127320.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4204B27F.5040202@tomt.net> References: <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> <4204B27F.5040202@tomt.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 366 Lines: 10 In article <4204B27F.5040202@tomt.net> (at Sat, 05 Feb 2005 12:48:15 +0100), Andre Tomt says: > > Please tell me, why your lo is down... : > "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in > Debian brings down loopback before any other interfaces. Okay, thanks. (I now remember someone told me this before.) hmm... --yoshfuji From rich@phekda.gotadsl.co.uk Sat Feb 5 05:24:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 05:24:51 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j15DOifB024889 for ; Sat, 5 Feb 2005 05:24:45 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-66-42.dyn.gotadsl.co.uk [82.133.66.42]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1F83F2BB5DA; Sat, 5 Feb 2005 13:24:41 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 922B5360; Sat, 5 Feb 2005 13:26:25 +0000 (GMT) Message-ID: <4204C981.6050102@phekda.gotadsl.co.uk> Date: Sat, 05 Feb 2005 13:26:25 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A0F0D5.9050702@phekda.gotadsl.co.uk> <20041121205814.GA22460@electric-eye.fr.zoreil.com> <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> In-Reply-To: <20050125214725.GA6093@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1668 Lines: 47 Hello. Francois Romieu wrote: > Hi, > > could you give the patch below some testing ? > > Any post-LLTX-revert 2.6.11-rc2-bk should do. > > Merge of Realtek's code > - code dedicated to a new phy (spotted by Richard Dawe); > - C+ register fiddling seems required for both RTL_GIGA_MAC_VER_{D/E}; > - apart from being reserved, register at address 0xe2 is named 'IntrMitigate'; > - bump version number. > A bunch of people do not use the vanilla kernel module simply because > Realtek's driver has a higher revision number. This is not an issue per > se but their driver is buggy due to some partial merge of in-kernel code. [snip] Applied to 2.6.11-rc3. It seems to work fine. I've passed ~20GB of data at 100Mbps full-duplex with no errors (compared MD5 sums on files). My data rate test (sftp of Linux kernel source tarball) gave about the same data rate as 1.6LK + PHY patch - ~7.1MB/sec. It works fine setting the speed & duplex using "ethtool -s eth0 autoneg off speed duplex ". I haven't tested the VLAN or jumbo(ish) frames. Let me know if you'd like me to test those too. Although I'm not sure if I can test jumbo frames with the equipment I have. One more thing: With 1.6LK + my PHY patch, I see the message "eth0: PHY reset until link up" every 5 seconds or so, when there is no Ethernet cable plugged in. This is annoying. I think it should only log it once. I'll repeat my cable removal/insertion tests with 2.2LK later and let you know what I find. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From dcbw@redhat.com Sat Feb 5 06:40:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 06:40:21 -0800 (PST) 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 j15EeGhm026882 for ; Sat, 5 Feb 2005 06:40:16 -0800 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 j15Eb8f1016246; Sat, 5 Feb 2005 09:37:08 -0500 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 j15Eb8O11027; Sat, 5 Feb 2005 09:37:08 -0500 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 j15Eb8vj017115; Sat, 5 Feb 2005 09:37:08 -0500 Received: from localhost (dcbw@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) with ESMTP id j15Eb7Ol017111; Sat, 5 Feb 2005 09:37:07 -0500 Date: Sat, 5 Feb 2005 09:37:07 -0500 (EST) From: Dan Williams To: Jouni Malinen cc: Dan Williams , jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: WEXT quality specification In-Reply-To: <20050205063854.GE9685@jm.kir.nu> Message-ID: References: <20050205052744.GD9685@jm.kir.nu> <20050205063854.GE9685@jm.kir.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 3671 Lines: 62 On Fri, 4 Feb 2005, Jouni Malinen wrote: > On Sat, Feb 05, 2005 at 01:04:42AM -0500, Dan Williams wrote: > > > Reporting received signal strength in RSSI and noise level in dBm won't really > > work well. Manufacturers usually provide an RSSI->dBm conversion, but where > > they don't, the driver needs to be able to provide a MAX_RSSI value. Otherwise, > > there is no way for user applications to know the bounds of these values and > > determine a signal quality % from them. Again, this is all about consistency, > > and we need a stable, well-defined API that doesn't depend on user-applications > > special-casing drivers just to get usable information out of them. If the > > driver cannot provide usable information of some sort, it shouldn't even be > > trying to provide that information at all really. > > Agreed, there should be no special cases based on driver in user space. > However, the API definition should not make it too difficult for the > drivers to implement the interface. If many cards use dBm for noise and > RSSI for received frames, it would sound like the API definition should > take this into account and not require the drivers either not to report > values or do some conversion which may not always be that clear. > > > qual.qual must be linear (because it should be able to be converted to a > > percentage value, its a _subjective_ measure of quality composed of a number of > > different quality statistics). qual.level & qual.noise may not necessarily be > > linear since they are measures of electrical power (either RSSI or dBm). > > How would this value be determined for cards that have RSSI for received > packets and noise floor in dBm? Using a table of values? AFAIK, most manufacturers provide either a conversion constant (Airo & Madwifi/Atheros) or a lookup table (airo) of some sort for their cards. People on Windows want to get dBm too. Unfortunately, given that Linux driver writers can't always get that information, you're probably right. > > The current WEXT API provides _no_ way to specify whether the returned values > > are in dBm or RSSI, other than using max_qual.level == 0 (dBm) and > > max_qual.level != 0 (RSSI). That's just the way the API is at this time. I've > > brought that up with Jean and he's agreed that it may need some clarification. > > There isn't really a "qual.type = dBm" bit anywhere in the quality structures, > > though that would be quite helpful (and was my suggestion). > > > See above, technically you could have a noise floor of 0 I guess, and the > > current WEXT API has no way of specifying different units for use in noise and > > level at this time. Hence, the noise value can actually mean something when > > using dBm as your unit, unlike max_qual.level when using dBm (as it must be 0). > > Isn't the 'max_qual.level == 0 means dBm' similar to saying > 'max_qual.noise == 0 means dBm' for noise. In other words, > max_qual.level == 70 and max_qual.noise == 0 could mean RSSI for signal > strength and dBm for noise. Using max_qual.noise to report global noise > value (noise floor?) sound somewhat confusing. Yes, that's true, and would probably be more consistent. If the suggestion is to go this far in changing the spec, then I'd suggest to actually make explicit fields in the iw_quality structure that specify what units are being used. There are two unused bitfields in the .updated structure of the iw_quality structure, and if you want to keep API/ABI compatibility then those could be used to specify RSSI/dBm. I've suggested some method of explicitly specifying this in the API, which Jean is considering. Dan From herbert@gondor.apana.org.au Sat Feb 5 10:34:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 10:34:38 -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 j15IYWdn003677 for ; Sat, 5 Feb 2005 10:34:33 -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 1CxUkz-0005ih-00; Sun, 06 Feb 2005 05:34:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxUkc-00033y-00; Sun, 06 Feb 2005 05:33:46 +1100 Date: Sun, 6 Feb 2005 05:33:46 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: andre@tomt.net, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205183346.GB11716@gondor.apana.org.au> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4204AA7C.9010509@tomt.net> <20050205.203900.66065862.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205.203900.66065862.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 647 Lines: 17 On Sat, Feb 05, 2005 at 08:39:00PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > I think "Make loopback idev stick around" patches > (for IPv4 and IPv6) could be start of that. Unfortunately that patch can't fix this particular problem. This problem will show up whenever there is a dst on the GC list that has split devices and a non-zero refcnt. So if you had a process holding that dst you can still get a dead-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 Sat Feb 5 10:33:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 10:33:42 -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 j15IXXpf003491 for ; Sat, 5 Feb 2005 10:33:34 -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 1CxUjp-0005hn-00; Sun, 06 Feb 2005 05:32:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxUjC-00033P-00; Sun, 06 Feb 2005 05:32:18 +1100 Date: Sun, 6 Feb 2005 05:32:18 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050205183218.GA11716@gondor.apana.org.au> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 988 Lines: 26 On Sat, Feb 05, 2005 at 07:50:39PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Yes, IPv6 needs "split device" semantics > (for per-device statistics such as Ip6InDelivers etc), > and I like later solution. OK. Is there any reason why IPv4 should be different from IPv6 in this respect though? If the split device dst's are to be kept, we'll need a way to clean them up. There are two choices: 1) Put the dst's on IPv6's own GC so that we can search by rt6i_idev. 2) Change the generic GC so that dst->ops->ifdown is always called even if dst->dev does not match with the device going down. We also need to change the individual ifdown functions to check for ->dev. The IPv6 ifdown function can then check for ->rt6i_idev as well. What's your preference? 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 romieu@fr.zoreil.com Sat Feb 5 12:42:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 12:42:46 -0800 (PST) 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 j15KgZLI010133 for ; Sat, 5 Feb 2005 12:42:36 -0800 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 j15Kffdj014369; Sat, 5 Feb 2005 21:41:41 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j15KfZv4014368; Sat, 5 Feb 2005 21:41:35 +0100 Date: Sat, 5 Feb 2005 21:41:35 +0100 From: Francois Romieu To: Richard Dawe Cc: netdev@oss.sgi.com Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow Message-ID: <20050205204135.GA13986@electric-eye.fr.zoreil.com> References: <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4204C981.6050102@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1807 Lines: 48 Richard Dawe : [...] > Applied to 2.6.11-rc3. It seems to work fine. I've passed ~20GB of data > at 100Mbps full-duplex with no errors (compared MD5 sums on files). My So it can be considered that the link detection issue is gone. Ok, I'll ask Jeff to submit it for mainline. > data rate test (sftp of Linux kernel source tarball) gave about the same > data rate as 1.6LK + PHY patch - ~7.1MB/sec. If this test is (sys) CPU bound, then you should see a difference when SG and TX csum is enabled. > It works fine setting the speed & duplex using "ethtool -s eth0 autoneg > off speed duplex ". Nice. Does it stand an 'ethtool -s eth0 autoneg on' after this point ? > I haven't tested the VLAN or jumbo(ish) frames. Let me know if you'd > like me to test those too. Although I'm not sure if I can test jumbo > frames with the equipment I have. Hardly. If you can do an extra test, I'd like to know if you can safely bring the r8169 interface down on your computer once the patch below if applied: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11-rc3/r8169/patches/r8169-380.patch (it should apply correctly on top of you current setup) > One more thing: > > With 1.6LK + my PHY patch, I see the message "eth0: PHY reset until link > up" every 5 seconds or so, when there is no Ethernet cable plugged in. > This is annoying. I think it should only log it once. Hmmm... One could argue that 1) syslog will cope and 2) the printk level of the console can be lowered. Some event kamasutra can probably be done from userspace too so I am a bit reluctant to special case this code (read as: I'd welcome more requests/complaints). Is it enough for you if I salt the code with a few netif_msg_xxx() here and there to control the messages ? -- Ueimor From davem@davemloft.net Sat Feb 5 17:22:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:22:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j161MiQg018727 for ; Sat, 5 Feb 2005 17:22:45 -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 1Cxb0a-0005XC-00; Sat, 05 Feb 2005 17:14:40 -0800 Date: Sat, 5 Feb 2005 17:14:39 -0800 From: "David S. Miller" To: Herbert Xu Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb Message-Id: <20050205171439.4e825155.davem@davemloft.net> In-Reply-To: <20050204015539.GA9727@gondor.apana.org.au> References: <20050131102920.GC4170@suse.de> <20050203142705.GA11318@krispykreme.ozlabs.ibm.com> <20050203203010.GA7081@gondor.apana.org.au> <20050203141901.5ce04c92.davem@davemloft.net> <20050203235044.GA8422@gondor.apana.org.au> <20050203164922.2627a112.davem@davemloft.net> <20050204012053.GA8949@gondor.apana.org.au> <20050203172357.670c3402.davem@davemloft.net> <20050204015539.GA9727@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 319 Lines: 9 On Fri, 4 Feb 2005 12:55:39 +1100 Herbert Xu wrote: > OK, here is the patch to do that. Let's get rid of kfree_skb_fast > while we're at it since it's no longer used. > > Signed-off-by: Herbert Xu I've queued this up for 2.6.x and 2.4.x, thanks everyone. From davem@davemloft.net Sat Feb 5 17:28:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:28:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j161SfT2019269 for ; Sat, 5 Feb 2005 17:28:41 -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 1Cxb6j-0005Xk-00; Sat, 05 Feb 2005 17:21:01 -0800 Date: Sat, 5 Feb 2005 17:21:01 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com, anton@samba.org Subject: Re: [NET] Add barriers for dst refcnt Message-Id: <20050205172101.7874e1dd.davem@davemloft.net> In-Reply-To: <20050204073311.GA11716@gondor.apana.org.au> References: <20050204073311.GA11716@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 998 Lines: 26 On Fri, 4 Feb 2005 18:33:11 +1100 Herbert Xu wrote: > In light of the recent discussion about sk_buff, I think we need > the following patch for dst_entry. This adds a memory barrier > before dst_release drops the refcnt, and a read memory barrier > before dst_destroy starts destroying the entry. > > Signed-off-by: Herbert Xu Good catch. I "think" the dst_release() case is theoretical. dst_release() runs in a locked context for the thing referencing 'dst'. Be it the route hash, a socket, whatever. BTW, looking at dst_release() call sites, xchg() might be another primitive we need to watch out for memory barrier semantics of. Since it returns a value, it would seem to need to be strictly ordered wrt. other memory operations. And sure enough, ppc64 has the memory barriers there. Man, something else to audit on sparc64 and document in atomic_ops.txt :-) Anyways, Herbert's patch is correct and I'll apply it. Thanks. From chas@cmf.nrl.navy.mil Sat Feb 5 17:33:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 17:33:48 -0800 (PST) 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 j161XhjY019807 for ; Sat, 5 Feb 2005 17:33:44 -0800 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 j161XIj3007281; Sat, 5 Feb 2005 20:33:18 -0500 (EST) Message-Id: <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> To: Roman Kagan cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) In-reply-to: Your message of "Fri, 04 Feb 2005 23:13:27 +0300." <20050204201327.GA2439@katya> Date: Sat, 05 Feb 2005 20:33:18 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 1318 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: 656 Lines: 14 In message <20050204201327.GA2439@katya>,Roman Kagan writes: >> +static CLASS_DEVICE_ATTR(address, S_IRUGO, show_address, NULL); >Maybe it should better be "esi", to match the name in struct atm_dev? its called address for ethernet network interfaces so i guess calling it address here is sensible. >script, and hoping that was enough for the driver to complete >initializing atm_dev. I suspect the only way to fix it is to split the >atm_dev initialization into two stages, allocation and registration, as >it is done for net_device. yeah which is why i just wanted to convert atm_dev to just be a netdevice. the code is already written and "stable". From davem@davemloft.net Sat Feb 5 20:10:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:10:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164Ao4k023402 for ; Sat, 5 Feb 2005 20:10: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 1CxddC-00067u-00; Sat, 05 Feb 2005 20:02:42 -0800 Date: Sat, 5 Feb 2005 20:02:42 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205200242.2b629de7.davem@davemloft.net> In-Reply-To: <20050205.195039.05988480.yoshfuji@linux-ipv6.org> References: <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j164Ao4k023402 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 852 Lines: 18 On Sat, 05 Feb 2005 19:50:39 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20050205064643.GA29758@gondor.apana.org.au> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu says: > > > If we wanted to preserve the split device semantics, then we > > can create a local GC list in IPv6 so that it can search based > > on rt6i_idev as well as the other keys. Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > Yes, IPv6 needs "split device" semantics > (for per-device statistics such as Ip6InDelivers etc), > and I like later solution. Ok. I never read whether ipv6, like ipv4, is specified to support a model of host based ownership of addresses. Does anyone know? From davem@davemloft.net Sat Feb 5 20:18:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:18:32 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j164ISp6023989 for ; Sat, 5 Feb 2005 20:18:28 -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 1Cxdkz-00068U-00; Sat, 05 Feb 2005 20:10:45 -0800 Date: Sat, 5 Feb 2005 20:10:44 -0800 From: "David S. Miller" To: Herbert Xu Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205201044.1b95f4e8.davem@davemloft.net> In-Reply-To: <20050205064643.GA29758@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 36 On Sat, 5 Feb 2005 17:46:43 +1100 Herbert Xu wrote: > This doesn't work because net/core/dst.c can only search based > on dst->dev. For the split device case, dst->dev is set to > loopback_dev while rt6i_idev is set to the real device. Indeed. I didn't catch that. > If we wanted to preserve the split device semantics, then we > can create a local GC list in IPv6 so that it can search based > on rt6i_idev as well as the other keys. Ok, so this would entail changing each ipv6 dst_free() call into one to ip6_dst_free(), which would: ip6_garbage_add(dst); dst_free(dst); It would mean that dst_run_gc() would need to have some callback like dst->ops->gc_destroy() or similar, which would allow ipv6 to delete the dst from it's local garbage list. > Alternatively we can > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > and move that test down to the individual ifdown functions. I think there is a hole in this idea.... maybe. If the idea is to scan dst_garbage_list down in ipv6 specific code, you can't do that since 'dst' objects from every pool in the kernel get put onto the dst_garbage_list. It is generic. They have no identity, so it's illegal to treat any member of that list as an rt_entry, rt6_entry or any specific higher level dst type. From yoshfuji@linux-ipv6.org Sat Feb 5 20:36:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:36:32 -0800 (PST) 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 j164aQjR028099 for ; Sat, 5 Feb 2005 20:36:27 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id AB40433CC2; Sun, 6 Feb 2005 13:37:26 +0900 (JST) Date: Sun, 06 Feb 2005 13:37:23 +0900 (JST) Message-Id: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205201044.1b95f4e8.davem@davemloft.net> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 793 Lines: 23 In article <20050205201044.1b95f4e8.davem@davemloft.net> (at Sat, 5 Feb 2005 20:10:44 -0800), "David S. Miller" says: > > Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > I think there is a hole in this idea.... maybe. > > If the idea is to scan dst_garbage_list down in ipv6 specific code, > you can't do that since 'dst' objects from every pool in the kernel > get put onto the dst_garbage_list. It is generic. How about making dst->ops->dev_check() like this: static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) { if (dst->ops->dev_check) return dst->ops->dev_check(dst, dev) else return dst->dev == dev; } --yoshfuji From willy@www.linux.org.uk Sat Feb 5 20:47:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 20:47:55 -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 j164lkI5028686 for ; Sat, 5 Feb 2005 20:47:47 -0800 Received: from willy by parcelfarce.linux.theplanet.co.uk with local (Exim 4.33) id 1CxeKm-00007T-Tw for netdev@oss.sgi.com; Sun, 06 Feb 2005 04:47:44 +0000 Date: Sun, 6 Feb 2005 04:47:44 +0000 From: Matthew Wilcox To: netdev@oss.sgi.com Subject: [PATCH] ipconfig invokes undefined behaviour Message-ID: <20050206044744.GO20386@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: matthew@wil.cx Precedence: bulk X-list: netdev Content-Length: 1151 Lines: 30 strcpy is undefined if src and dest overlap. That's clearly possible here with a sufficiently deep path on the server. Use memmove instead. Signed-off-by: Matthew Wilcox Index: ./net/ipv4/ipconfig.c =================================================================== RCS file: /var/cvs/linux-2.6/net/ipv4/ipconfig.c,v retrieving revision 1.12 diff -u -p -r1.12 ipconfig.c --- ./net/ipv4/ipconfig.c 22 Jan 2005 15:00:01 -0000 1.12 +++ ./net/ipv4/ipconfig.c 6 Feb 2005 04:41:30 -0000 @@ -1232,7 +1232,7 @@ u32 __init root_nfs_parse_addr(char *nam if (*cp == ':') *cp++ = '\0'; addr = in_aton(name); - strcpy(name, cp); + memmove(name, cp, strlen(cp) + 1); } else addr = INADDR_NONE; -- "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 yoshfuji@linux-ipv6.org Sat Feb 5 21:00:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:00:42 -0800 (PST) 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 j1650aYv029454 for ; Sat, 5 Feb 2005 21:00:37 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0121C33CC2; Sun, 6 Feb 2005 14:01:36 +0900 (JST) Date: Sun, 06 Feb 2005 14:01:35 +0900 (JST) Message-Id: <20050206.140135.112327413.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205200242.2b629de7.davem@davemloft.net> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205.195039.05988480.yoshfuji@linux-ipv6.org> <20050205200242.2b629de7.davem@davemloft.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1556 Lines: 42 In article <20050205200242.2b629de7.davem@davemloft.net> (at Sat, 5 Feb 2005 20:02:42 -0800), "David S. Miller" says: > > Yes, IPv6 needs "split device" semantics > > (for per-device statistics such as Ip6InDelivers etc), > > and I like later solution. > > Ok. I never read whether ipv6, like ipv4, is specified to support > a model of host based ownership of addresses. Does anyone know? I'm not sure it is explicitly specified, but there're some hints: 1. we need to allow multiple addresses on multiple interfaces. e.g. link-local address 2. if a packet has come from A to link-local address on the other side B, we should not receive it. +-------+ ---->|A B| +-------+ Currently, it does not happen in usual because ndisc does NOT handle addresses on other device. 3. mib document states that we should take statistics on interface which the address belongs to; not the interface where the packet has come from: cited from RFC2011bis: Local (*) packets on the input side are counted on the interface associated with their destination address, which may not be the interface on which they were received. This requirement is caused by the possibility of losing the original interface during processing, especially re-assembly. (*): here it means incoming, but not forwarding. BTW, BSD has similar reference to interface structure in routeing entry. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Sat Feb 5 21:12:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:12:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j165C8om030220 for ; Sat, 5 Feb 2005 21:12:11 -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 1Cxeah-0006MX-00; Sat, 05 Feb 2005 21:04:11 -0800 Date: Sat, 5 Feb 2005 21:04:11 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-Id: <20050205210411.7e18b8e6.davem@davemloft.net> In-Reply-To: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.0 (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=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 j165C8om030220 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 483 Lines: 18 On Sun, 06 Feb 2005 13:37:23 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > How about making dst->ops->dev_check() like this: > > static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) > { > if (dst->ops->dev_check) > return dst->ops->dev_check(dst, dev) > else > return dst->dev == dev; > } Oh I see. That would work, and it seems the simplest, and lowest risk fix for this problem. Herbert, what do you think? From yoshfuji@linux-ipv6.org Sat Feb 5 21:30:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:30:17 -0800 (PST) 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 j165U8tJ030992 for ; Sat, 5 Feb 2005 21:30:09 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A5C4A33CC2; Sun, 6 Feb 2005 14:31:08 +0900 (JST) Date: Sun, 06 Feb 2005 14:31:07 +0900 (JST) Message-Id: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050205210411.7e18b8e6.davem@davemloft.net> References: <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1138 Lines: 38 In article <20050205210411.7e18b8e6.davem@davemloft.net> (at Sat, 5 Feb 2005 21:04:11 -0800), "David S. Miller" says: > On Sun, 06 Feb 2005 13:37:23 +0900 (JST) > YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > How about making dst->ops->dev_check() like this: > > > > static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev) > > { > > if (dst->ops->dev_check) > > return dst->ops->dev_check(dst, dev) > > else > > return dst->dev == dev; > > } > > Oh I see. That would work, and it seems the simplest, and > lowest risk fix for this problem. Well... Here, lo is going down. rt->rt6i_dev = lo and rt->rt6i_idev = ethX. I think we already see dst->dev == dev (==lo) now. So, I doubt that fix the problem. The source of problem is entry (*) which still on routing entry, not on gc list. And, the owner of entry is not routing table but unicast/anycast address structure(s). We need to "kill" active address on the other interfaces. *: rt->rt6i_dev = lo and rt->rt6i_idev = ethX BTW, I wish we could shut down eth0 during lo is pending... --yoshfuji From yoshfuji@linux-ipv6.org Sat Feb 5 21:49:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 21:49:14 -0800 (PST) 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 j165n89R031710 for ; Sat, 5 Feb 2005 21:49:09 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C4E3B33CC2; Sun, 6 Feb 2005 14:50:08 +0900 (JST) Date: Sun, 06 Feb 2005 14:50:07 +0900 (JST) Message-Id: <20050206.145007.34543324.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> References: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.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=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1441 Lines: 41 In article <20050206.143107.39728239.yoshfuji@linux-ipv6.org> (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > The source of problem is entry (*) which still on routing entry, > not on gc list. And, the owner of entry is not routing table but > unicast/anycast address structure(s). > We need to "kill" active address on the other interfaces. Which means in addrconf_notiry(), if the dev == &loopback_dev, call addrconf_ifdown for every device like this: Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/addrconf.c 1.129 vs edited ===== --- 1.129/net/ipv6/addrconf.c 2005-01-18 06:13:31 +09:00 +++ edited/net/ipv6/addrconf.c 2005-02-06 14:48:25 +09:00 @@ -1961,6 +1961,20 @@ case NETDEV_DOWN: case NETDEV_UNREGISTER: /* + * If lo is doing down we need to kill + * all addresses on the host because it owns + * route on lo. --yoshfuji + */ + if (dev == &loopback_dev) { + struct net_device *dev1; + for (dev1 = dev_base; dev1; dev1 = dev->next) { + if (dev1 == &loopback_dev || + __in6_dev_get(dev1) == NULL) + continue; + addrconf_ifdown(dev1, event != NETDEV_DOWN); + } + } + /* * Remove all addresses from this interface. */ addrconf_ifdown(dev, event != NETDEV_DOWN); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Sat Feb 5 22:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:52: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 j166qRtD000812 for ; Sat, 5 Feb 2005 22:52:28 -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 1CxgGz-00012j-00; Sun, 06 Feb 2005 17:51:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgGL-0001WJ-00; Sun, 06 Feb 2005 17:51:17 +1100 Date: Sun, 6 Feb 2005 17:51:17 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065117.GC16057@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205201044.1b95f4e8.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1601 Lines: 57 On Sat, Feb 05, 2005 at 08:10:44PM -0800, David S. Miller wrote: > > > Alternatively we can > > remove the dst->dev == dev check in dst_dev_event and dst_ifdown > > and move that test down to the individual ifdown functions. > > I think there is a hole in this idea.... maybe. > > If the idea is to scan dst_garbage_list down in ipv6 specific code, > you can't do that since 'dst' objects from every pool in the kernel > get put onto the dst_garbage_list. It is generic. The idea is to move the check into dst->ops->ifdown. By definition ipv6_dst_ifdown will only see rt6_info entries. So dst_dev_event will become for (dst = dst_garbage_list; dst; dst = dst->next) { dst_ifdown(dst, event != NETDEV_DOWN); } dst_ifdown will become ... do { if (dst->dev == dev && unregister) { ... } dst->ops->ifdown(dst, dev, unregister); } while ((dst = dst->child) && dst->flags & DST_NOHASH); ... Note the extra dev argument to ifdown. ipv6_dst_ifdown will be static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev, int how) { struct rt6_info *rt = (struct rt6_info *)dst; struct inet6_dev *idev = rt->rt6i_idev; if (idev != NULL && idev->dev != &loopback_dev && idev->dev == dev) { struct inet6_dev *loopback_idev = in6_dev_get(&loopback_dev); if (loopback_idev != NULL) { rt->rt6i_idev = loopback_idev; in6_dev_put(idev); } } } 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 Feb 5 22:54:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:54:10 -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 j166s5r3001421 for ; Sat, 5 Feb 2005 22:54:06 -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 1CxgIk-00013G-00; Sun, 06 Feb 2005 17:53:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgIe-0001XH-00; Sun, 06 Feb 2005 17:53:40 +1100 Date: Sun, 6 Feb 2005 17:53:40 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065340.GE16057@gondor.apana.org.au> References: <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.143107.39728239.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 923 Lines: 23 On Sun, Feb 06, 2005 at 02:31:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Here, lo is going down. > rt->rt6i_dev = lo and rt->rt6i_idev = ethX. > I think we already see dst->dev == dev (==lo) now. > So, I doubt that fix the problem. > > The source of problem is entry (*) which still on routing entry, > not on gc list. And, the owner of entry is not routing table but > unicast/anycast address structure(s). > We need to "kill" active address on the other interfaces. > > *: rt->rt6i_dev = lo and rt->rt6i_idev = ethX Sorry I don't think this is right. Although lo going down is required to cause those symptoms, it is not the trigger. The problem only occurs when eth0 itself is unregistered. -- 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 Feb 5 22:52:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 22:53:00 -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 j166qsYD000874 for ; Sat, 5 Feb 2005 22:52: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 1CxgHb-00012x-00; Sun, 06 Feb 2005 17:52:35 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgHL-0001Wn-00; Sun, 06 Feb 2005 17:52:19 +1100 Date: Sun, 6 Feb 2005 17:52:19 +1100 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206065219.GD16057@gondor.apana.org.au> References: <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205201044.1b95f4e8.davem@davemloft.net> <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205210411.7e18b8e6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 431 Lines: 15 On Sat, Feb 05, 2005 at 09:04:11PM -0800, David S. Miller wrote: > > Oh I see. That would work, and it seems the simplest, and > lowest risk fix for this problem. > > Herbert, what do you think? Yes I agree. 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 Feb 5 23:01:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 23:01: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 j1671QcJ002378 for ; Sat, 5 Feb 2005 23:01: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 1CxgPr-00016f-00; Sun, 06 Feb 2005 18:01:07 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgPa-0001Y4-00; Sun, 06 Feb 2005 18:00:50 +1100 Date: Sun, 6 Feb 2005 18:00:50 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206070050.GF16057@gondor.apana.org.au> References: <20050206.133723.124822665.yoshfuji@linux-ipv6.org> <20050205210411.7e18b8e6.davem@davemloft.net> <20050206.143107.39728239.yoshfuji@linux-ipv6.org> <20050206.145007.34543324.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.145007.34543324.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 833 Lines: 20 On Sun, Feb 06, 2005 at 02:50:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Which means in addrconf_notiry(), if the dev == &loopback_dev, > call addrconf_ifdown for every device like this: This should fix the reported issue. However, I'm not sure if it's a good idea to stop all IP traffic when lo goes down. We don't do that for IPv4. Besides, we'll still need to fix the rt6i_idev GC issue since the same bug can occur when eth0 goes down and some appliation is holding a dst to a local address route. It can become a dead-lock if the said application then invokes a syscall that takes 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 herbert@gondor.apana.org.au Sat Feb 5 23:04:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Feb 2005 23:04: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 j1674pEZ002895 for ; Sat, 5 Feb 2005 23:04: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 1CxgT4-00017P-00; Sun, 06 Feb 2005 18:04:27 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxgSh-0001Z1-00; Sun, 06 Feb 2005 18:04:03 +1100 Date: Sun, 6 Feb 2005 18:04:03 +1100 To: "David S. Miller" Cc: netdev@oss.sgi.com, anton@samba.org Subject: Re: [NET] Add barriers for dst refcnt Message-ID: <20050206070403.GA5996@gondor.apana.org.au> References: <20050204073311.GA11716@gondor.apana.org.au> <20050205172101.7874e1dd.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205172101.7874e1dd.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 555 Lines: 13 On Sat, Feb 05, 2005 at 05:21:01PM -0800, David S. Miller wrote: > > I "think" the dst_release() case is theoretical. dst_release() > runs in a locked context for the thing referencing 'dst'. Be it > the route hash, a socket, whatever. Unless dst_run_gc takes the same lock as the context doing the dst_release you'll still be in trouble :) -- 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 rich@phekda.gotadsl.co.uk Sun Feb 6 02:53:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 02:53:26 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16ArJLB013734 for ; Sun, 6 Feb 2005 02:53:20 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-102-19.dyn.gotadsl.co.uk [82.133.102.19]) by smtp.nildram.co.uk (Postfix) with ESMTP id C59B72BCA3D; Sun, 6 Feb 2005 10:53:14 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id C05AA361; Sun, 6 Feb 2005 10:54:59 +0000 (GMT) Message-ID: <4205F783.1020702@phekda.gotadsl.co.uk> Date: Sun, 06 Feb 2005 10:54:59 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Me Subject: Re: Acer Aspire 1524WLMi and RealTek 8169 - very slow References: <41A24F35.5080106@phekda.gotadsl.co.uk> <20041122213008.GA9618@electric-eye.fr.zoreil.com> <41D2844E.5070204@phekda.gotadsl.co.uk> <20041229235203.GA5465@electric-eye.fr.zoreil.com> <41F250D1.8000207@phekda.gotadsl.co.uk> <41F26FD1.2060407@phekda.gotadsl.co.uk> <20050122230156.GC24461@electric-eye.fr.zoreil.com> <41F3F632.3060800@phekda.gotadsl.co.uk> <20050125214725.GA6093@electric-eye.fr.zoreil.com> <4204C981.6050102@phekda.gotadsl.co.uk> <20050205204135.GA13986@electric-eye.fr.zoreil.com> In-Reply-To: <20050205204135.GA13986@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 572 Lines: 26 Hello. Francois Romieu wrote: > Richard Dawe : > [...] [snip] >>It works fine setting the speed & duplex using "ethtool -s eth0 autoneg >>off speed duplex ". > > > Nice. > Does it stand an 'ethtool -s eth0 autoneg on' after this point ? [snip] Yes, that works fine. I'll have to get back to you about the other things tomorrow night. I'm busy today. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From andre@tomt.net Sun Feb 6 02:55:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 02:55:33 -0800 (PST) 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 j16AtPPp014124 for ; Sun, 6 Feb 2005 02:55:26 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 878A6884E9; Sun, 6 Feb 2005 11:55:24 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 0DF47884E5; Sun, 6 Feb 2005 11:55:22 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id E2F7622895; Sun, 6 Feb 2005 11:55:18 +0100 (CET) Message-ID: <4205F797.8080804@tomt.net> Date: Sun, 06 Feb 2005 11:55:19 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> In-Reply-To: <20050205061110.GA18275@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no 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: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 986 Lines: 25 Herbert Xu wrote: > On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote: > >>It is just the first such thing I found, scanning rt6i_idev uses >>will easily find several others. > > > You're right of course. I thought they were all harmless but I was > obviously wrong about this one. > > So here is a patch that essentially reverts the split devices > semantics introduced by these two changesets: > > [IPV6] addrconf_dst_alloc() to allocate new route for local address. > [IPV6] take rt6i_idev into account when looking up routes. > > Signed-off-by: Herbert Xu ~{PmV>HI~} Now that this fix have been written off as probably wrong; how much does it break? As far as I've understood it "just" reverts to old semantics, probably not correct semantics, but still not unexpected semantics (like, say, hang on device unregistration ;) ) I'm contemplating just using it as a quick-fix until 2.6.11 to get this problem under control. From yoshfuji@linux-ipv6.org Sun Feb 6 03:27:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 03:27:21 -0800 (PST) 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 j16BRGFi015799 for ; Sun, 6 Feb 2005 03:27:17 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EDB2233CC2; Sun, 6 Feb 2005 20:28:16 +0900 (JST) Date: Sun, 06 Feb 2005 20:28:13 +0900 (JST) Message-Id: <20050206.202813.132742833.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: herbert@gondor.apana.org.au, davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4205F797.8080804@tomt.net> References: <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <4205F797.8080804@tomt.net> 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 version 0.81, clamav-milter version 0.81b 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 267 Lines: 8 In article <4205F797.8080804@tomt.net> (at Sun, 06 Feb 2005 11:55:19 +0100), Andre Tomt says: > I'm contemplating just using it as a quick-fix until 2.6.11 to get this > problem under control. Would you find if my patch works? Thanks. --yoshfuji From herbert@gondor.apana.org.au Sun Feb 6 03:42:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 03:42:45 -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 j16BgaPA016712 for ; Sun, 6 Feb 2005 03:42:37 -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 1Cxkns-0002Hb-00; Sun, 06 Feb 2005 22:42:12 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxknR-0005RD-00; Sun, 06 Feb 2005 22:41:45 +1100 Date: Sun, 6 Feb 2005 22:41:45 +1100 To: "David S. Miller" Cc: mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206114145.GA20883@gondor.apana.org.au> References: <20050131162201.GA1000@stilzchen.informatik.tu-chemnitz.de> <20050205052407.GA17266@gondor.apana.org.au> <20050204213813.4bd642ad.davem@davemloft.net> <20050205061110.GA18275@gondor.apana.org.au> <20050204221344.247548cb.davem@davemloft.net> <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205104559.GA30981@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 791 Lines: 26 On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote: > > Although I still think this is a bug, I'm now starting to suspect > that there is another bug around as well. > > There is probably an ifp leak which in turn leads to a split dst > leak that allows the first bug to make its mark. Found it. This is what happens: lo goes down => rt6_ifdown => eth0's local address route gets deleted eth0 goes down => __ipv6_ifa_notify => ip6_del_rt fails so we fall through to the dst_free path. At this point the refcount taken by __ipv6_ifa_notify is leaked. 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 Sun Feb 6 04:29:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 04:29:24 -0800 (PST) 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 j16CTJw6027344 for ; Sun, 6 Feb 2005 04:29:19 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id F3AA633CC2; Sun, 6 Feb 2005 21:30:19 +0900 (JST) Date: Sun, 06 Feb 2005 21:30:18 +0900 (JST) Message-Id: <20050206.213018.92031627.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org, yoshfuji@linux-ipv6.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050206114145.GA20883@gondor.apana.org.au> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> <20050206114145.GA20883@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 version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean 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: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2204 Lines: 67 In article <20050206114145.GA20883@gondor.apana.org.au> (at Sun, 6 Feb 2005 22:41:45 +1100), Herbert Xu says: > On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote: > > > > Although I still think this is a bug, I'm now starting to suspect > > that there is another bug around as well. > > > > There is probably an ifp leak which in turn leads to a split dst > > leak that allows the first bug to make its mark. > > Found it. This is what happens: > > lo goes down => > rt6_ifdown => > eth0's local address route gets deleted > > eth0 goes down => > __ipv6_ifa_notify => > ip6_del_rt fails so we fall through to the > dst_free path. At this point the refcount > taken by __ipv6_ifa_notify is leaked. Oh, you're right! Thanks. How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()? Signed-off-by: Hideaki YOSHIFUJI ===== include/linux/ipv6_route.h 1.6 vs edited ===== --- 1.6/include/linux/ipv6_route.h 2004-10-26 12:54:23 +09:00 +++ edited/include/linux/ipv6_route.h 2005-02-06 21:27:02 +09:00 @@ -26,6 +26,7 @@ #define RTF_FLOW 0x02000000 /* flow significant route */ #define RTF_POLICY 0x04000000 /* policy route */ +#define RTF_ANYCAST 0x40000000 #define RTF_LOCAL 0x80000000 struct in6_rtmsg { ===== net/ipv6/route.c 1.105 vs edited ===== --- 1.105/net/ipv6/route.c 2005-01-15 17:44:48 +09:00 +++ edited/net/ipv6/route.c 2005-02-06 21:26:35 +09:00 @@ -1408,7 +1408,9 @@ rt->u.dst.obsolete = -1; rt->rt6i_flags = RTF_UP | RTF_NONEXTHOP; - if (!anycast) + if (anycast) + rt->rt6i_flags |= RTF_ANYCAST; + else rt->rt6i_flags |= RTF_LOCAL; rt->rt6i_nexthop = ndisc_get_neigh(rt->rt6i_dev, &rt->rt6i_gateway); if (rt->rt6i_nexthop == NULL) { @@ -1427,7 +1429,8 @@ static int fib6_ifdown(struct rt6_info *rt, void *arg) { if (((void*)rt->rt6i_dev == arg || arg == NULL) && - rt != &ip6_null_entry) { + rt != &ip6_null_entry && + !(rt->rt6i_flags & (RTF_LOCAL|RTF_ANYCAST))) { RT6_TRACE("deleted by ifdown %p\n", rt); return -1; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From maxer@xmission.com Sun Feb 6 08:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 08:19:50 -0800 (PST) Received: from mgr2.xmission.com (mail@mgr2.xmission.com [198.60.22.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16GJkkv004092 for ; Sun, 6 Feb 2005 08:19:46 -0800 Received: from [198.60.22.201] (helo=mgr1.xmission.com) by mgr2.xmission.com with esmtp (Exim 4.34) id 1Cxp8S-0001Ew-RZ for netdev@oss.sgi.com; Sun, 06 Feb 2005 09:19:44 -0700 Received: from [166.70.55.125] (helo=[10.0.0.2]) by mgr1.xmission.com with esmtp (Exim 4.34) id 1Cxp8S-0004jo-3I for netdev@oss.sgi.com; Sun, 06 Feb 2005 09:19:45 -0700 Message-ID: <420643A4.9010407@xmission.com> Date: Sun, 06 Feb 2005 09:19:48 -0700 From: maxer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050109 Fedora/1.7.5-3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: skge no workee here Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 166.70.55.125 X-SA-Exim-Mail-From: maxer@xmission.com X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on mgr1.xmission.com) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: maxer@xmission.com Precedence: bulk X-list: netdev Content-Length: 1313 Lines: 34 Jgarzik wanted me to forward this to you today. This nic is on the mobo. sk98lin from kernel 2.6.9 works great. However: If I go into Fedora Core's Network Device Control applet, it shows eth0 inactive. If I try to activate it I get: skge device eth0:1 does not seem to be present, delaying initialization. Under Network Configuration tool trying to probe under "Bind to MAC address gives the result as [Errno 19] No such device. So while the driver clearly loads, it can't find the device nor activate it. What should I do to remedy this. I can bring up the device under kernel 2.6.9, but no kernel beyond this 2.6.10 or 2.6.11-xx works. 04:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 17) Subsystem: Intel Corp.: Unknown device 3065 Flags: bus master, fast devsel, latency 0, IRQ 3 Memory at ff720000 (64-bit, non-prefetchable) [size=16K] I/O ports at a800 [size=256] Expansion ROM at ff700000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting Thanks, RaXeT From romieu@fr.zoreil.com Sun Feb 6 08:50:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 08:50:45 -0800 (PST) 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 j16GodiI005319 for ; Sun, 6 Feb 2005 08:50:39 -0800 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 j16GmFfP024477; Sun, 6 Feb 2005 17:48:15 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j16GmAMe024476; Sun, 6 Feb 2005 17:48:10 +0100 Date: Sun, 6 Feb 2005 17:48:09 +0100 From: Francois Romieu To: maxer Cc: netdev@oss.sgi.com Subject: Re: skge no workee here Message-ID: <20050206164809.GA24316@electric-eye.fr.zoreil.com> References: <420643A4.9010407@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420643A4.9010407@xmission.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 199 Lines: 12 maxer : [...] Interesting. Can you send dmesg/config for the working 2.6.9 kernel and the dysfunctional 2.6.10 ? The brand of the motherboard would be welcome too. -- Ueimor From ecalicchio@yahoo.it Sun Feb 6 09:10:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 09:10:46 -0800 (PST) Received: from web26809.mail.ukl.yahoo.com (web26809.mail.ukl.yahoo.com [217.146.176.85]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j16HAeEY006665 for ; Sun, 6 Feb 2005 09:10:40 -0800 Received: (qmail 74386 invoked by uid 60001); 6 Feb 2005 17:10:34 -0000 Message-ID: <20050206171034.74384.qmail@web26809.mail.ukl.yahoo.com> Received: from [151.41.232.52] by web26809.mail.ukl.yahoo.com via HTTP; Sun, 06 Feb 2005 18:10:34 CET Date: Sun, 6 Feb 2005 18:10:34 +0100 (CET) From: Emilio Calicchio Subject: questions about ipsec-tools-0.4 and linux kernel 2.6 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: ecalicchio@yahoo.it Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 33 I am a student of engineering in first university of Rome (“La Sapienza”) and I’m working to my degree thesis whose title is: “End-to-end real-time applications performance measurements on VPN network (both terrestrial and satellite), blocks encryption algorithms vs stream cipher ones.” Since I have to use a Linux based test bed, I must integrate the stream cipher algorithms (like Scream and Seal cipher algorithm)in the Linux ipsec implementation; at aim I wonder whether you can help me by providing the following information: Architectural description of the ipsec Linux implementation (both tools and kernel modules) the files of kernel version 2.6 and ipsec-tools-0.4 that I should modify in order to add chiper stream algorithm if someone else is facing the same topic. Thanks for your help Best regards CALICCHIO EMILIO ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From bunk@stusta.de Sun Feb 6 10:44:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 10:45:03 -0800 (PST) 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 j16Iis6I009354 for ; Sun, 6 Feb 2005 10:44:56 -0800 Received: (qmail 10378 invoked from network); 6 Feb 2005 18:44:47 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 Feb 2005 18:44:47 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 0B526BB997; Sun, 6 Feb 2005 19:44:34 +0100 (CET) Date: Sun, 6 Feb 2005 19:44:34 +0100 From: Adrian Bunk To: Christoph Hellwig , Jeff Garzik , Linux Kernel , Netdev , Greg KH , Andrew Morton , linux-net@vger.kernel.org Subject: [2.6 patch] kill IPHASE5526 Message-ID: <20050206184434.GT3129@stusta.de> References: <41F952F4.7040804@pobox.com> <20050127210731.GA2953@infradead.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline In-Reply-To: <20050127210731.GA2953@infradead.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 59623 Lines: 845 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 27, 2005 at 09:07:31PM +0000, Christoph Hellwig wrote: > On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote: > > 1) iphase (iph5526 a.k.a. drivers/net/fc/*) > > > > Been broken since 2.3 or 2.4. Only janitors have kept it compiling. > > No, it doesn't even compile, and didn't so for more than two years. A patch to remove it is attached. <-- snip --> iph5526 does no longer compile since 2.5 wand was therefore marked as broken. This patch removes it. Signed-off-by: Adrian Bunk --- drivers/net/Kconfig | 9 drivers/net/Makefile | 1 drivers/net/fc/Makefile | 8 drivers/net/fc/iph5526.c | 4645 -------------------------------- drivers/net/fc/iph5526_ip.h | 24 drivers/net/fc/iph5526_novram.c | 278 - drivers/net/fc/iph5526_scsi.h | 31 drivers/net/fc/tach.h | 475 --- drivers/net/fc/tach_structs.h | 428 -- 9 files changed, 5899 deletions(-) --4ZLFUWh1odzi/v6L Content-Type: application/octet-stream Content-Disposition: attachment; filename="patch-remove-iphase.gz" Content-Transfer-Encoding: base64 H4sICNo6BkICA3BhdGNoLXJlbW92ZS1pcGhhc2UAxDxpcxpJsp+lX1GheTsBEiDAksaWxg4j 1FiEEWgAXzs7UdF0F9BWX+7q1rET3t/+Mqv6PhCS/d4StkRXZmXlVZlZR6vZbBLTsIP7Zrd1 0up0mp72omlZneYyMM1D3TNumccPbeYfvtcce2msWo6p73Tb7eNmu9tsn5DOyemLl6fHv7Xa 0YcctDvt9u7BwcHTKOepvjptvyxQffuWNLvHR91G55gciC8n5O3bXbJDiKqrru94ZMFM565F vjgBUU3uEL52AlMna/WWEa4aOvlCfIfszfqzIeGB6zqev0dUWxdEZPOK2cwztBjc2iW7Tckl GV5f9mbK8XH3ZLe543sG91Wfkb2h7TPPXaucEYSRuaqtHxybaGvD5cwnC4DokkfmxYSBhM5c ZuucAO5YmdNBn/z6KxFcwO/rvvh1Pp28V8aAvGamC78ImakPIMeaeYwYS/IAsgr5VDIwFtDW X6u2zcxYJ86S+GuDkxvD1lu7TUFi7hDNsVzDZBImTUJUDlQsRw9M1gDuHQckuhIjnQIeC0GC wp1hmqBuoqmmCcIZ7hpFR/okVNbssnetTEGziaLmnrpcgm5na9WF4WrKZ8AYXinjeW9U3wPU rEIulI/DvjJDLaQxd5tbO+6VesOWIGWZ5746ffHiBzw3Il0ke9Qudd3Oy6PGb+QAf0m/dRZf m/9T60/Gg+E7OlD69OXnz3Vy8JosmUZf3t8fgudlkXrTK4GgetbhbjMDkv4ju2uHuX6gSNq7 vh4poL33koLrmsxXzZs86nwq4L5zw2zPsFd5+KfeWCDcqfbhEwwBPKUVdtTsdJvdI9Ltnr44 Pu0eldrhUGe3hzZQCnt0YPaT9otT0HL3uFzFjZfw1Gijepu/wD8SDUqWMBMEqzm2QrxXpBes CIzTbsAEQod13DW5ZKZ5B678+1pbvzXspafqTNVbjrd6g52m7M4zfJ/ZGFQCmCsm9OPEsLkP aDjxjGVTuL7FbJ+3xFg5uyUhpb4Dao3mkfM03UbdtLxyj06h9Wcp9+jk6DjR7+H+T/nsNsl+ LLZ2CjH2UETAMCSh3TD05GMsRsdMvEM6OzsQmfqqh3EOqPYd98EzVmuf1GBmdF69ekU+GjaD iHxFegtPXasW+f3WUuXXt2vHt1TDbEFkfIP9BY05hkfXc1YeIMPXpccglThL/0712JmIvppq E4/pYHvPWAQQ5wwfc8ohcC5IQNQ0lg/YGtg6k+KAMBaXoZmRd+MP5B2mHdUk18HChAg5MjRm g6wQkQUNF5v5GiLt4kH0GSAfs5APMnCAtOobjn1GmAFwj6B7wDPpNkjESE31kWFICS6i1oHL B2KqfoLdqpQ7EQ+CvS1YWDsupg8gCqJF+QCmAThogwCmoPNpOL+cfJiT3vgL+dSbTnvj+Zcz wPYhM/uE3TJJy7Bc0wDSII2n2v4DqEZ0v1Km/Uvo0zsfjobzLyjKYDgfK7MZGUympEeue9P5 sP9h1JuS6w/T68lMaUGGZCxSrKBSoVz0LcsB9ekQCg2TC+l/xufwJ86OkbM63W3m/XYXMk6r 022BS89kPUGswPQNiOrgj56OsrRftDrHiNHTdVDtAPw8qWsQDmH3KIGP6TWSycDT/dNFE0Ih KL1MoL3z+Yxce47vaI4pwV1BfGDcAxicU4XCwPMC4Xrkbg2Gjzn+PFCmdHrxBcoPsIbHNAZz HydxG2rL35BKH+YYeJfpqDgYzApXBV7D+fOeeRAAWiISrADMmaW6azAsb0nuwK7RR9hbWzPt hgPBJT4Z9q1qGjh9bKhalNmcQLT2DMZDBlJSnnvAgKZyH8IU4X6wXOJMJ0shI7AY2IaA+obF 0L8XwQqI/BxXkF5F5pOLCTjEzpTO6XzykWCBCemnc2xxpuHUHDmOCy2uYzqrhxYZM2ANEEB7 EMkJYrWkPmZX1xCHOIoNLTtgKNK7GM76ZH4fqQaLRKgTUDGD0eTdsAWBZP9wB7MY5jVwJyj2 QF5trXpkPwo5ryX9vSSq33ZabRLrMnTmKATXSkNw/V/23hkO9Itha2agM/K7zN+yCG2t3xRB N9IRykDM82ynFOJqRmm7YRt+BQAiJjpyKdSySpt1ZqoPpRB+swA/Kh9pSVXPLQWhh3nl9FzD Nh3tphQI9QIkfoh/pdClFgMJuNoaihicXzrTTNUT6YWLoImqoQKZqJZjr8B7MPOKj4PZh5MD EtKGemhJE8IE3Tg18l6rdQj/uMYN8aO13kvzFbfTtcNzCg+7LrUj+O+KjumuKrcO+QOUYnmD IMCQviBmVFhpcJdpBq5O1lC8YeUBZSMX7CYj+rCyy3IomijkxkCDCi8LCv2fGm4FoChwDLKd W8i8LU0KpUMRazMy/TCmvXntvk5qXw1YSTHUMzzW00gXyvmHd1QQgTlX2t6paO9iO3KzzFBJ 4V5Ph+P5+xo4gaX6DaK2Wq06+duFlYJ/U9v7Bz8lew3QXPONrVqsfkb+JVxjR7pHiBZ1/uUX tQJjD+Z+/ex7Mi6s+5QpCLqzxVAxkTj8kFOM6AyXM+QfvIaRpUHuMwOMlN5H5UcGMJl6m6Yv ycMAzOTsUQWWilrKHjbCEtlYlhiqUxin8/9nqVI5O2WCVrHfLXTv/pfZ725mP0Se06vZu2dx WsZnERwzmQzZGw3fjZULOhvMaO/iYlpTdd2DqACfwObGyoacb0JgrocAiBKIev5hgJXWbPhP hTRJp14nv5L/VECapJRUvchEzEADZoG9mQtASI2cPFWPlqo1ZJQlkLCpTCfUiHeeKLb6C/PP v8hr8jfo8G9cItKPyvhiMqXDCzrEeSUW2w0BkZtLWYjwQwmG9QrAst+/N55P9/5xut/B5ljg wdLQsGU1ioXog8hB36EWuppcfBgp0QiwJhopNRC7kddBXdRNIfYIcMczpbb37nq0JyGRAa96 n+mgT/u96cWMdPNqXmrUsJcO2V9qf6YxDzp/ncW4sdHAU4VhDO8bhWKCneXJoU1ibL7GpQYs /nTHAyOeFWGxgREmy0ucP/AEE0EDF2EUd1vA3JRiOSIWGJHpn2359FZudjf18ry3J+30bPNv Q7zd+C5tHasPFOoxP/BsCnW+3FimcQVaQ7UDRoPcOjAX9kFroLJGPFN86rEVFDH4s56YRCAX iFHgRjeZlyW6T8qJ7pOIaMIq9gNbGLCc+jdDLLAQ86jriDF4reBZBvYX3GiQQG0auNRisER7 qEDNDJUIYPgV+CnsRWCYOv0WsIDxzdiCH4keDSFLwpJuDRKgAon1IFQkHzyq+Wb0oKcA/oPL 8LvwZ86+hSDxqC+jXnICOPchVD568lHOBHT2nHgrBhW5x1g1q+USKhfnpWIlAyU8LE11xZNH DPYVTJRTLedgUsFBQU15bcL40VfNTqvO8oPH9Iidxp9CZTVCz0XH/hYYHouHWEINziisfnhh +uDWL6O+E/tI5O7beJfHYNlOTdXX1ltjh+NscMJb1QxYcZrfsJhHZ7nE4LzVmKoeLkK25tDA A68tsAMX/IrRSf8PQNHvt+8xvKrsIW2oOYHtV3SGMuf8qQNeberz+JDZ8PHEsWEObdtDBm46 uEplhq17gYzP6TaZTJ7TbfbM0SC1PnM0KG3pp950/Fzd/Eh/dNgf6f/BvrGdO5sORBx6BoHz gBtM/4H+EAVw4/f5FIb2Ag8nJJUZwAP+w2T6jmVB85PoRFuZMB0txrm6YnG9Ux1RDesb/qaY uPMEl4ZpUtNZGTYVaWIDGcQqli/3lN1rYst6iwycS3iZEiMqK/IJUuTBstSWy4zVmS7kE3Jw wGztGXyGqTjN2aa0nMv5YZbGuuOpOTrMh4YIpcJKG+yzjzc0qOt7eRvDIhRTPK5FwWeoBvGc PYeOB0XtLQM/caztiaVVqlng7pqjs5yINjSheCuGs4G6HrvdyF+wXAoGcmS4oSdUNhCAqavX z0pWioIPiW06zg0W8tXyVRaxusFdU32o7JqZQ7K6uRfGfWTupV2wUB9JClTVtCdQSXlueFpF hUeXUHc9cxN/WhjL0LjPHAGYczaM8ERqKlhhkypiV3wut5x6X/1n8ptuVznE8ogR2cjuXdPO zxNJ1RVWdm62mh6NcFb8m5UpaKOnPFEbuKkB8dW7hfoQItsGwgAthBWu2VtkMTk5y0bn2jYr RcCi4rwpu0dHcjNY4KIFHA9CnThtfmosEiRc5uGOaKUj5vFNR1NNisfSFHtAoK3cPyiJ7cIw Yi9pA7O+p9pc1UT1kOTMsqAc2SqJ948OsI2nILOZ6BgapCpG4j4iIvBWqyX2D9PEbIdTB6bh tjaFiO5ujSwNTyM/2LZb1nxbdyvTSXkvoRNxh2Emzu1TSkGLhd7AWYWZZngG2QeDk3382SjP fbbxWHaE1O+Yt7g09FbM37TxITEqFoeD/jXtX40vtlghZjZmZlttzEQr5u1XoJbq3YjjTAql xJYhNpRTTqs8wfhSBrChzOZU7IQ/bwIJ8y7QvzbW25nKtODVZsDX8Xp+U+lWTiQyglCRc1+q oworPNYl7iRc9NLhPp0zWOvgjVt5tE396Pk1XmEWRwVyUdcvFFTRUUJ4gyUa0wbe5Za82GQu bvtGJxCes2B4DrGxI/aQ2/bZjlWddpu4rW8sSa04DsLJ69ekXceDM7lVTtp4ahB+byrjyYXy UZ4cZJguY2ET75KNohVArQBuvnFB2zgwHvbh3QjRfCbueQNUrA3Q86EdMeLnGMPwvoUw+HYW ShxTRiHHH0ajOkFBU83Q4wzbxCULuRseahqPk3ocoyEJPHLV65Nw8YH3fUQElHSwH0L+bOPp WQ05WLWsB5lTRYWyNlZr8itp3+Ol0MGg3a6TN2/Iy7MChc5foQglBIrY3arxTOdODIdD4UcM 1z0qUnjxGAXJbkihc1KkcPQ4hc0iH1eIDP0FcmZRI+ds2k8rvDJlzY3uOFPmNDzqm3waK9PY 9oJJx2U2ia8VU3yMYXjHOQXTTIezGAiRWafAFQhzbwE7CR5nUPW4qnbD/BhbhDYQgafw4rZk QGgRd/7wjpyoiIh06RhDhmdq+UGasbhRuLlAhNo1umP3Oh+zYmp3uL+uOysJAMTj/ct/lmkf pklybhWdK4mbfbh7jtdbJ/YIT0xzRcNjJ1DSQvJGx14aWRzEiumdOZaCLjKUiWPMHXmxYC+D UocCyzCZLilk4p0QBaf8lOH1xVsmL/uiQx5iBULQK5OZn97hjzLJTnojP9cYnT+IamgymH/q TRU6VcD/QjR5SaVEzpDJTkrd5yiTuFx2RP7gpEmGV380yKQPP8SeOwyBv0h46XHk+OK2tG6p 4HorxmEysPAmaPS2zcVVjxPVtCAB4r1i78Ff4xE62MmR15/xBhmRx4vipu/hk84HhS1Fqmt8 BUHC4mU/CuChkdNU9qIQPIx8C/n5A2Hko+oZ6sJkqUiMEeRby/U9cdWNOto3ipcrRQWWmic5 tLW7HR7uZEKC03NoGUQcErNSgQoCTBFI2tlGCAXFxvQw7fwYyEfpGAgojIGNhTGwMS1xDrRx eGvJFxUMSFCBBdlcYEI258fKACt4RCAWwaUjISA31goBFCFQyYnTpjLBeLVgvFwwXi4Y3yQY 3yQYrxKMFwRLQPqihNJSc6lYXFeZkUG3UlkFQKqqSBZ75o7kSomUHNulCcWruXwKQ2Cy2s8B Vi2xjA4w5Q56o5mSAFy/vN007JtSQLjGdjEwC3fIwW1ZheDdoQJMd2xfVhjFbrIXLqIpXisv MvQYgu1QZxmubXnWiTmzsg2ZbZ4iKVBxYnkIoiKyYoaQ0RJzp6zaCrGrFi4165TG616RNGrv Btf0vTIdK6MGJNmyXCuTK96Xh65iNOxZnmyRK9QCWAgTGSLLvBF44cXhHbwsXZNyEIP8jjh0 pIzfzS/h+eBALFlSMuiLP42omMyJdUDGEzoZUMgz06Ey2zdyioH8Wa6YVMD9eYrB0TYoJi82 HoNWiw0csrzcMdePyX0VlwkFyTOx/ufJLkfcID2UGOAWtZosEOplDMFIYaET6gXKkxfdeMlm 4pYmLNcdKDnXwQpfWAnsGyyAwvKl1SL4OjAnd2t8uRH3wmF+LSBgrEQ9IQ/FUsWF1E24+qxF xctmZRzXyU/QBsiDJ6X4Zkq4+GSilGOW6z8QGasrZktaQdJxJCMC76vE+wp4GQ+BphhxZ2e/ 3B8OiLGf6QUtX0FYsvYd26zdGhjmHMgkPLyHeibJCQUevCZX2SuzAvo9XYLPISDYgbVg4v3r 8H0i1AGD3ILdQ8nx1bqXLUT3mHj56aW0X4LBEar64oI5kAi4eHmOHLVfnTS7xydk8eDje06f xKt3GIgsSQEqY9z2cTwVsgCH9Zp8300ZzSLnkO/44bt96GdgTwsXOxyil3irT5LByJbYDTmE QhZ3V7OFK8RrMypS5C5Chd7TNs2a4CztAZ3QA3qf6bUyvhiO39HBtHeF5k0HkMywRrIOT7c2 O3/BuCdi7yAdOWbVkYP/30SO2bMjB89GjllV5HjuTJsVZtqW80xOszCu3FgqRq78hfL9boMk qgqnEqpcdgt3tf4mcoqFmgulDq1ITsPIR2zHJ2oYH6NFcFaRcibu7OCN/jAMoP2c5VKWLOV3 50NCOQvIjWqp8bRIEXrGQiGv/M9CbPn6V9qPoiVjKp5I5s6KMYv/cMz6HsambeLS7L8Xl3rT 6/K4ZNiOJ96axlU8EghfQSWXn+j8wZUu3r7viO2a9v1Ji+QCk+q5kReBETZMLdDnrDI67Rfi h3JxnkSPWunaZLvQsVWexdGeUHHh5UEQo6zcYsUqM2b5gHQLFZZ4I1a+tYeNk890eMGJh3ty BA84cYeUNOHn0WAwyFYcaUdm3H+qWraIqMjbE9QijpKqK1FkMq+bhPGyUnSnRNKn238LQbc1 P5GCSk7xAC8O1yXiAqfcdIoiJ+5QQxIY8Q6P6pFn5OSNF+s/PV9Gh5xPsbAUPOpZKnbEcF7s rCDVC4+4PE+iV7QHeSlfHYUYd8dME8v0qvlQvg+xre62CBjZAZ6uwnmvf0kvld6FMg21SLJq zA6QV2aZfAekcxLPmrQiw9wuXy3WDS1auZChfIr+jtMirj7xLwS96IokQ8TFUFW8sE9yu6ml O6lRmdLdf1GsTNBM1X0ztUqk9irsjTVLwQibd3+rBhEnIsK1Airfm6vCrJN/YKGY2LCIcnAQ 2iaFUNhffor28p0fUV8O/Uf0lyWV0V8WdLZBf1nMcgVmcYQGswrMb0k/RX+5vo+oL4v9I9rL 81w1yCblZRDLdZdBiVQXniIVD1Lyp0g/8jqOOMyRsRbq5fA+yiKQRoxuAEp+woOdavrhS5UY 0PpQDHvyhIfLihr3SuPsACWtOEqTEapysRft+YmFR7JjmCz0KntGu2aiZ7LptkXPqAIUPcPi Ebq93Nwrro3kGikprrYYkadHLJQrQCCqPDaTKckzDXFvoFGSx/DvGiWPCfUnlIkiJcdXcmTW m3weXtDex95whK/knlWm1A3lWFSKiRPzgEu6iD+YKsr/tvfu7WkcS+Lw39pPMdY+yQobybr5 EivOWQTI5gQBAWTHx+tnnhGMLGJuZsCWTqL97G/Xpa/TM4CkXN79RXvWkaarb9XV1dXVdSH6 8jpysTkBUudwC550h7gJ5+FMoSekgHxAsYXgN7SBE8OAoYq/3rZr3WrY6barpVNy//4tEL9X nE+tkoB7F1bfCLL4LQDfH1Ha6VRPj+vvwkqtA62Rl3tWz2qTvIWxorZcbSHzyPa9IKorse9Y YxB9v5XbDZ6IEw59MwUFKT04bwosDTelioS6lkxANGbeo9N70sS25hzmvCWknLSENjbydrCn 6wSy0jAeqzoWK/IOyoMJZ2gGK3PHp+r4VgZ0+96V8b67Pszh+QyyFLmSbS1HroR0kWvwOgu5 ss4tcGvPZTXcWnVUhyZySV3uRW/6Rdl6INjGk8/7VHyaDuCw9C166aJore3yZdGw7sK4U/DV MxeHq6Vmma7HL82qpkBxZULRTIcQggv0TMwIMDbddBZfxHM4kgUP4EeSwQxsRTDGggBPJmD0 A1c3kiaAdQzmWqORGpuxWr55YaFng3WyaSD9+N7JpAH7Vb2TRwPJLWkgWYMGkkwa6OTSQJJP A0kWDSR3pQFafaKEZTQQ+IkgySOCJJ8IQHPl0MDy9ZDy1grLIUFTq2FIaenFgFoORgFXiE1x 3R7MkyCky3iIEeUspGDTDhE67QvByV016oWwXaqH3dppNfg2qIYVDG+H5lswBAdX3KUACd+U 6mfVjt3RxUhg74s5jW4sCECKBqLN6aD3KYgwhCbbyEIUw3rYKlkd1JvNVlhr1Loh2Lzhg0G1 k+7MJ+i0Y46f9vZtgzSl1Wqr3TwNdoLjxbyI6o7x5CvQWkRGuoM5BlvesUbwttmuV8K3tUo1 bJROq2G9+TbV/devYzA3ddfarfq69uq1t+7lwBi6it20CcLyu2ZDG0eCAZvYHXUMFbmzs4OR iYxjWOCpVqqLpfchaD6bDNUINzb0XW/J3cq+7a0RD2VJ6BK8BHKJsp0PHqKZ4EuueqQgpJEp FGOwmYfqt5fBViZQAX7d/kF+0O3Z9uOyfPsHMuamCzVF3AB0QVC/EKL6QYCdJPoSb30LCBaN wMciASJic8K6AF4kRmTwFmp5MZZtC5l4PpllN8+38Fr7p/B1qVGpVyuOCfM9xpb5ay8QKmql 1IcHyJH8bLqNF4PeYjYT5TJ6RYznbxEOoy/62xEbl8LvxYDsqOTznDKDktHjNuW+S5kWM7o3 l2uTHkhvAlQh+8YYCNZ7OdzKkfALUn+k31oF3ws7pK0di+tscBlNwQQdGZrUWckwHjiAnYCu j7XGqwBDJrXPWt3OgwcP5Bwlc9m92iWuMpDSNlgph5dfU7zlRj1TpKf1Q+C5zOBF3MV5uu62 r+4RTz+zx+9X7tG6xWz5Ll3b6VEV9KOM0556IGCiRHSRfgHxan4QvWvlQQrBBKN5N3rimLXB TWJfPkcADTAJhGOwxJZUsBOcYjRu9uAXpy94GZg6MUUi3Ym4tkd9eEGBSN/Hoo/qbDYR1+U2 QGNwtK1BAcYgqIRMB9K267q9ZTS2PpEZ9j72TvaRjtYJyf1/FEjqsFaNPysLJou/uBZy8XsP jXygFTI4kKjGO9lqjQlnIycwBsa4cUJgbOiXLMNClc03C5CrYWvL7l1dUDEMSiH47bcgBdFZ CmGGUikU6DFq41wQ7ScclBshCIa+J6/fqJuFmM865LfcJUR2d2B/GbtesFebLOTmsJabXlw2 VqQgIrng8UO48k0uKKfBZDJ9+NiUpvyHAUfnpePbr0JfO2aOdokwzqLcVuxzyUc/v9LzxHKH E/mIYdgZYkx80VoEoegXczSfpI3DEet/Mh8IHRXtVuqeWhAXQ+sNuGAaIXrjGUm2k02NN3qh lmNKesucjSFOd9wPy2B6fiykYzhRgzuGLMpbvtM/Y/lqP59WX2CGBWDvot3nKhJ79ro5Rmmp BTq98wKd5i7Q44f26lTBRfxxxt5aPR6U8UJ1FyETTK1CV15ZLmjaxOAf9e9IDLdnx2vLfcF9 CH5rS373J/qhRikGU7n/mkNSHkwGACF4gmiOPC+JRqTTZx3Xx2gwNrZTmkCUlGF/fUQKxbSc +UD6Xtuft1+yBvJ3EHvSg15L6mEB1gR+4AgYuEhrS0bpcfEBD/35MG0uPPXpXQ96p/ce/PlL 4mNzFiiO22Z3Obs9dc+/e1A19qn/OoBQmFYJX0zBcKh51j1unjUqYbl5Clmsas3GC8SWuhB7 IAIekQoMIUV9LTRmNR7Wljcf1jI78MYsVDeSdPfh61ooesqdXRpmjfmlK/tm6INatZNag/AD Z2XmNPxAy9DoP8CzBgBP00sHYAMtXUcr0uWyAXRWwUBnLQx01sLAWePHRvNtg/wlUuvshVo2 gKwwlMuGcnzWqVUr1EfGOEyQZcPICGaZNQpCwOmrdqju/M4gPBDLxmDFWM3qmQ0oSt2zjtOj UbLq1jLvB05rZtEqROQRPbOmcJrd6+kavZ6u16t59rgEYxQt6zVDzF5GruU9fH0SrDCDWDXA qot3DMuNoXY8e8AuXEr9WaFYc6bFUVeR3nK5UhpwKY5z47ou5ZIYxrV5elpqVLJ4pAGy1mDS 0WFXGk2l1C2twLklaOaQwEdiPCRrZukJzcpN3X0/vogWw/kLVNxoLWX1pHRWTxNXMWCJ9pur TZ/c6VyfzOjiNPWbjPvo0rDK+ddQfKOyY+OxtOpkcyA1cREDu2IIgyJVG0H6TI7YdZTz1gPy P/z6O7z2OIHd1PV6Hn303YUtjNGS31JHm8KbvODa7T2C/Cj4UCcV9Vlw+wUjxpHCdE6FA2pY 0bg9IqY2ckko2GX80vhRNO5Mg4I2UcglNUtzmVNVjkzfNDEQiKhOtv6cybK/QDMM4LwhsN7f kKuW6q0S32PhOR1e0TGtXzCRmw8CIDYX82QnEKyTn/bRDIQq9aIFPEacXwfmmc47Y6avyNLG WeL/ZdAsn8pzIGy2QzkaUn4/4OgGVjxDu8gMfFAgF0otkgBzl0MHLwf0twqWLQYruWsJJh+l OIfoTscJOhOwRAatGkRM+kfQAJtwSPp5HXycTPqEOXZXYcUATTq9fN+/RK9c5INg+MoqfySG l8FJmUoAJ91S+1W1S9p8KP7ejMZVMB6Lahcw6gEkn1YrVYQFncXo6TdASx7d5A7lm3sYVIdg 7Qv2E0MI1gXqDg6nCwQDttfbYr47QSmoD8afZK1ZvK0MGjCpnaa4efQJkDQdRr1Y9vJY+avm zJHdzZGPmI/F6E/EJPU+jcxvNS4FKj+wA+htqxsRR3jEOB77pZdHuf2DOCXECSTqVGoVYy7B 998zC4GfrYcEjBbP4I9ZoEalAyy52io9mD7KoMeAT2IkusmF3FoP5EkJGg1IYQ6L3sWTUmLb 8N3lWAWjQZKIpeHYIsBExGIobrex4Q22KcPp2RFbeOjggCQ2Qp+3yFf47wRZwldBbRQNGx4O LsVfH8XMqRZ4sH6NrtGxNZpRmllIpyvGB4crJFlHT1TR3Kc4nqpKl5MpUBZ2BVG5+uApMBSL OYzl3JE3CfqNg/Oo90nVxNzSO8GJthYSYwsuByNA644EI7xtqMRlm6eEMNm4YCB9wUBsNMpV pCgSW5/TpAJE9Hn7BwJH7v3SbUPBqrdb6vGbflAnJIpxiq7NZmTHGxviK0ZnFwOEBKOQ37Bb PW110a5kQ40BV3ExwsVNgh9YvbUhfbBV0fa2qiZDg4PiqVrvhC1oH4fRt0aghTJNzyZBbwAV iVrj+GpuUT15VgMNV0ktZ3JdxW3ZmMtyRxcT0ufzD/DS9KumyTHklqVWgBCNXQ+kYLDIHfng RYxKRmtIPp2Dy3V/R31m2gCDmU/kv/DpHGx9tqSclHxCD2khHqE14XwSgv3hlnPMqCgY43g+ uAi/gj8COuhsccBLy+PcwIuaTworJlQGiGVacuJFS7Lo9YTEDInRr3f4oXeAZwpARmNYfjrY uBOxlSIDzfAnoDUkyg3F6QiJQOlsIJCtwZhbwIuDGG4UQNgmePQo7ARnH4fXD9yzUwsMu3RI GjLZS3SAxWkpcXO5MIXv2JPxfDAWIhG62+P5qMSMILqAZN40YzhQTczw2W5ibiewBmkd/4ZY iEND+UP8yovMGlv4IIkXMQM7DVMFv+DtA9H74vm/ZRSAoAHo7GDAc8FdkzkYSUoKlTE9rBji ou9u+6x6ZIHY4pUZPUrDRMNphAxfvSHBaQnBYDsSMB0DHLiFG+1bz9rmFmrCLXPC+kXMCdMF JMBhsnTQd/1cpjiad1DOmKDXBnesxmYyrXuYWVrOeWEIEHcXc+5JzskRdNaRdJaKOt6zYQ1p x8awVADckhBxLOow8dP7DwbBK5xocHcL0TbTyFtlo2WFpVcKF4m0FXfkjTOlrDFSo97A/7Lr G+fQdY5WkOrO43hss0iTN8rrAh6y8mAlUTFK8IQlFQ94G8hm03eGvFPgB0x9+uufcTp7DR3S ug1pgNJGuz0WPwHXYLfXbDY5ZEsqw8CqOcLy1EvwESfAvhUUI6cYTKPr4UQc1pCdg8HoSVNG OMLoUZC+nCIfDDC+TRQk8RSSmMcywg0u0i11NyqYUI7ORsWOFj/PoJKezAoVzWPfqmj8oa4/ JkqWKIi2Azbql06wECWGvZejYW+BYeLnk3k0NOIEWbGjbGQ/emktSPDYFxsNNoIF9Y0LZRgQ cMvSH1wMbDqbfBn0tWMnXpSiMWaaxwiM7hAzwqaKsVpd2PYrKXDBP23zL9yqKuefDvrtVnwc pAKbZQ1p2+kDBEwoMI2UjCSEmD1JJhyEHZyl2F2a1C9z5xWNHA1aGXo9jQFxuN2LmAZqxR0K pv3RDOx1GUj9qWJe+RM43HVru8xTcFVu8ussmobRDB4M5HkmrSKwCOChK3th2KEubSZ3P9rg vxhHUcK/BflNXy5ygH9BonsPBRTuiSepQThtoSbD/Fb463IwPQmXknEW1kfDgG3LhkZr1O9l nDiWGZydFMhisCBLVz+yqqSWPuXJgds+HkH0YbexLe7nETer9ynF64CLLNT08cH0oBH0Gw8o qkkc8Ac66tGGZ8u64NvILx7HV73hQhwgxDZYX+iOw93uaUal+qRpsm3XTT5iRUtmpfTMEOj7 nGltv3ShH3mMk9kJwh2I5YD9yGbG0vPBZIfqqi1FRJOE3ca/6Wt+rgMsftP3cVPmFvmnQZoP y639SjTtRNlCl0ry4jVFOnV6iU5Nedm2H00FJrUGlgq06IyTpW0poMRXQhgXhw3EIwRuQ2oq sq80T04V4asgB6MH+yg4VIyaWDw+49GLWU6tA3UunOAPOemZJ6nBfc2KT83nQqMgFU/g8aH9 SujM6JsrEgj4V9kl6YvSckPRk6gJzHClQsmsQVsiIJ1b912rGtbr5bDTKLXw3gwXMvIDxPhG cHHaSh0LtNkA0tYOTGcCo5+2IPiSuIF2a+VqsPlN8iKojf0yVCE4pXhKidjIMQg2/dlkikp9 Soayg/SN2mgYOm0u9qLEPCg7s6sQ68R96fexhqC6sb6oypFPbyGt3k5eXS6xyhu+tlegDzA1 gw/x8JWwJmUIl6s89AZiJnXqYCirWef2tm7xyFZzmj19g8oW3QQzLwVilBrxbFO8K1BBZXvT ayDCcAoptT6dG00VioGRE01/ZoOVWzAzpQrw9avHbfXrTEcpTzLbsfaZ1VR6Bwq6h9xFQEy0 VZAqRDNYHARaMWZqxVi1xraHzFORw0oGskN/+nhNwUqI8/cFMvMC6fF1WWLzvX5q8vW1POmb VkZ3/5fuXOzJwdo1DFW1oFlvstISafM29AxEKmcrpInUzbZgegt0THLxOAjkLUUWtayeh/4+ iMXf2/9xWjnHSf+1SCVnITIpJcvM9bZKLPE7xqKjy1+RIOP+uVJusVTamw+LZjJ5ONRmFA6H X2IEksRk8G+d42g1JdjA0HNxImtOeU//Usa7J3v7OrWYYXOB1OGzRsxC1v8lUl9dkUQYWl1k skK/665Tlz/zzge3K0EpGXeq/ewr3Kp3t5WvbLN8QABhCN8jqo5mPb42LQXB/gi1qmheQMaH WDACc+IYzSnoq8wPEs31Y5qKM4tPY9BXkTjOeSwucUMIT42WFlTXsJcRXAeYWJUT9IJmF+LW Yg5g0eU1Ou1TKDaq+zZmVjZMKN41GcaYTSqTTtH4VyU1chaC4Ge4M7Qr72iihnppR/PKKIEZ Q9Ar2G+QaeBCzloMUA4WbcEuoy9opYoJI3tgGSYY60QwkHj4BfyXX81ms50dOzw+EdLLAC3P K9VOuV1rdZttEhPXNWjLsuFiC64+G28BNarbocliTPMsmQwDmZIogNSb9Ml4wtZZNqjINZPC coOfos2e2YHNUzMo+TlfZhQvzoD7Tu7ODYoc3Kwco7Ark499pjBD+K/B13eR9RYdnryL/zPH jqYCBWmDc4anH1Jsp/oTbAZ492/HQ3GaCTJoEjFx0AE2u3GUVx2ZKWzHsLkxzqnlzAtyFcBw IbvNE3nne7hltgEFKkGIiQmYz/6hv8ozXcVeoYJxD5n0z3cu+zPJZ3MGZhgnq5TetNcrx/yM bmCAz+b1Zv9MsebleTCMoEhmMoyXAf9VcOmcv29vH21Imwv0HtaNG9qKX2hr9Cdyh8n5iJvj Pm8hoGHx5xahWEoj+mCU7/iQeGdg5ZlB6wCI1Ayb/r2YEVjCVHWQYGnfMYD52IODEulIbI7L mwWEn7q0oSOnGduCoX8f+KgC+4XiH9xiBxPKQNM3pV/khI7POu/8XIabMXXvhpEH6wwgWQoc Hxeo1KbBc1iJTWO8y8XcHEHXVWKlWQOmbJngMSR5geBK5n7XewlQwHspnc5Hkgj1y9oYO22g J3byh2Lw7ZbqoSCYnxCgJhdbYgwFHyfzDBeDVKKAhWfciKxA4rgvTQkxUc8Fnb98p1DnKhnH cAACdVYas8/Zz0vRYNxBILCytTBaI8PM7iW7LCCrLhiKV1nO+0JRmVlKlKaexvihUaWjCI5L YalcZhvSUtj+Z9d/yLfL3Xp4XOrUygBvBuY6HyYyYsEsHk2+xCG8bLi2YEpZvmEEaOTOpUKM nkQ6cCDtXn1zZcpwoCSDZZ3FyVRI+yiroNqMjkQ+/+RQNCL14OwpHHc7lv1qp1sNzwdz5QJn MHvRpRCEII0HkYQQGC1yUPZS3IY+4X30YexfCf8tBWx/4836Z9QMvpVkhfC1xhvJawdqtCEW Ic27aLdNp4yYb54lFmRwf0ssGvt7if+8JTYWg+3PAeftUKCKcL7C2uA6kIrBWA0dK5Y8mSx9 jrjObBr3mR3DH21NvY7Fj+5Pt5One8jS7uR7DWepeP4Mv9AV1EpQNkumOFj+M4nFxqPRKyPl FQ0Z/WZQpCDK8VOFrFXSvRZ+lwOSabjpqx6X/s5WXG7gNliZxFkZmePk/4ZG6ffVEK2nsFr/ rf6PUHFposoY0N5uQakYJcXhYAyQQ/U81jMChUJqNo4z0O608IqConCadL39ss/yxpKmO9VG p2rcf1J70xr4o/TOeRwcHslxpTaPd2S8noa1jNmf6b5rxKXSMDqYrmrAWgWwrZCjpFFgk3nb 39QBOmSWUgYu8enA0xXA8soNv4wMnwxO48OOFjh3OqRQ4cIXlHSpvq8o5645ZiZFn+EOQApW FA/7hvvVqpSBLwC0U7P7Nwww0vTwPVbk+yI3lQaznuR9CJC5jWyyIKwYr/KOS0vWNE9LnR+x Uq5biynlrOrKgk/YWbJU2rZnXf23N82SJK9UpqW/wiNX9omZkoL8iPOHSvNJA/LFi8pW3dq2 rK4v9ewkOSCl/mJ+jOoSLK9iuSU4PthKdYSdYEij41q3YF54HqoUUJ5ntw05AQx2J8+9RrNr jVpFJl1P1vcrGx3tayK1r67u8e4a2LWyaQrEbuVm1KSDyhhVSj8plZHpfrgL5rmpBaEkaZym Tes+lBO3hbAMbRpcN/00XdjM1fzeq+L3D1D7+lW++Yrev4jS1qtofs6SdgGfvPSfHuuv5TrV ZVSwIWNwd+Jo1rukPK/zJCD+fOluSTh4+mKZZxPBoeYPUjFJ3H0KaWULEMF5WfbZrdN3Yav0 qioTGrOON9XeS+kWqnCQZg25fZkPcgaPE6i+Mp7fLO5n3hLsyVmPvkYoUa5ptwlYbkUzcfYN OKqLWB96dzTDRKzHpG7Ppmyf1xxWxeCr8SpfvJH74VeZT5ym++y9E2AeCVpzvQ0ZplVafExz ZC7BP+bR+VB7gUhPWdLUKFEQ3vg53CuE9JhZ6RVL56ItMMgEiQFeBigT6mJKzwiCdbD4Zer/ 7a6XviJmpcq0m3HyZub5yC0JGvc72abl9/p/20bNsM6gHGuUSgxCV59LAw2xS6WJBoJL+uMn KfL3wABNWjz9068AKyzqTU66hXv01ERzBcPlwuuBEevniF1SS69syIbBenDr5eksL5IQ1QO9 ST/254b422vyjl6TaztI/hF6w/V8odZ0gvr9vJ+yfY82tOvRcZ2D+a5p/6di5UA9O1iO89pm hMwp4Z28hmHq5pNZUTPLAFMqWfxSSmn8Ik9nrCnuGS9Y0M+qj4mb2R5bG15JyQmvimirSrTZ nGmJudeGwWdQM9cPKSKbIEPyHtEDYfQ67ZvLkA5RlIrYk7CAzm4W16ZMLR9AZ/FccTQHrdie g9eKjdfdlfFKUqbsDZTVgI1w8glnnuVqU6AYI2rMMgBaGPV6KghaqVxe1rmMRcMJsimui92z BpYxcSwhGRFGB4M6BVBPxRMybjMmLIR9GkvgNLJxPkk4+2WuCKCYOnhUf0WjufRwb/KiOQkc vdChflZ4t8/ApKYObjWTPpxHewjeZVBJbL3Ya4JX3zXe/fS93pICnqezoRE4r12vybEgcwhP am1xcepUfzqrNspVo6oVSy8jINiaozE25BKma54BZl0nDJcdTszooN+PosDiAIYEoOEhoBlG LOTEtGZAMwWkWW9mIMJKrV0td5vtdwKR7TfVtkxjl4PHRmphPfHEnOmtu/RGW+Es/oygJ+VO 2D4ph4c2aNIzIz1x4j+IX9mPvwzAGASNoiPx5zC6FifWxYQVrvK0knle4QxDHrkSPhfY3tYT UFcFqwz9VUsQ7eFyMgVC16gdRbNP9AQhTh+X85YqFZSC3i1vtVSpdcq6WVKlKxUEnnPOeuhQ cJJ4JgbLW2cL5vK5ljkwm1lhURa72rROX98Ql8sLGehxWOY6oyAH3H6s5QTY8V9c1BrRQTH+ 8honoxn37W5zNgnNQbwoWWfGW5acBI8oFcgQ/epVVVTjTIo+kFa7Wa52OgaocYq4B8AKQsOa m+Xm90BpMxOlzftCafOsm41TeMBqQU6zRteis9VmZaACbalz15VeVlYVisqnjQqOrnPWahVB /Vr9uVVvrNN1ml5+P3KpVOvVbjWDYryLL/7X/mf3dxDaqOFV5bY8mY2UYXyFA2+oy08UDxru cVGCQcj7bCxpHnck6wW5wp5zwmTIG4kt5dvnBAeTzMJv81Xz98CuaPY+cGuOI0fOKaq5mEeX vB3lEixsi9gwk1VYLyyJNp0sZVztTrnhZ1xQssYZvNJE1kIVDCB/8CelditsV396YVF5f4Lv L8liiuGJAUgRdiAkRLBpGQpRfHittMODuU9ZYXaxKib8QsZx9+cMGUOU/EkH7u/Ewu94kFp3 NWcp8pQcPmRxENf5lPOC2gFmZc4PkNo4BQNeGDAEPqTxRR1YI2wJIpJVxKUBI/7VJ5PpAyAl yu7L2RyAo3KtOsaF1dXU9QEcNNVj2eTiYjgYx9YtRowKk4FDkHXI8iEugdWwEnabb8CldMIs my4uidEwZxAXcOGbUv2s2iHnwzknEr8YiWvYF50+3KhSbzbFDaVRE6vbPOkKxlIRUkS6em8y vhh8tFswTNOtxSnKkHop5NQRnzs7Ozr3uR4JDKJWqtf+VfX1buc/d8Q4vay/0za5l31ibZTV d0q+vqjyJvMC86b8N3MxUFUtv86Q0qHkb1SZqOp0M6gKSv5GlY2qTiaqOn+jypQ2yxmYEgV/ I8pEVDULUdW/EWUhqp6FqPrfiLIQ1f4pA1Htn/5GlHUjzqKozt8UZSGq+yYDUd03fyPKoqha FkXV/kaUgaiuEJgMXU5jAikYh9eQt3URj3txlpIG6t1JQdNuZAi7ouDvFTIR9SZTgnvztwhn E3MrSzSBkr9RZaDqValW8aMKSv5GlaXyLncz1KOi5G9UWahqGIfJ69FoBCmG300WQX8CNt/6 gaAR/OMf/8h+AVjnGeTO8/dPpZK97JW/191GViMTV42/UeWgKpuuGn/TlYOsnyadth9XUPI3 qix+lWlVdbKuVdX/VWQ5KTgtLLHbQiq4k4ko19Xm/xXEZdv6Q8bYavtNrSyVp6YfEMRfygol Y7nagGOGSutOps5mO7YxP9h33r/BNrd6H8YprumIYZCqjFfthMcZ1rme/Lygjf5n1XeA6LL7 mMNKi2+l5pE5P4x8H1sc1/xhITdZiNG2tUHZz9dIA5LanFkph+6YDOR+g4WsnGDj5HRlv8CL ETvD6oSNbOCgPqec8MzmyRBAtYKbJ+pTyGDDBIBjnEgLALsPbyV0VnaqKac1MQIrulHXbY8C HI1UfCO7w4IKLzXSEXDqtcaPYaX5VtonSqoZCKoKymLq43gY1AfjTwEAsQHEuhPfIOIccrLj bwFabmH8VDjyQIwxUXF2+XBJuSfPshmRGTLRo5mNkaE50wbHiHI6pgTKcye5s10tXZCdFjoj h3uqhXh2MZmNyArbKGcP9Lo4lRZzGeN9iEZCiRneKRUFXZ4L3sDpGDEBoLIDqHPEhi0Fqi2V 1CexSuj68TIAa5tGWOp2q6etbrVy5EJyYkOupYKiWwmxx4tRSPOSQT44jjAKD+nlkZnijUzy 4iINybQHcyOPPEeXyLVzupWR07oWTjoJtt8RRxqE6ekMJxOLTuUSEFODZN9+Dx25gDTALQKk GOfBb4G2rzopHbfB2ZIsrKyiVrv6ptY866xufmVEh3Dys7nTuOdZ3H2od7U8c6ZpJoXXMkht HNQrbxvrWKLdwgztRp7tgfhxj4NGsxG2Su1urVxrlbq1xiuZUVAeDJVBH21Vo97nxQBjz8CO aJV2gloQjbBoCpkfe4NpNJfhw6EnJwRw+hA6axFhZx1P6Kwph5N9TJ21NjlLWqobz+QeWATn HgzKMQxjyNin7bdBs3ManrSb/9Lhh2CfziUPIcvmdrvZFoKlkGk6VRUG3YWCiNzgB9E1wgnB 4i85L12Q1IHpAgyXAWQemSlcNuuVsNVsd3ldGAEumWvPuszj0fFX9IoTxnYCX9j9Q3fnnF4T FSoZyHBKtvp3T2F3gDmnsBXkCfFhIUTwo11EhsZMipp3r3ZPEAbKMfBgVdyaurU3mnHnMAob UaItI7B0EFEo+u35ZBt/CQhni5nYhZMxusOLucXinMcANBxjGqDG4qO4EIjPYi+fEIsJuhCo vj8bgE9hfxJTcpnrWKmgZf3I7if4SlEmMUae0zbdFwzrZFG9L1hIbz68tmNeZyxFipiyRSrj aPHKAyqdS65pszrz22EXT/qVDJuZJbe6rXB102audHwcltvVSq0rjq8GEMkKNs0eqdRwaLVP l7NW5uHS8Jg538bIOR0Cytn6xuBcH5AT8gE5of3Dvqo3OjeO43gst0CG1zKRQ8DyMaUcwlcU KAZZGdIkmc6z7fhzYiWasN2EXYE8Gk4jFFfh9hpfKZmUU0hkRGnUs6BsQRjV66RdOq3qhKwy CuBoOhQHKbh9oOcPevyCbE8em9tCrkZpeMeN+JYp699a1M+S9FcW9JfK+TdqZ6el/IwbkKak x4/z70gr8YxVqNHInxIo7ntBkkdvMoK9JIhcZvIIMfhSGMBBihHAJrRgkv19BWZJiwnaJXL4 lsHnbG6oQru6SNEpOa52c7FlnWRMYSiKyKRlEBKMO+VQfNCQ1gTaNETfQfM1iqZEREw/uoYe jv6WAjKJ4BOEnUMyMyShVH0ZM1kIlQGkAoC4uxcg7qHkSXInTYRm6gq51XqpI4RAcQA329UQ RTSeGzjYTCbBaNG7DH5ZiDWdUBAtXF9jkwHc7Br9ESdBD0O3iTNPrPz5ddC9gu8U30SUYkaz C2dzGkKmqWDI8ImzpJkgc1p4NwEp+tc/R2S9wQTvG+krRSdsoh1wuSoknUrhVxsThtQassrQ OqWV+ks09Fg0JNg06TDlMZWhHzNVYYYQaHS3c7EY91BsgTTFSTgBNS4U+KFlToTFOBl8HIst O5yMPxYuBn5oIb4I4QaG0j4Ddri1dfDw9b8Kj/cwCoMgoIPdYJTEPbnNlwrzFJgiDyADn5pP 3li0s5r8ulSArZ/s0cvMCpD7BSnoarkE99ZJNBhu14AJiu63oc4OL2+ujJamS7iWvy2Jba2J M2e30LhAnwOO6r96bzoKMaX2ca3b5oujcwGpklgIWE+EaLEjhC0DPMDnKsHYNzNuU2Yf4dsm RfhfsXkhy4kaq3fRbFVXaR/A1mu0Wlmx2Wpl9Ya7P4flemeFhn8+rQmRoxKU681OdfX226u2 L9nXuh0o4RnIZnk3JrjbiSnLG8I7uHZqoPVldoNvW1M4LlXCUr1VWq5v5Ieq86gfglAMTNJ7 j59dhaijo5u8DDiGd/rnf5aeRXDik8EVimzHB4cyr+RqB7Ec8gOvcCmw9sAjipl5RhXGMKj0 CYsB+kSDDK2WYkNWKHiz+RmqY0f6MzXHeplIaNSRTIzwbFQdyAvd9jV9LblucXBvs3d9o75Z IirUa60TR05QqBBlWyfPC87pn8HbQWt4UqrVz9pVQxyy2X+nA8+SndqrRqnubsxKPCfNRX2S QBbboCNO/Gho7nZLGXbWxbbeNcrLW7oe9y5nk/Hg36gx2cmbh+Dvjc4pKLBL7Vr3nSuqCup4 EHQ4yOEEsgpPp/F4J+hMhgtoe/uH4DXECmjDRjADCbP2tBUJXnEdVGezyWwn4CU3qjxIjc17 7/2BsgWCJUbHFe7c+5at319+JwOZx6OUVCR1k3cdV6PyzSJrZNAg5GQehjYEd5l6n04/C6s0 l6mHam+7WS/VS59H6OpJKSVJQQfKt2KQQDiACeWHVgwkCSDF8miQJBx1WtICBwfbl7HBDB6S wihqevVhkH6esh/U1rtPy9wyywJZ2lqg3wI1yvfeUcvkeDK4f97USIr1Anxv0DgJxvdmq4Sg y2aBlhTpF7BCQQU/89bjtK85u9ecmF8rx4ffcjwH+TuSx7IOI1mZk6zASpbyEkMFtZSbyFMs tcWte6R9VQzgAmnl5zP2vJFsj78+LFiJ9UyTlbUNMAw7J3VHhoCMMEjvXTnrKqnwucRWw5RE nGgmQO0ZwiRd6WSS4Hu8o/Ijy2rX1ObJiRAgqp6rak1fT4PoAvL+8nvASpfV2zwn3OIx4dZP CXkPCRYOcJmLa7wk3O5OYr0WE8Fkqoo8T21MKnjPB1nQo3kQ9IeaB/9iOi+mprYIKVerilzI XE2RC5xWFD03FEUrPeM6mqFUeQb29PLei5LFWrC/nG7p91MuecQ8SR33cwBkrl8WNx7ePzdO TTLrNM0UZzPsC8xt5Sk+yqmZt82y6qR2m/3i9DAQWw933aqmEc7eywBLoc+HuvshlhWtIK3v kuazl9veDP4EfCCmfImGi9g0tbXVOUVuCPIqQnpCqZDhLIzirKIMye1q9V9V/sipNsQFR1bb KwYqzxefLdivfaygLa17sMBWQFhkR0ofFOh0OZPeZ3GlmfRlNord25vukv10Z3Ix/wq3L5w6 XcQGo1HcH4h7AYT0E5MqkuVEJHN8CZjxf813gtocRhadw3P1wW7QEzfIT5hDqC/lBeAEyuqa ZvbgpcupiC/SI67Eo6mHGjx6FPwQ7Nmx/1lLgKqA4KsYmqDPRa8XJ8nFYvhAmYN3rCcXj8mx zx7+lqbQfD1NqQg1UbE9EnVrkMzukTerE5EPxPuWbSoJTO4JH4f3nhsrmpyvJrIT6XRVAp/5 1wkY1PQHwCoTMvNViS1Ex/EOAp9G40UE1vl9ygkENBLPZsAok+iasl0Ex4KYoKC3mM3g4j6A JFUj8RvZ8AwSqtuPexRzMsGnYc6nvgEE+fhxtsJbC1zBrymdVrpctBV8ncw+RTPMnhXhxaS1 Ezz/LjBEx9fNTjcsNxvddrO+3AglW3NiGk3ae2QF3mGqWrkNviusYBfDFao/17rherO5scUr D+7Vy69Er3wF9iNfvRHfFhFmFtz1EIE7yT1Zor44fb/MolHmFoINJLaZ3Md4ZnMfVDO8/Gp2 xUYGA4YZ9C4HUwcED3l/Q3onZrWjIUhWmF4+ebL/NBzPBLtB63LJPCQlCsY9jjn9YKtcC99U G5VmG+LS18DJpPUani0AnTTLA0yJqSS/0TXZ66A90uXg42XAyiAYO5z770W1D2D5DHn1fgvc okd7H478jQ0nX31tPdrPa+3Abg2FzdyhPTrMa+5JVnNZg3ua19qzD5bPjJoqHlCOdaiNVG+B GIOTOUoOz9egjQpvATeYIWAhhWXL0OJI2BoUAMY8+eX1uvy61gpfl9vmPs7bAgVKOvc1Gszx /QvbFbLFx3huNj8iDfHeLsP34+0oSeLZPHcMleo6o+BUWGO0QRKIDuBETaT5jZyzv6dqA3Jb w0YqBStPWvZ1fj2Pg+Rr5G28dNoOj9+J22XnbamFxv5ht53RBbjnhaMo+WSxOktoYL1qtvAM xfL3vspejXmdx3PI0AEm92DrtWekkpOGhr40F0p7OAspBxcm0AKl7pn4RTu/gXcg6AM4/xSI 4dxCSEobUJ+JrxmtK2NG07bRSGPHM98sGFkOMaDF14jmRs8n4JYoyHCyEP//dYzYoASZD0EO Tnqz+GsiU2RiHAyt6RUCOwimO3YG7j5zXPPdlp8ZTGzymTIcUnIR8oTECz/8XTjSjNhNyHZS BnRBdc5Tz6bLw4Sz1LOuXLD+D8XgWymTiE4oTf3kYgvNJSmJl0BTfNW7jMYfqXeZ4D6v1ULR aqdIK01enUUkoiIvT9EiomLAzs80RTVD0Sbp6bUMJT4BEkH/3RLHVq3xiuxV6b3AgCFE8vOY tebZ90oz59bqGyM/3btnw+xm74TOkp1Q/bn8utR4hdJRq9kQfA18i0p32AcwWfYg/X+N6FzX +9+Z+jSmcykQs3FkU1+P85NSmrQ7UOHeX4cfw5Q3lYhqzlCma4DMOgaOocKOGZsAsqQnW1sq Cc9vAWZqxmzsmLAOW9dXpuXNQAABfytejr1x2826sZHFBPBmYwxUetsP4/HH+aUaLcwXh3hk g+NOteZ1Um6FOLxys1J1wWN4XRxFH+NwGg1mqk7tFDDQKtXabgUKPwDZqtHIatcpnswGYpND +kt/OXgyDHrQm+AkCfcnn2W64jpyctaAFWhXS5Xw55OqECQr78JKrQPyVcUYzL1wJBiSYkhI bHfgR1Y7d+BH5kb4nfiS3nnLTsVJDk/6o/mPd2MppmR+tHkSVG1UzD89nIw1vJyMV58tmHcG 1x8w0H+PF891jtrJprGI8Df+g6FRFPlbOW4MSLjczL5odiNJu4eY/9Y0xhAUd+BW53fUQT/c hVHi+Hc/ZALtKaC9bKB9BbTvAukLJjpZ0dQa+NgWNsC56HXt1etCZiW6aqdr1Ztv73vfQ89F a5HvKIfcYbt71v6eRZDJZtZdkGwjc6SO0X2IHPct+K6/5b2bm3JBLd/NbIwDqNoZ2rGRiFh1 lCMXXJBPX6ZsUuC7KbCU9ipr62xkVszdPG61lCKP62FCvOzeXJWdW8vfl+QcqoLrGI3C38iR /GhxlEWee4J4xCc+Pbwi2YqSqyF63QubQQwQn/nz+IuPOu/MYLzSAsU4u528YH6HzHqK67hp pv+067VHOsBEg4W15AHEkSUR4JedNFfRqQzT0AaOFPyW+VHpps2E2sE9H6I4lj+bvL1outcD VC+Z9wg9nycr0/ytROPjUgfC3xx3O34aPl6HxRlUvLsO4cI0N/PFsGOiIJcKwFOWiGR9xaAz /4K9MmpM5rrQjKaoeZl8ylmZh0ZEO4kVvTQq773EEy0goSk3IiIaMFBGc1kLg04eZGVCf1Jg NUOqBrwZ9MIk/pxV9Zmn6mQaj/PqPDfqGGZqNLNvrvRg4Xfdv/jLaBmfnHDdCLzojriooEkk QJrbfikNNsPX4n4vLvf1akNu0wdb3DMg8fmu9gnSY5R+N+zZjLEIjOHK8J4H0nZOLSEqCcul OnivaN4og2weaSszte5SGoCRAWq+F+v0dKUBnXbPMCKhDM8oaq84nna1/CY8qVXrFR2GIWdY iNIHL6lv0lb9upE7vskF7X0KG6miNy4dWK3xJmyV3tWbpYpcsbyBpYiXovNsrLCYZpXNFUdX bjYghOlPy4alyXfl8VhVNu+PrOgJqoxeU9PJPB6D8fLwOuhdxr1P+AA1mszA7CYe9hOIKyo4 j5DUhRw07geLKcYdQG+beTT8xCEARpNkLl1u+jEo2ZKd4Gi7QE9RaMgjIBNRHs05cyc8smKX YtbRLH5B7YL+ScgRF3Ekhk4RMK6eiw1JpfOJ6BPXlix3mCGINodC/pgHewIMe0zP3Ht85r65 /CXfWTw3yXJ5LSnQeHvBa0KvlyH/ccP3eifp9f4KIps9s/uU1yRyPWY+otQIpwMjzKE9UZot qYkpFm05ao2HcIvwjPDL6z6xSPI+KR+GlSo0EVZK3ZKocNboNOu1cq1brUgbr3z6pAUUHys1 cQp1m+13OKpqW1Qrd8PXlXbQm4eX/ZlNyA421eP6CZgGLqYBVI2jfjwjJkRNiNvLFzESUyUg kCBA29U32ACDXaio0O6gwlKrZQMmi3OGRU0EY9SAmUzJaJHJRY0k+bLnfMOdCK8c9iuKmJ7x GMSwo+gKQEODEsym91PfzGubWaKvaU7BF8HxJ7NwMR58XqiyFTgCx+AGIiahRUefFkCHFJ6Z 2YbUI8/ELjjcoY4LgmHQb0pPSnRQsAJ9UJUkT70jQMV5tkU7NRgISepgX/z30SPLZ5AaOh/M IZTP+8EHHWKIbDVk2pFaS8iHYJ9thyayq+9/oFhEe0eZIAcEss+d2PwcUcSDX4O1Yg+mYPXH sFfmqrDUR75A3zp4uXfVP05F9TWXneuQiwftO1p8VDwiX2v8jFrITsGHYI6lvjaGqd+/Eopv fpczzMdXfdJT0pvl2qumjy17HTrlduFOp9ctDAPyn/3yTycOBcxHWh2PJ+M4Eugw5SrxZ4Zc xfM24Gbxx9DwAuJj6axeF6fSq1qHo9zctzAmev6jhTFDBrOxcJ/0KxciRbN2UI480hU3FAzp sSvt9UCkOI/l1Ros6cFfhT1BA+lTNYAwpK16pSSuSl8Gs8kYfAoMk7wlPtrG9O81eGFG7EK4 lV1RdBMMUIox08fbHG70XHDvPg4d/g/MReeD+UBc69Snx4Y/ig5o2Ne++eRMQ5Fd6A/lXy/j ohT1e0sxcFopelmB5LzLwikaYR3wb1xS9sCXDgUCAzLoB3jsBhW1KOQPa60uuX+AOAD+Sx8H X/DqC4ENZbRDnEbc58jz8wlny2BPlGRCt9+v0vbzMvqCeTSmcggyYt78ciJOzq/wL1WlyJLQ bZjMwWIOvMwG/R2LsKz4yKZToU1vtlehXWmZP6ENnfbbRRw/PLC9d5fHcXY8CFMAqY3sZD9Z Rc1qeiI9RG3ky8DSoO5jTDqKdYDe6Gz6hAjm+E7SippVClpNcORhG3wy2GPddKIRxGD6C4Tk AUMCzQ/8uSRQcDoKEVILOD9OiAnw0ca6WkQU65FP8Ed5EyHgA9uS2PCfS0cpQfNtFfQDgsC2 wB6+0c0PstFXMR6NtEOr9MDhRCCMXT6XyWMtgZdVbJjrbiQl0ugi9saRvDg6N5RyI3q9ez1O XcKIJ72x0bzEAHCogEO2WN0jO32+WzCuYpk7n+PTWOXr73y6AwmGF6uQjcDx4qh3ybo+g9eB 5x0wwzFEGe5DlGFiYWDTjjeneAzCwCBOnHPxT+It1m4cxtGXjM0o5QtPUYo9+dD++/g2+6Zj hotwwybp0EXaDZ5DFumQShjNYh4HdQjW5B6MMh4slmHgPSOU0rIY81mRZeiqnBN0yrzpZAao z7Ym9J2Af9CCbKy8Is7EHtgJTf4I1GYGTM4PgjCfmNnSsg/j+SwaJxHyJtasW1ZeFvad4MrT YvDwcypwsvg409GQ05pxX1s4ZearnwHJUJtxDI19RnxBX5+1NAkomhpU4Iyu8GkkhOdJb4tu Q69OWoJjNU9rZWVhhAtu9MSe5VxPMAwxHoyAncZnQb/8cFggHA3jAaRfC61HVCjGJooUbvkr zMcIHy0vG2ZsaR6mN+z09Mhwe52p5qaZJCJ12d60en5CyX5syaAMH1V89gXipsHITHU5ZABo +azw+9IdDAApqeSz9K4yo4Rr1eKKUb91fkXumzArR8WZotILaCXoMco16UogqSj7jKRhxhr/ rIKF4ouZiR8SfqZ5u0LhQFENn6b7W5tlFZfxYgCiAOKT0ghai7jpTa/I4/Hae50vBsO+Cj9w iUr+HMaD0qp6WSFdhf3EJ1VL8DtK+hRUXv3Zv5C1DF2VQa5s7IYaE32ScGWOCKsuxmSioe8P 4AXBCR0IRia2tJLw+ea8aXvmKpkS1S/cJEqYNE8rcKB8LalAcpOBvo1+FPfPyeP55WwRRMEJ nkX/0A6FW3q0D1QwROVmyJENjZg6ToREgLZasIfEofwYYTKeP6u8wA+fpo3PGwxAP36wZCKu d4IDirMgwIggtQN4Zm2eNPzwODLuHP7DGOrE86BenoGLpTghh9eAJcRWPBYXyKA3i/sDIwSJ jCzbrrbqtXKpWzX0VWZvw94MRweiAvjTj6bquWf3qgwSLiS1K89eHlDbkkms2FIW6oCQEbpv vpuQXvQ3fflI1/wCdvdY03px0W8t6SqopoQaYvuMUe9KdVSqUM+ayWwO9EvGQqn2aGNmN9XT 9/E0gDxBCema9XiwZkHO8iAnsj+8NQMvUJK1uEUtIHXqJSRc+RyWUVsgiOlTHE/hGO99AhOK WitAtS4FKLyMSb4OmuWajrPKGT9nOyytD40G7SaSYG/HkxwlpUImI7p2s1QplzpdM92jH6WS UPd0YJCV6+ybQdlM0PFXtcLhGLmX6gYu10trJZm1nGenjE5h/4NReqGI94FisL9ubQhuQJXB 2q0YHK7RQCLuyL3YHIBo4+l6g+A2rGE8l8O40dfYzNMk46ytVo69B6w+8vRpeDGMPib6z2E8 NgKgiXtO/3znfMGKN6l62sKzsPBlAG96k/B8kdDeMZ8IRL348oKrJFvYjZKwRS/BN2KeeNsR vz8S0vphsK0LnJZgBFAkW4NRZk+/mTH9lLTgChWiWXXRGZsSBD6O5IsTUKnxlheH/rRfUziu EmzgEM3eLDxPxCxhYBafZ/aKKSLT7B6qzCdzRoz4V2JXDcM4y0xggW0BkjarTEPKNfK2QSvm r5Q5TPPh3ygpGIYIJtpMi4RGMyw3T8VtrYFhaF4YHAxaMs6sZEuQQFiulzqdEIQI+Kta1QFG 4W/RGgTuUH9A0+IvaMX/Ni6gsWscQ7v60x36z+6ERnUffVhz9HV4Y61Q/pmJfSchByGxjmgu SuJYV99j5ZaGuOzPJAshCjB5BwWyk+GbNIt7TwX2R4xz98ElMNpWmsSSLbalTW0JnTkJw3Lg IR1wONvkE76awjksTnOIcLcTnMxgZospvyBmnPCihrwVpVVsSOdw77dsXwxGcGTDArJoKmkT aHFCpPauHSJOTO0yHk5JIAExBV++oPvRYA5BS1CZniwfoTlE1pvLV8LfAi1/rTjwNMlpaFqx VIlKxq1LxGGwCh0JMCYeqEAv4QbhpHXAbmCL/NgehtWE5aI6GFtef3KMTtQIAhRNTy/DL/Es 0WYEyVbrdfim2u5I+4FUZDiDG1Mz+CqG8xf/5cuNbAyjp6nAyoUjO+atqVleq9lWd7/VddrF 2yZUhWuiip6vw8orX71yuZDqLG1FzB2htXo5PHGHbrZIHa3a5InVpFlDbN8vIUgxIZpSSzs9 quZkPUxVllGolcEzmzpTbbA6P2u3qw39eNXx9D+E0Izh+TXZA/QijfE28PETcUaJ++mrZvtd qjJn5lF2KxQZOmuYq7iP5tRczfma663mPppZK8d7VIXhQgvSMnKpvQCDRcQ6JLlFFHCDSt7v flChJbSpJ19CUkPRdShuOESr6BmHcF4NQVKD6QAM39eokU2EeRVtI/tFPO7Fq82KFzYeoyYb /uPs9rzK0uchnAr2Ku2RVpwo6oQMwNRa7q+ylnu3WMu9tddyb+213LvtWu7ddi337rKWe7de y72V1vIgtZYrsnHqZD+9yqpDtt+GXAO1imlgWKnWa+IsfWceHndqPAsF+2vT0/7a9LT/4W4H lG4ml7rwOnEQeg6snBZvT3b7y8iOxwNZ+FYZSZoSUXqczEyT8kOyKDcfauUJnHwxzcnNMrat Z3FNCKdf4qEBe6N8SATdU4JVuE/U1P2gHombrRMfsqiMzK4ni6AXjeUVIviPbYghKCsnATzG qQDWQqy/WIBUg2CPfWE5h9BbdlhOjhqpwzrnBIxFnz4KL9lp4920XuqWXxeXBZr1itmLqaDf OIQ45iCM5wffd0Kb2wanqbjnFB1d3DNedV8XlkRH5/l7IOx4wFbRsknVTjMnRdogNImx5jcY fQZhMaHBPXpJIPY0bZgfXgbQT2qaNtS2CZWasAVrT9gqWjbhzknneLV1TC6S85yVdIphLant 1DRTkJ71dGDsCRqFS2Z3mje7rAUdOePzL6kLBXmk/PN1IbdtyNTcR3lzH/nn7p29R+WybJE9 VdyF9oCQQSBkI8QTjNQFHQMF3jr+d2Yee7VyvNKAHc2AO1inGOUU0XKds9FmAKVGhkoCjrcN Z50c1RgSAJA53kPxXx6Z+Dq4AC4qzlNxNi/iLSjLeWA3m+8NJ0m8WvuT6WrNI15l+/BgOVnM 83vw2mOJ4u0fprPBF7RsmYlBf9r6sdpuhG9L7QZkjt38JnmB1tlogwjnJNgjQkamIlWGy6A6 +EXjML5kZ34V9meT6TTu0+ohKOmxEIei618GF0JcQhsKmvxXyIVgTT4LnzCEcBr1PsVqzlJB +DD5dC6O77shAk2gZI4FZGT0oMDGH/hlEaK9G76eHJmtDoc90Sb8h6UcNjzwDH5TCkKZqw/P 5vPZYIpB6zFccRIv+pOAn6mU5aeY9fYPbHyqf38U7D88KYclUPIFEooUe+rXbQMGVhHHbxrq 4XwKqlH0cSE88PsRQGz/EEO6EfkgDX1NB0Iam/Q+hYPZ5yT6EpNhn8A6fCwG+tmJHxewrvGo UO2+DlthrUWadrUcgrKERCMXHxebpwJM1a+7p6ZKbU9b0cxsjKa4pMl+fBEthnNqiy3QeLs8 ePBA5ZUNzsafxhB+uoXNB10xv52dHbQBjWb9wfijkQvX2jwzZ/M4TwOI2cVY4lYIluJ6k4le GWeC0qho2drcqhC7PIEzUc77yAdFaEpoTDfO1e2WO59e88GASsbjrrUC4tvy3T7jxZ6dQVRC il3MPjKIOTYCVKQneUg4g1EWtKIdMtvygwG08ekcXgku8DkBnxas2N9bRO0vNRWR8tTomhSn YqYh2oKFokWgpkIeb5MvyJlsYZVzBe9k4CCWwfpJHIIHF2J9OW3a+8rHVG1DX9wd+ZlqDI+O pUGS8t3f4ZPtu8iui/V6Oew0Sq11/R8pmoPXEeyzZS5mooXW5TOl7fsULqYq51XRYLoGQ1UK eNc0kt+SP5OD1pGdn1q0vX02DcrQdtCBRElxnyPam94O6s15g3wtRWMco0JaP5K7EyZreVVr 4NNlvdqVCbGzXSBrLcuU0fVoNPgkEoHPazHTZdF8FYItYmRfNkYuDeG0IU2O594022OPg0CJ WYScq8tM5JodBEt2q5zXKxNB/oMexEaZTyj9Mrmn4ZuiduLzRZdmv8GpQwOKCqYGFbAfoOH8 R4ntX7omfmyrak3ut5e3WSvbR9e7aNZWk6m4pjR0bX17k20Naw7Tu+BEqg/SpMoRfgznkgZ4 7wBDJy8mMWI4VbtX8JiqXP+cHYJKz9rPp9UX4DYIDoD9xWiKz6/qnADOL9dxuVOVdH3UZrr2 vj1BU/RNJ9iZw0ry2bEhmljmQeuy4cmU/a0wtY04v8JmC6KIh7sfYC7LePVuMWsL/bkcfIUI PTML3aJMoYJ/+f774DmY7ziIMSMnZ/FHFY9KBjwV9ZtoGnJWlfzKf75ksytmCDb7WbbFl3Di Nfc1phkcqeBTKmTH67cYEQIDcvAusVzkAdckt7G9nHEM4ujMy4hpnaArvv/OhLGifyzDgeNk r9u0er0vLDGe8s8EmXcZeb97/q989HgEhVVPCHnK/LH0g2n4llIQQd6VgNYiob8aEakD0/EG oa8Z56aTHDnNfFr1d3ms5ygwxV9D6GRvfLiEwKkIqp5oDK2KIUyH13xN9Yu+XqnXK/Z6yfkO gm9a8l1R9N1YcxOsuQNW56F/0ib4q9C+kQfzrhLeEpltTQHwRu3EVQQ828xPqoSi2Vh0ACqh 2hjjTARN2q8D2lmkF3qw6dqUpyWXlKDoPC1ehXDvt+/uPvtqN1quzEqjo+b61QgssYjf9KXZ 1A0ooUz8boZRU0O5hGBU8F9DQLNGTdM0qptDE7vAb7WoWIdR8Zv+ZlGNI62YntnaLtn+PndP muAQ3UmlGke3hIo0ALK4mqk2bzS7QgAmrXlt7KxMITiNR5PZdZB8XsQxuLiipgyokCB8avUl qkHbnRU4zyfQFkM+X6Bs+TR9ghT+2tEaG4E7vIahAco6Kl/J5U6faMcKRVwMTH5kACdp4L1d G9oawL5R3yBUo19PR2brTwk4SQPDKnIaFtIZ75ttQOl0obXJiigKxuidkiOldMftQVuDvkxn k/mkNxlSjhWU8VD3SO1L9Z/OA6rBKaSv2YZhTPd6NBoBH4QQQ+JonMJ5gkplOk+iRHC24RAg LPWlMySptdfKTFQlKD3B+z0+MJ5q5eXsSmkzkTaHQuQVH21NrkumlraYOVt6y2dzs9FFksfR PFxoXQ6Wy5Z09yoeZnky5prXEIXjdTTrB2ZgzPQ+sV5ilu0TE9jdJ0Shw6GfeKWGJ3+nmO3n 7pQ/hKbXoCybeJyF8ehNlGCz3NHKcS2yfJqlH7PriiTlnJQTEb8RXulcGF63IssVGlgs+yfB iw2pWy5DDgdnS/+WWxNEdMkN8Gdltje1JljXCD9k60wk8qTGxG7Hm3IePehs+yJNCfIA6sj6 31wF9AL5TR+jrPOJbffDgqaMug58zBnIt0GzcxqetJv/wpDpdBSChRXDkRjYbjchibGgoE5V hn9wgcA6CTMMF+wr0b2MXPr2S6pAcyhfyCTWb9NTqEc7IG9QHAw0hBhAIeTXe6GkX6k2k1EJ k4H4JL78Fijg8LjGigXjPdNu82271q0ubTTdiPUqmq6Jf6Vq3aSE59tjYHbv05+tOnfZwnG9 41TN2KO5uJutjjhJXfxCaV+0+KnpgvWzKk6u5jV7UuV3KnofsJDYYdvT4B9B7SK4jgVJQ7jG djM4l+75ylP0B35b3OCETb+Bu34dY4eGzZMTGaoMu/EGm4ANyGElmPkSqyXmy4hnr1AZPEJz WHbw9CogbLLSWPi/MWW8flh5CF7Fc3pHl3yLRJMEA4lVK8eGdfdHwQHxnVqNCF+01WdwUhbf CoYiateIiYXTtqO1ZdDepbyUreguZypD1nQ71IkUDYfugjxLbYr4fXpKT5GPUOf1BCKrMr25 qicVJdez4jZh8B52FS6u66K2rslmqH5+msUU2ZRPMcOtLJsbkx1m2M4YDE4auhjOzvK4JBW3 FWdcHi0QDREH+HOtkjaUsbzpZDwMCoQrWLHgy4ZTgwqXsZv2SaAy6yLjCkoZ+lqPcKqWfm3h lD3dM/JRpbzeHZd6Q8hcwwVee9wzatwHdSd0M09uky/3MuKBJnMw1Kw2KkjvBSfO8jIHUb3x RInO1CuaLBj9Nbk/xUIpPTjgkSIHIB4dbrrabkqNdaLGahmkGyOdmCNtypEazqODMWjTVZQ6 KzfR/tbmyUBQdFAWlDaOh0FdQKNidDHdCSpSd1RlSnxgRThLGzyknJG7E4jFzK4PSXQh/hlA 5MyIU9gIeoLIU+egsewNF/24zx7WaF81SMhJGxQSBC+mxcpV0D/NFmPQfwZch48l823MdTqQ rMSZgIzNB+N3LYm5So5xNEMYYa0tIl1t47onZvaDO18CIZKylNw4WK5xWgChYbgZaZucedpI 1YPEL6wUFbMr/CKJdUBlSgiEMZWiMTziiCnQgw6no9agvLYYUSwiwSEZCspCNRK6vKC1WhBR jVF0NRgtRhAU52CfApByk4kgoOG1oXQy5qlmttYBixamCoFGBjSz5UfBUzMFGtkR9oD2onN4 vcLgQDBMNMOXg+xiRGiAgvKvA0yaNBnHCc0SLQfHYAYYYQjBATidRUMUBsXM2S5R60+NgOA0 1u/5eOEzibfzcupcbopvEowReLxDyziOQeF7GU2n8di2SOLHiMbEFg4vpXD4JRoMIXTEpjLY ce/HneZJ922pXTUvyXLb7OkXy3tZ9rXX/SbfisYSaTM3rTSooWPRszGdk8i3KUUH6+1IJM63 QJx/5ObkUI00LcQMzA0MUDIOXYwaILjtSbtatcnZ5cH5Hho++nVoE1AoTX8jeDAjurwTWbr0 AUZnFoXgwxxMB1+Mc0OgC6k2FBTtRrddxbQHRTHDU/+94ZtfbXxQENK7/r3hUU/l/L5m6+vs wUtFNYWsFacyhhxuwAWXLan5UW0HaAzZHHx8HsCDmAFsKrONMRcDiQFWUFtzMAUkNQ27yn4x sKZF+mZ7qxvwB4V0CHXaeErasKUjCJ2CO43Eob7Jo01LBGV3CMMdTe05ft7+4fIrP/jYE5QZ B7UNTsKx3NmcgczCZaMaB5+ZIOgvGwUU/bGQfgN3pwabG9/FLwUT4AnKN3FIPK88CUxy1zYm yiLCNYgQUP8pJlOpHp+9CtGofJ9UUoNkOoyulZkHtP6fYB1ykcH/PUFN9Ww0cfUhTCaIsCPw hPXMgAU1D2kH9JPnEMVhfzlZOw9+5T2dGfnY3OWFLLtxM7ayzQDs+MrLeYF3r/um9ofu+APf jr/T9kW8RUN4UbgO4iuBqeT33rOpLfurZYXzLdgOqVgYBRsBz4rBAbiLcEYtjO/VPJFp6mRu rQ2yRvIjxZdfmOuwhVOitb08Jpt9mI098THUlbY8lYMSJ20RP16MkKzp6fb2zMEwZls1Hri9 oe4/HLjNF/wRwRUlTO9GCdN1yWCaogEeytQg76UbUtdZh2imucQyTZOK+DSPZiBek9bsSs0h Iza6zRFT8dHd4twY6StRaS6N8iGTzVOzI/WbUdjXPmfyg/WvKEx6j4fMYW3egk+zzliP0nTL rHcgR0zzhbyC2uzcZOMbWZHhDV78Ms2Ll9pwMliaxZW63eppS7E4fSVR1BL8EOyq+lbJ9nYW t1vK7yyOJ/lvyq6Xv2uhSGJSxSekaCIwGrEe31xB2preJdwqtS2kkFHAnEKbPbqerqLNdqfc wNX5VbpASWM6HajVIYLnBZl/R7lNjSfA/KbRR3gNw2B6GzIOO5MX5LiI5lziyzfg78u6v28Q MRONgx1plHwS4hJ0i+AvTd71nWH/bk7p++CQZG/z4w+Y690jWQN6KDH4gM0yZYYqUe2j+Cwn sWlalibh7Jc5KZY5i6SdDtlIIl50c8DbkrlJDJA4DaaKUicrWROU0cp0gRf/7SujVGNJ4NA0 Z/sYULAd7PlztRoVzRA7lFtJL6VeL4l/mYeJUyPwMvngUsmu1FO+3Yfe5UiveICVKhVxie+E J832aYmjxwK6kt44ZHdfxDx3L9FpPaFze6V2tZTRHpZXmqclYBT+HjHsvIOSl742FQvZAIIN XgZGqgH6rlNR2EAyyj7+ZDiHKDfAzyoNILSA0uyWXAP+prJa+BAmOavqMM2UNL+SoVfFtZPS 1EOeRjBjH8dfdSq+c5UmAzRPMgkO3EWPF/MiVeD89XE0Gw7imQkPbysxnA/iEhtBSKTFUKW7 x32pejYqCQY/nU0+wqrgPYay/n2N6Omhv5gOBz3Is4TaW6NefCHWcI6+3sN4/u+gB5kZO+U2 JyWMgmH0cUfDPzaPhcxUYElvpvN/ZYDnJQHLqJLO02XsWTdbFxHI0pRdG7zDV4CyNpJtjaKk 6jTf5K0S8FZJ8c1bcM5GM6z+3Kor3wamTXUePJJGKxs3YNKPqdEu0EMEwrDyIppFuOvxRBSF eIs0n4hvKTfmC1tpkdHcl9lSomRvtxAJZfhbskIjBYab5s/knioorKpgZ/+rNXSAWBek1W6W gRNqUOZbGdzMcemWw5C8bqkQlyvDpUU4h5xvnMRAPm+rm3QM2wy8yKyIWTkRlRyTnRZx7Y58 Ti3GWqaoTXGoO2VmC9ZIzZbOdY3j1SnLfYa6NoFm74okf0vAg1GmQ61+n1NEKfVI+FVTJfaC aXXoe+bdw6RqAsWr8QOZ/8/Swfr3i5urygS2gW7MlCArj9rjRV8wlbYOndl5Rxif1J7cJWZF IwOpj/pG0ewTWQeJBV4po6wyVaHca7dca+tSzH9w7FAMcJr4bsGG74j3Gmw1kFFxb9/U5eye 7P4BhBexNPJSHF5QGorFaL9TLNWgS62y8V9tl91svVcW9fA5wPD6ET05dlEfZKazfrDlYPDb oFtqv6p2w5OzRrngHy9nn2+2jzbub9BWDzQGFReiC5YsFJdfiJOjSJBOxNpzreIaQ8kcxMav HBZ0xs/sQeoVSuDEiQqieIWhM6PrgKUQIZMgEvwIMrEsCmjgHXn2pZoMPA1IwzrzQsICnWiX cdEBq36By740IUodm/r63FX9fdNXynvOS7ZZDJxBFe5JhbwKf/IcMsgm1CkD6dO+rJHlOpMJ HSkvjodK1ue/C6oNlykte+Fdlzt5HlsttuTT8wpyVzZb6gFFvhVRBnszXfcGuQsJmXtXEPqh 2wJ46wRPA/KnFLK2btGqvC8NejK9x7WTh8kxdRbJTJ6Zfmxlwsh8b31pvrdaLPd+X0ZVQlnH CkGyY5NSvXRmYyrfWnQJuZqJM1Mvk581MZuPktJ7nDCKVKW+GWpna5SblhGA+UJHxp+meb5h OkXJPn/Ne+H7VkOqx5D3+/AsI9ukhbXCVskaaQFHIsRo1HySIjI/noltgNE9aq3gH9q8TaFj 94NsAv/cs//c/2C8i+jPBzbUof3nE7NSFjIUuDt7wuHn1R7UMl63U+9sTmpS23Qn/dJmk21h 0zbMUQlXyWRAvXj5It7Qk6HhF++hNbtZl/vbOzXL/Gu9m3aaJfjz6WpDNn/aWoNpqIjF5P33 ixGKdfN/xrZ0gSYgtTFpXEAGBNXHNwn6jeN4pdu4bOD0GiMWVTifqfjz7dsGObPB35tF0xXQ +MNOD+ItgOR4R56UNSopt+EcjxYgYZfiPjVC+Ot/2GAplUlnaf26Vd+vdpD1aLZMhqgX/4X0 4r8E39vPp+LTo0fEQWRlgaRN07zg/S8fWAMnIUzcbjoKVwlT5/Nls7BScD5rBM2GrKYYmCo6 OXGaJPlWCrh2Qyy20WD7PFZLTNswiM6I92IqS5BKVfxP7/moRgcKkGD7B9BaBKfR1F4tZ3dI riIry9cjwCrUh9+QxJ16vKE83wW2mPOkN2IK2OD9ck9mm5Wm/MvJ5R301ByVE1CK33LiMW9k aGGsMMQ8gq3MLoUQZLrdH5m5DvBOlszBOR7jriY6vgmHeePh9uN53JtvdeDO/nqSiF0m8DME ndTD+Wg6t4MmK6jg4eUkMR/6GUC2CqUoAD6Uvx1lhV5WpgLq1RGqJMQNhZzzS1GzR4q8jG+a vYHgtJRwbNdoG76D//rDKXmxy9ZtZRhHzGYfZzFNdE/vkfQqtipPY5Oz5dnvaXQlE1u/XGpX OvyihvylR5knuE+nZk/0HJOt7eCDzFtB5ki71Ig20N3i0cNswAyYF34ro42i0ziTCRRAQwUp 8Sok0HMttM6WwoqPwDfKJij7pBbI0XUyng/GHMMRoGlhvrcQomKc9d5jMWAkU/LIEDroVNAN OA9kklHwMu30XgRnlAFRXEtm8UeBBnFVhzDLwX8Kdoe8g4YqbkaOoaRBcubdV0heSTzXYygC NfqHX7DvqQ4zM8Z4yobajcXoXIwPnydm/UTevncU480aGw2NjGYwFAMPDgsT7PFiS8oB4kS6 6KGLOuVD4Mh1vG9RRydRtQVbwJ2eu5UL8rDZgi8vX5orQlE/1XhWnYXiElpkTTOQAvwqzmCD j8jVkd/E4gQrDt+VAVztiiEGyJpwUH4M4SVOCAB2bAoDhlZkoGL2MJ7hP+Rz/JjmMYr4dEv1 LNszYJ4YH8Hlir4Sw+K/eVlNfgi/z2LOYYzcHzexwFLB2ucKBqOFK5jg26DWbFc7zbN2uRrW moUsig5eBGUhl07m5KpAid2DVrnGoc/QeEM+ExrUjbS3GCvqg/lxkZ+QTFai7hA2N1IRZXUQ EgMjGIVEfWBxBzEQgYnT+GLwMfw6mfUZB2IKIJGdlsBV8VuDTfJ4ZPXB7LPguWMMWIVHt/hg iVLG5ge0HNeaoGuDy1wixHZwpBs8ngTf/KcQdERVwaooBJTNzWkzq9HTr7JrM5am2BUhovxl MJjMYnER2dJI+DZolV5Vw9NS58disLe7f6iSeBo51TlA1Sl4EvUFFexgMlZ23giSadQDdxXU kCZGylWYWxmxuJjRvUSuLbwOC87/VbR2fi1zLAWQlYirZgNKXyUFYfoOouI2mv8bkr/OVOKm QEw5URVL/D7dgWGnk79KJyTG2BZldCg4qHykHLuFwN2pdsWHrcDE6v8qtAZOBBFvN0iJnKY7 DWB70pgrap+Avq3IS86X8QcPHvzOG87ebbX2T3t4t0ACTlMoj5jzdGmqRfsu3qVbuAC4lZir SU6l2gqUUZv49CXSIR0wxLMYcj8YiJMMXiLEiBw9vKzBZijQqtW62OtyMVTCAXsuwT+CTins vBZtC4zv6kt3MTBwCqOmzrIllsAUWXi4cDPbUqP8pl/YSSGzyPOWQkzOymYsbcba2ovLZzQd PMCZSH9Bv5njIWiHF+5qa3LiZHhqZciuknvL5X7A3EYc5ko+CTkddCJjVTzQ6zSYY7CKbKmL 92+g2mXNCemsQB5QgiJtmrSsiJ5yQC0KIdZ65ywCbWVppQUJ6Magwxohn9XBE9bZhXYUmEyf IZyUxqU0ywFeHw3mOG/gsuhTDi7cYLm1mGK4EPhO+gm4FAELZWZNcNOhuDLuBCZDnQgRkq5U Wj5CQ/eHr/91hLet8Dy+gDQlXFiUVzBS5Dvu8C/lczpaobByCTRA0uDsWimJDAhpmXARnc/E Td0DIcQTUJ2R8YYCKBwVlLnsRm+6EGQ3jK62pIVtNJsNxKI6mQoMXciGIeDq7Ch6XexLLUjk xhcjwh++RA74GfJTHCSLWayzmZTKZZkNvdWuo4tnjA6n5AQq1xMfZUr1Vsnw+hz1xYSut/Z2 0YJM9HT2cXj9IKjH1PKrSR+NuD5ChsOR1BEYExBU+wXctGyVgTxevFI+KyJMRcP5YJLgQ7BK LwLbRipGEhS8uOQck9vIonERrzeiS8Ew5oKwxXk+mF9zHIvp+w8p9y0JgmqFKWnqnx7yX6io P9jnv1BPj9XAKHlPaiSp5AcSlPjQ4Yb2n5BULpt6eiD/1G09xhYEOKiFBFghy1nZRBA69bKg SfqY8kjsxofwb5HMK7Ye9idwCprFBSPpeTr/xDpB+lnk9cbpPym3zByu/Exfe6NDzplJ6V8G MDaMJCiWUHDM/urx/TNVTXaTfLFaqnfKuVt6rpZeDZV5yctLG+PmBHMyf5nru7l2miyaPe2Z CR6z8B8dl8nGjrixwqM3h56O+3aAOYIVMFZQtU4NdNChWIizqriUvmILUD17cAjZuehNQ44I I2giLDe69fAnJBGqnxEeDcIigZPUrVtXDWR0EDTblWpbUPGte+AGlsVnwxdpecZtBx4tgUv7 HwqCk2w9Eczg9b+02cttB7axSo+OmkJZ0hpmIHdd1xsVdFg2unKLZw2xPK9oRnzaeOrqB1MU KLMg9pdC7C2FQMbOmY0tVA4XY96p0jHQN8n+eZG5Uw95tfwdnTMKGR1jxmhyyYGeh9yzvJyA NQfX1hHeIowv0SfWueNEmJjGVrCXxM5jhs8SZtguyRLWSidnu37fqJydlPdMNv/eCZn4Abl9 DQwbzzrVow05pVNpbRXJvG4q8zIHuhCHyaQ3IPN+NP2PtwqBtMcnyUfI8iyUgljP3gRmFAxD ErKXQRpl+4YLi8Es2uSZUA0cQg2POIyOFj594XzY20192X+Rn/xDB1s7chSQ7n4iglG7CuuI 4zmjQn4Kw/zhQES4NUcDVZYMhs0sUhG1EAhQzFTFf+qwWnajOrYWQfaFLL9BTX/Ge34yGX6J 2RYOzY1cRmmkSHSMHEioOY/6TsRcSK4iZrd7dVI90sozmV0Qw3ODMDzeRldI8FIp1cNWSRE2 UOcmEPKmvFUp9xIg+PMYHVXEHqenIHKXkJkKdB5ErttfoAIhCrp8/YJ7QATDpm53IAx9FLS6 raBnKuiK8kZHjWqpEVPYwy0kifFFAMJizlHHho6I4ItIOw+33gX1kuzQ5SWaigujuJmLq0vv UwIWaWIjT2afErAUBNeeB8alMdduYMOTMTCdtkOlrUgRRpoynLwVtLArpT+TW+FYCCD8tn50 G87pGlGCreg3V+jdqQ0opWgGABbD3TXjCecZEGhTKvZvTsTAFPEXg89KBNEDMiELrBpRIUXW nacdguQmd+FW3PpLl5MtL4qcDCZjJc0ryvffB3tPacAc0QgZ2GmjYoU1Wj/jKnCE2kWgLFKK sH/GcKBRHCjTXJqPJoTPtt/nFpB98KW4J0Pz8RkoZAXQvYFtw2QWzQYQ9akzgU6HfMvnwxB1 CIJXbAtmYRyMTjbS1FUl9+IanYs7hntjtayr/oDLXHD/t7k/4ua80pXYl0IVbSMQ8zo4u87M Z19E03dRrKjyT69+C13vZL3juYpnCgdDAy5JAe44DBp/j4Zfo+sEdgIr09W7Eo5QbDcaYzCQ Pqq/LFBtBoLZzg4/C61/hOMd/B4O8NR5bZyQmj+fjXk+/UCdHdJY/691KN7ykLvlLeSkVKvT NVIFwl6d9QpI4p63Yb1UE+Kn3pH16ssdJrtGuzmpzC3rikjgqMrR1zqvXZIKiGx4+sM2zLj6 DNC6Bhk2SwU5gMYrhORYA9+jhBRTBsEPvoCYbD0sZ9dTG/w8DhSdizkjMjbvlUDu/TKXcaki 9Pz2Mp18AHDjsG3609rEWF9yXBkMIFvkgzcUu1H5tqGj/V5CDGTF5CC933G3I58U5rwn4Lkf cCvZk2DAyOm+0i6Ig+NSCC8Rg8QIW8LUCu0J4gw2AsnAwE/2fJ6YwQjMqVkRielc6AjUng/m ZOdHZ6NKgACbeywDwwXSeCXh/sUGlZGQzbd+JlNaj2/tHQLl3KF2vNESKUjD76HeB/0sL8G/ FQe6OKPfyE3zcMtbL/hW3o4RvNZ4I98F1URCLBF8Ed8DTfQYWR4c8cw4vdfcF7wtOmdlcEr1 GM07tOj3ljKEFjvwMa/Vl8lQNCgOP34ZGC6SS5xn0VzgJUujT5ISjMkMdU1WFApTAnj1ZQQq ohgrqrVEjHWI/qdf4n/YWrOM9cbsmzxua4cbsXlrF3YvFhOHDVQbn4PBQjGQroQngCdSX4nO girQBAUFYpOW/0oo+6Bt17Au7dFyyBd07YplUN6GXrLsnD8EAwozlfdHhXzaMhoAz7XnuzJX BEa85PfwW/eyxq5VI9JLmRoOjWadRm898pU3vmFLiuK/ES7pIQfKNwxfZoKatpszCJHcjsX1 Nh6dD6+LlN0S7arw/ZaY+QtFb4MZ+IBhiOzg3/FsAqI1VOHcnxwQif0Dq5Vjlk4V5fE4IEzT IgEFwpeBuAhKD0Yf+oJHwbOCjJXoximCkMLoiTGQJphGUGGZHIAEFv5L+sIajzUkd6jGJKk9 1GNVv0q3bR20SD+PsIwCQYnRwBFNi4iUwIpjhvgcu+xSOjw5lhkG3wo0AfQ3rUV3PAftcP26 LZM1CPzFRtMwUGzc27BOBLDhcdz3MYUVmb/D7VOpx3JcfDhyCBDgcOt1U+yHcrPRbTfrdAeR 2+liBEaa89lkqHcSPh+krCSYpwYntZMm0LsQyufXpjzQn0jnz9tlNhN7kKwp9nfZmvZGMphU irJ2tVyFvEAwmBCCmrxjTz05geanneCV2HUQ3Bwtb3AV5I+pLGUUac4lrsoTnRlmKd/h+tWf a91wPTzb4TEzlbaE1blYEUVEfDNSVk7/v1+xuy4CPBUgr6V5S9Ms634IqYVPwZgWVgFsX9OG q+wNChxAZ8cwOETNZUvFtA0csC/B7MkVb2dHG2fzHElLVa/9q7qUQm5W8GZ29EU5OYpZKXD/ EV88ERi4LzOmtxkpQnnSrRSfw86vTVECnBTXehiZkVqUcQDd2KS2h4NA9hazmRAYhtdGamyG ByXyXKuFI1mT07vUJ71oKP6dTIPJTFeZwONQOx5N5jEVisUdx705RoqeTRYfL0U53ZnNjsZB PIBHIVSiFUHV8RUk6E/jyVe8KcY6/zAMQtcko7XmeLsOKpPoYyQmALo3j6ZEV5I6E6V/G2Bm B7iBzmcDUojYMdz48GYUfNN3son741Rs5GQR1wEIFGRqpU0TCyuWqR0nSNLUr0bYPZDfMHSe 4GjJZIwY7Q9o2DADjJU3nYwTqeBkzIAh4A7Y8f07AG4A13pE6Y4vrp0nwTrUH+hA8tjczo4d wG06GxroEBAmNrIiXXH9GwsxKYzdrBXfI8vN23y78jGWlCWdl62M2R1crIZSF0L+LTCn3GOB mOTpeTwbDcaRuGYjcrXbYqLSXiSsoJfpXak8tsp3oZDl+Vn8mUvIEQE/FtL2ILGOKoJCbILy LONFWVVioBp0dn2YDMUwxL/7GswY70c2i7l9mjg+kQbjc8Q/3WZ2UN0Qin2MudZBDoAMOvI2 Wmsc09XnjeB3R9mtYF3L8zMDkGYzi3tf+jTkZKUK8dUUOd1qdTA18YVOIqmODFqlRRILfKpd bSDYLJdG+0NwlaBV2fItW9bSb2QGdxVtW5FdN9IkCRnvh3vi7KFb3WPSaByfnZxU2xin1oya bEJ+k4JU8U9Tvah4QzBJ9ceNE1TIQZM9SK8ZVPZw9Rq4VbLHnTlsDB0pWnxA6yUV9NLKAzJH gT0DMEsMhYk5FmbxaJCwRMtC7Si6wlMRjmN52yZGzuu8/THCA5R3PftUQbtPD2QWHFlxckFG xWCLzNF2wGF0B/RYwPKDEN5twFRqIWTnwWT8j1T4qTSifwie7O0rcpGpeJRjasdIxgOJI/DN EZ1JU01Jbs9tVAYJvsR1eKKvcKIPHjxwM5TsmZ4mGxrPHVBgYmwxzkwnuppjk45tGB3/Xwjz ElmYSkjcS3AVyJtN6a7bcM3Srw7kyOAJ1qXSRnWMTKjuuDX/NfQcYqiQqYltGOBPndtqQ38E GL50uKCiPdGrINrOuxxuBOAy/Krkq6B7gYPwfJFs8WAKhWWcyhd8hJjMch5D74wwDI7VLTja 9g88LBWWmRvHshVZz/4qrMd0wNhI+/ViMTnzalHroUKMF2tyKgUrfu5MRp7NGrQkBT2YG2fy u5op7i9lihkM3ti7EOjb5vZLJqbli4IhvyqZwzO3x4cSzp2cOWxPt7tXe+Rj0rXFJPaalfea pDeDBEDBNEJVOBq1CqH/cjLs8zs5pLQR1ElXYrEl7G3q3xXUaAiNym0pN1bOZlKCwGyyRAjQ Sc3iq9VAlezDsCmLR1SNuvanRQrs4Taqnu+VCEWBHzMz8LrZezkp6WKeIa718UGGFrJ51tVy WvBbMB5YFyB/U+C4TkZW2rA52YKqkAzle4jUn1fdsCdNIF1qSLlVDkT38Fe1Gpbb1Uqty383 mqG40eg/4Bqd2/58Mo+GkAE0ZP4C8SbfYDpgmYI6oyZ4pumRKdTUa40f83uE91aK1xkayHUW PLcJlZvYTEecVwHMLGZfyAPoajcPkvMvKmTQ9PyZrHn/EsdhZY2TVn3DykEMwcz95kwb8iEj 27hKm1bBB7POqqZVfLVeOc/7Dmsc1I05W7D8IWCKVqE4l2WCz8kFb8XfYmscudfys8I7RJRO Du+KMyvke0+JOX9YpvSNZVSaJ+/cYnTqJFwhPav0T/7rX/jiP+TCF9/twhf/SRe+eNULn3Hl w6x5m6n6mwHqwQcfF5NFEsJjY6Ke8ekiKO4wkDR1h8MlKyOVC3h0dYQZ7wobvVlLDUzwFwMX GUlXH6WbKQQ/vFTvokYEfU/GViWy6gfYFdLFik4HvpSxHvl8YATa2chOKuuyMIdXucxqY2AM /cbaurScHyfzIB5DVDQYHq5b+v7n3eF+3hQvuYitkthecSJiE7dhEMv5Q8ZFz7ifrcIpVrpl 0VFHK6XNUbEDRhUG00rtVXWfSh052bjTZwxYAygBWXRuXOLw4XH2iZLWw4t+BAbD/IIPYW/s 5C8rZkYmKtcXdUVjpDzm0NgjcZoYL55St4w0yAIHGlSoHMiJ5h+aw6BF6ZzjAxgPAEl0wcZA G4bZ3ZINtWEuRd7F9ka/Rf1zkcyl1XQwmP8bnw+iYATS1XSIOX/0g43bHimt0s80K5w7a1PV kvZ+Nxq7G+HkrNZN5vEq79IY8oETkCfiKjuIhjvwGAhHF9nzbEI2HCHjbqrnI7JdFtLvjiP1 PlwFJaCB+IDxUcCcZs0av6F5VQL4E/fXSiri/BLN1O/PhmWva8olq/BGPxFrVUw+Y7xnml2d Ld6JuG/DFG/LEy2WaHPEnC2WrwpL7bmVeeEyVrjCVTOPJS4nJt5ixWDlxn8nUrsTAWWvnO/F XVO1wRkjgw+KHjfTZ9EfwfdIvWLzvbSUejIYR8PhtdoVYBggyBwciCaCY4/7D2yJdU2VosM6 1XpppVaGUvEGNUB56de9fpRZcdc3PH6edMAZVw6zkHJkQQgQ2UFH5Q9OgaYGCMeJHQIha2BS icW2UgistW+yOpuSq1w42nlnkDD/JEtyJ0hDNA7ECoBXGcZqsOIUKMtztk9bLbTCA46tUHpT qtVLx3XJIXg1rJgPTnhBVQa4NefrxPlvTIgV4wSTIAIjU3iR25QZF4QgIRUoyIw6zZPu21K7 GoIOrGu7Be/58mLgctEroIeili/ahjMhm5KcmW6Zrga4OQvaus6AzCQi9TiYSUMy0DJ5bhJi mTLT7xIuHXVIlluTivB10yIlqMRukhigNaJVhNdHdqKEZ1T09Q0iqjHiEMXiDDvYt6gzCYRQ dW24DFtEuuxV8wE9axo6AV7ajsvV9e6XtU3ihL8ziNN8sv7DKVRNYwm7k3NyOZ05V2JyHTwm uu1a1WRzGs7vij2LwWRJmW47fteWWeUfGTIrP4LiQEjKEKzWjnnqdTsX4p+YDIk6cmzQ7ZIJ 43phLUEh75/vUsIlDpgtPhWDzRp45k4vQaaDVp20XhDhFndDqR9NIbj4IoGNR0E7MWakmpg5 btG0HPl/9uMLMHqEfBP1amNj4zns+//EKOBiYOTGBs5b0C4GE1aplLKTD2BCgfCi994MwP7h yGFZg8mR/TdGKTY+nEf9IxjN7tU5Pp3Cv4KBBRPIWBXg5gkiwZ9gMGYORzOGeEzhciyAEONz BnqhBvMt2DW8JXAs2p6qPxtA/sg55x/YGU36iyG+9byudcLTZuWMolBZ3SJlbn3r1FXO526b 7IOMO8oZvjSmDizHCyeg6AuiAlnLDCVqRtxNN628L9xooTkTIKGQbJopt4Cd5MRPDuBQCsH2 BVmIv7ZkzG+B63g2M+LqPoC4/tlhUzHBMDaRDpXKJD94tFfwxiRVaSwoSP3gA0dIJDKYzibn cTjtDbZgBJTdZDZDe35GiZgRDF0Vw3AB5HuV5YgYigv3O8wjlEkdKCixGIsO8UmuRirzFO/5 7SrkHHtzlJdFBI+OMIyvjN0Bf2TtjtsQAQJjRAYcN3b5kBfFyjOywZAfd/rick1b1nAs8Pt0 QBWOnjLOXLdUvFtdCzenHEXBCIKLf9OwfEtsZ/VwVyO174yQQivuu4BXirgP8SyTgcEwuAxX zFw+MrdCTLtTz5ILcJWLvxjhIp2adpYkuuGNLpLzz3RIKkRhqvAtGcU83x/PqA9BIZ4UDH/b rU3Kj46rsU+9uw9UnZPOMZpMvOq+1t56rgKM5BiWYYznHnsuyUUi36feDx5adYRo/suHghXM evVqWVPa8yF00vOhc8uMCe8AptsYjFZsQwGuvrCeVgzQdDvJ6u0kee2gNiOHzNKQkpqc8aDa aaWGFKi/JeeZfqUp+up4xrjyXJPcuSpNxEpjs6E9RKtHsknJx+zegIshVYJkTNcj6NLdLh6w I39bl9PVGnPgMloDWhfnfX9JYzZY1tY9MHKIcVJ4ywOMTsRb5MFU2Qjsz15YIx8aTUUnsZQn kTFAN8lZdrZAX4pAGlROGkHvYApO4kTfgeJqNXKD7medXTKmVE5d7GxwseXLhcFykyE2nVZP kcT/YxuzDbDP4QBSe4SXX03Pw42XQa38utYKX7+VrqziJv8KDK8E+0/3dpTRpPYVDYwWO91S 96xzqwbRYHgUJZ/cNkuVShvThKzSrHS3lMcNN9Ys/xQelzqgtHhV6wjk66QkKzU1jMdGS3R+ 37YttV2NFlttcUkri6Zu2aZiJ0abYnU7Z6e3a1OetHItTm+PPmhKow9auj36oC13qtDiXafq Lgm0eZcl0SIGN3iKct9tUUjNaSSeGlLk7dvDSZsN3n3GuDZmk3dZGGgSEnNb877DrBN3UTp3 WpTEWZTOHRclcRelc+dFSdxF6dx5UZLUonTutihSaJWt4bvqbZcEGjNGhobmtx+auPa6c4Wn j9u3iNa8nDSNGpQWvWJJTmqv7tKmPN/tRuXxfqtWrSNeNqpP+Fu1aUd3MNo9qZ91XtMz6i3a pugKGq8np6/ad0CqHazBaO+2+BQNWtjE9m6PStHcfPLFbKtbu+WGFk19/SpueAOztbdvG+Hr 2h2aG06+uu3Vm7dsb3YVRkNxkTMbbJffVEJI1rNqm/+xLSPBLZO5jacszsUDvu3/sR085FgQ X6IZvpAlL/Aj+kOKa8s2P/e9CDY/9nrBduXHartRrQfbb6PhMNhuPg22LyajwXwb3Xy2uc9g u/Z4kcweJ7Pe4+FgvLh6PI7nj+e9abDdC5QydpN64hxw20ybL4I5ff8UT+fb4/jrNgMkL4In WFIVw4FfHv/H9vZ2gO1v7+883dnb2571DrZHo73ti8Vw+Jh0eQn2fdF7rLR2053Ljf3d3Sfb u/vbu4fB/u6L/b0XT/Z2duVP8Gh3b3f3Px49ehQ87sdfHo9Fa1DjcFt0sf8k2D14sff0xf6T VI3//u9ge6+4fyj+LO4G//3fmBN73I8vglrrNXYOwr9+/LG/6u/1ejnsNEqtEF+Gdq+ecxbn JrqPJdoRrtRuURRrxIasLr6GzVa5WamGuxtbu1dPBf2YTRa8oHsA+iwNar8oorY+K5W1/YyE WnbSmK4EL7uYTOPxejV6w0kSr1cFLGfE9ut90vFnxCUNTsbgYfLpvBgsbe0eUn9nzAaj9ECw 3Yx6lOoKHI7sNzbUNAvGAuD21HyhdR6iGEApRDGFdnQ9nET9EAyAjJGZjQrhNa9hDx6dKc6v xPbLRbudmHsIQUo9+oZUq9FMNUuTozzAK7emM73fhqWMJ1/EJtzpMZPY3xYsYH//xcHhi8Pv 7o+tPHuu+crjh/fyEyBDBVMRGZG68aZdOpVhgtxHcHj2th/Cy9EME6qIVkriQAAeHo+RQ5Et 5gWovl6ArcpsHifXZovlyQwiJMOT6Q420CFjZTDuHH/CvHc/CpofBz8tBhC19NNn+O9/D7D2 jjiXsNa9/Dw2me/JSXhaelUrB/yze3X49PCpLq8cp8oPD/eN8rqnvE8bVcKUTyvAXSVI8B0x eP0DU6NjEH46GI4lTjAoHDVBBgKkwkYsJzt2na4V61FWAptZ6V2NEgGEfBKNTsDSVlYFWWCy SIIJho9IZOQFq7OgNRuMMLw1tCc2h64OA+vH54uPH0XPalQOtqURBhpwOInoaTuFHEH5/SG8 t/4q2hA/cnGK9KdcC/ln3fpzN7g5skSdKEC1KScFUpZMaE3MwdrBHEBGXms0YTOwqGGYbLTD 6s/daqMCawv70yyh3DtYcmiXYB4cKnlul1Tb4mpIJb1ds6fq20qHqpi9vG2X6tyQ8bWqvu6b X98Sle1eHewaiKgYNIRBSyCBM2/6jFkf17pbVwVFscHWHjhwi08FCzdvKrXwWEMd7NllgfED LRJ8wQJqukDfWeXlqlt+sGsBdH50AfbtFgSRNM4IWxLgeSF/B9bGveGiHzs7LYOD/Bh35kI8 rl7FvQXsoBalTZ3MGIG/qhCZcHr1i8H06H8wrB+ux1b/5e5R0P/+SvwDzgL4bQrfpt/vwb/i I8FDDfFzI2nc/6MmgvkTeIhM9zEECF3EKs0rR5Tj5EDKAgPLp4t5gu3MKSi42JqSMzjgafRk Mtvyyauw1KhsUXLkwELM/CigaYo5zq34jmO+RzGjsN8CCkcC3qj47csAmz8Klv6oWhz2cM4Z nVfrTi7FWgsxmf1l1qHZ/j2X4be/3DJ0YjSCdcJtEvsrWvEHyfq2N+rrMxaj/gaCF0F550cM lY/56WJxgJWrJNGUId46RmdyzhzwvkrAZlevnFhweAnEmM0YTKrzI7aBRkH4QXTGocmxl7i/ xvqiWBcKsWML8nyIJaYg0hLV6F0FmXJHffVNbs3/3QKe+xvw1ULBKhUEA0X6IxmGAKsafM8i jnQ71YsayMHUf2yedbe2esG38jCRYtE22GAXgn8Ee5BWXXI7rNsTgJD/K7hZcZVpoTB9RrVI QukIPHbOWRCiB2VcI2O5ZTio9VFcb4d0Qin8IY5WHCvQC+aTAbvbc4p6Jf4DKeCBWiwa3SEh j4t5Uizn7IGx5m4x4PMdG4YGxN2arRQhzM6Yhn4LQqK1o67F6qoFMiZdqRUMzsH0oqqI5eaz 3wDKPjifGESgSE8Q5K0qwwCD/3Xr39xhiYBqWMWmcd+PZQpOlqyQxzPrBj+3yMyaAXH9bfFr 3RWpNYh/88+vkhsGd8GZUZ/X9ZYtAI2KIyDv9DAiNQueAJKg4gFHgdnWTb6wdiITMInBzCcQ MyXJv4WY2pfxLMyKSczhRWeudsSo2p9YCi+/zsKt1ANvj2QxyqiVR5fr/NhIIrXvTDAFQUQv As8kNGxrIa7qCUDRj1Y3810twBBDM12jEie92QDvjy/sftP9oERBUhC3pvSbMovSNYYCg600 HUa9eEc3Vwok9lRyGt5t4qobKYHqNPooEF+eTD4N+BaM1eK+0VTtQoBf80k9QqDzqF80diUJ AnLufR30UTfCl1ba63Rhj8ROn2Ewx5HYGdFHzJ3ZHyRiKtdxfyd/q6+txlifMNF4h5aVEkvA 786VvHeJKCbzYwlL3gFkri8v/vL4l6ptQhx5zuoIFHL/Aw8le2pn++F2Q8sl7vnRy8CpxAO5 kb2DuRkBY5IHGtzekVlsteAZoRA8DtGgWqoZClZDazRzgM1I9YTZTEraNSzlljS6T43WfWPT oxPfGMkrL4esCsa8Wxl4kbmj0ku3e3Uhfo64nZtAe0ukYR3VzkC0nNnhB9WkNOn2sExikQx1 8ycwSwxonsUoZ5jJAfLmfhxirFjQtBlH/DJmifWBwew9pSsDCg4jSJuwmAJjgRbhSJL3C9ZE B4GtCJTVBRSKLcp/ngaIv4D0AvJwwhdLlGaUyHL/HGrdQ9fLpuiCqn8nKUOzJCX3sM6noEpQ EwY/DzWWMRgTynRKQEN5z2T1F0LaAV4e9z/GjHXVkHIylzcJRDY2IWEey/71jUzqBh8p4SI1 wsbkqx4lJmTj9YZVpRMKLD9x6AgnTpjKHmcrrOwXVUMwqGQSQMpmZzwacy4r33tqsApT2iQT V6hIdzL+Q9z053pPmhc+uBqllwYuCvoTS5mp9SKCJBWC8Yj9B+92yXeyt7yo2luA74gUZpR8 Aq5hBkNcZf/rxiLdjlTacvss7gxGIFlQQoTEaEHliBiku//9xY480XZtuSNNmhlnB8ScZTeU PPGB20sdUttUicjsNu+BYGRFRgb2a+CT5/f2Gniwl21kgAZdHjMD+T1dUi41wp/OqmfVjYP9 jHon5eDXgCNNwT//wxxE/Oyga2r65+UyN1rThXazSAo81Wg/noNGLN2oxDIBFL36Q9UKe0Bn t8IAxdxWkGaDnLEAQDFDl6laMdNoe1sxAYquRnTnfDCB53ex5zc2dB34ih+LOT33ojE17o4/ RQB5rYDyDCK5prAg6HGpRle1knyk+O0YxN5sZf/Jk+LKrfRG/XAKwWoXY3ssz4vB6mOBoH69 4QKU5XCm61YqtQ7EzhBn1hnYYdUar4rZrcSXlIJTJsdNrSuWFpeMRbTCdiQUnkA2JnMXrzgl 0cw5KlHMNoJbtIKeOE4zq7WSCkNAO3VLeeOHXfavDB7OR1MUI0xwcxtspfK14BGz9RCu+oXA LC647SyJfnC0Str6o/WDDDjtqg1qwVcGySdxRvfFf5RNyjmmbZWGPuMii8jvP5AUdDsbFTAZ TJ9FB/dp8Hb47Mm9W6Z4n6k576lrg0KvQEN+H7MNV7CdrUEBHHKCbqtGxir3ZzTCR28IFr/m mas+6E+n78JW6VWVhBT6Odz9zrAsaVdb9Vq51DUeuHevTk6MFko/h+BN3tEAe/vPjDf6drNU KZc6XbsB+PEAoQ+SBeSCOunIEHbfLS51u5Aaj4v33OJGs2uAGKYJ4IntMg+jNkZIcIot4whp Y12vnda6ara7e9WTNAyb0QbSQGLXMahkdaOgkwAJxbSmzHQsAyMI0eHzXSFx2h0VPLUdJzJV +3Cl2ml3Maz9nbdvnJqk+dfRrP8VbvgyiWBbPiZLmyDPZMttCoRjkNHung+qUjXhBJQPqNrA s7TW6JbYmAV+DqpBPvAxAx9UAdwHW3sL4eAxPSPCUiLGLAR0KK3jKvPvtGEAYb3ULb+WM9vP arfEkSZPI8HSV2m9dNoOj991BSd4W2rR0nbb3MvzJdCNpqogoA95TKye9vbpuSE9PZRXZ7UD JIuVtgPSKgrepSHXnHofR4b6k7IWkix5qyRNGvryTVsWnUbjhbi17yiTIuh2Mac8nzL/zk8o nW41yz8pQDmDLDfHDaSkILAh/Y4sCHtoQ2Y5ISHsc7fdLP8ihC4HPC+ZvvSUNf08rdppelpZ 7ocbyFNsuOxJPT+0IfOG+fy5DZuHgOdlnhFmTLiwEyYcU3RMnhw6xRWc2WX7BkLr5V0XMnuG 5UMXNm/c5ecudB5GymVzmbM98QC2IhlLh7S5J3k46fhw0snDiWVI2MnHyZ5Jyp1lONkzmUpn GU72di2cdPJwsrencAI3eZXXGjgt7H/I0oXp5lOYyHKI23DsJnO83RDUxEO2GxuCSieKoE7h oFmDKo1df0oCZ5BWFJGNjec+PrOxsWWKdY8P9gu+nZsLZm4Aq5tOZoHGysaG2bCi0H/H7vw4 OorLhVBMPREngyWXCjFv99DeSVbYWvnj1LbJxldhy+3vkS//h0so6Yae7O07c+DqJtDTQ3cx DUiWobeshSk8dtuyrVvteKN6VtmLC3H7LAx48ZuK8Scb3jrYf2gPUDZYSB3hfEBPMJOgPHzV eU4P3TnH9IiOaQ995PhyGgLinnkULfPWNKs9T1fLcCK0qpXT1XLcLWW17yTHyrpbltGGcsFW UhJ97rZBZkOiqn1DuTqUN2R629VG2zUQ4brtqhTCZAUhtEKwPVSHvYSXuoePjbdhfTcsVTzV 0bDbrP/0UNXXlVsl0fu7sPrGcDngq5Cnq2YTnBpLnU719Lj+LmRVGM1tOfJkonI/2qwwmxs6 dbrNW2XpoWne3m7CcVUXA6uKov0lI2FhP2sg6czuikLMsXROBa9q/stBG0B5BsxUayB31yEY iHf6r6oFJ5Hq28kkYQjxWUiSM2cnG3PJcwsWIzVlrVyPX4A9dGAzNiKAPndA/c66AFl2IDMc cQVoddcD6vGxBVB3qNneswD9PINebByvtvmPj2XiOc8PSnKWU0ir2e5maUtpBwSm0qTZwsxl 4UnpuF0r422v2ulo7hJ4oVvt6ptaUyyVhkdFhx8a9qHVMo0kCFbFUu4uf90UDJipzDPj3X2L 3VR/FgPKqiKgDyzedHJSrzWqWcjcfWLqFDD/W91z+BLsUwO2LPiKkD1Ostp9thJiljAdxP9Z K4MIbKrptkuNziksLPNu4H/WAWNKDw0A69bKtVapW2u8MjhQir2edVHUeNcop5bFha03Ox0E rr1qlOoW7F56DAK0DpwCGWvFgBWXabddgQfgLFVkGmJIBuyhA1trnaQalbD7NuxxiRiAZ/12 d/fcdhs/ii1Wq5+1qylYBDYotF7qCOSKITfF0SVXQmmyDlPtetcYYfdTsJXm24Yf1roRltrH NUETxupasLt7Nmz4ttnIGsOueS41W9VGBs2Tls6BtRbBgTUvbt2fw3K9kw37xIBtL4F96u4L cRvIgn2262EADtIk7HOXJoEeMtqtmHioV0IfU5ewJwYswDGtl8qQDNKB3T3xwlp8TsH6262f 7KXHsPtdBuy+B7bE3K1MXg9w9kkFVhesp0npt2VcHFo7e8+eyStm/g0CMkk0zxoV+Y5QazbS WMsFD2vu+WrzMyFLtNo1f/vQ+t4ScKN9aN1UdDdoLHD/9TUP4PtpcJCg/eBiQ6XBOzmtH6bB y3s22zTBn6TBzxo/NgSP4Uu3PdWnafDjs06tWiFod5mepi74oZDmG1li0LOUAiEX3NFOLgM3 CJymBkJgDWIQts9a3RR4KXWXMoX1FPixZ5lAhMcHB3uxUGeWAS4gT0uNitt6xT60+HLgYFyD V63WCZwlc5duAPxEXifGSguEGWMSlV+pB+8W0Tl4BH0FE8GvsfRECaIxbnZTQe/yhK1m+dSj pT+VZBmKm1rqLEat9rL742tyMaf38MUs9twfawdpDJlMX4A0PCDH5nkuQDx4fsKDEzekbt2+ YTkJieVjpBZhwR1c7Bo60Uv8zpWWvqAhE0Zf4XddUaYjBA4H1CcnIogrOO9elVOAdgpl+7Ji wp01NKRqV83F157Ru5qKvz3Vs5JijbAJsLEq1U65XWt1WcCCRckfH++u3aunu+rtT21zsYxh VcikZ7CeptIjNRkF2nFBD7ygtDyl465x23++lwdaLpvi/mEOaPufpnrs+ZNd81ET8lzb+jlI fH2ckp58IgOCVn2ge15QyBhfbQPVd3IuFAgqQwbZd7GMVlvpATy3JnmS2oDVn8uvS41XqDdq NcVWa1sbwtQXc/JvF/DQ3YlWFnJzxd0NVvLBqZ3j6VrnHffqA3xZwWkuxnzh/Ej1Kefrs4LQ 2nOKu2BIJY23binZWjz1smLF+KVVsvh+jE6PW83KcZrtV46F8F4SF8WDwOE/NlCDRCJHVZqC qTW6toLShalWHeXL7tVJxqlSvZrH437sm0rVMxVOhWwTp0cD/7wQ2JWqjYrvQm8DYYJhx5jF LIcUd64tjBTK8YW8POk7T/vAsODK/c9u/m4GOJMBZd33Aa4FVjuOAsYHd5KGO/TBCbCmq6Px wXVb7XrTXnlve6VKrVO2j23/PNJwu164dr0WuBRHCvwUoDORfS+ixQHmIPqpd4DtTrnhwHnb O4EQbe3qT8ZE/Ig57v7sKrj8CHxTduAqPrhq+XXTo9dMw3W6bnvlDLiOA3fsxUu5k1K+eeGq ncxTxIKrp+BOvHDtn1y5O2PdUu1954XrvnHhqv72ai5cybtBqp2uMz4vvbRTir0n3g3cflN2 1uNwz78x6w7cvre9V6Wac8052PXTc9mZx0EG3btqgqf+9ip2g6I977o10v1659FIt+fdbz9N Om3/y587vhQj2kvLqtizw32B9aJBprIuYmY/i6NEXJZ6cCCkrIoab+BMwISbENbRrwu1jTTL pTpoNYNMPeBBGj51XJnwhhai1W52m+VmZgcI/8wU79H8r9sMW9X2SbN96oP/zoykJiYKNqad s1Yrq/1jG3/x1XQYjemNx4tEIYdUf27VG9mvNq5IV34TntSq9Yr3rZ95mDHoZgNk659y2v/O bv8nNcdmu5vSwYo9WbYsJAURtErv6s1SJS3REHxFSdstivsozWLYhnDHtYZB0qSApBsbeyA8 2vM5a7eFIKuk1o5jMtoG0e5EyIClbvVVs/1Oim6GakNcrsW6v0mjrrIbiHHuB524ZwtAgg5B 5bCRWpw9rPG/e0+CURL37AtT8034plQ/s46PLW4JwpLsPYXkvDwYYwLd9OCAKR2ip2Yg9nS6 r1a3Fab62+KWsrviWxdUq1WyZEp13ahU6+I20X63oVQs+lFLyOUHoWd10ia9DAsqfu9tZ1eK o93LOImly/BsEHuCl7jb6W2zLXbG21qlGkK6QyETvg2k593HndF1OAXnGXAigxDL2fVe1169 zqh3Ofh4aexfVM/bldauKEe5ykjBKD/dnVEPk8b4Omy6SMmsiB06Sn2qae3w597GXRCrpdeh oJ+OoXpG/vOdFZEYnkeMd287ImGru9/qGsU2aeFVISyHJ5akBpumNJzHszHYCkLdWdwfzIPT j6PxHGxYXNZjNvCcG4CX6MEY0r8PIbZoD05GcOR65G8an2lHMbYvdQ3R+WzQ81pOV2qCr3cF r0I1iH5yYm8J06qBnupZEVZXoAxpaHtPQr81AENWrUCkOO1KrQIcFwEMZimFBS7HYmmy6zhZ xjNwKEq8czwpiyPxpBweOlfDvWeu4lJIeK2wVjm0mUJpLw2XvmqK1dp3+qz+s1ruOjDqxtuV imD/kMMy2He9WUGP5S5hWCIhQaCrbOdglaou944sD0lwRoa3MO+QcC+idqvWWnbZ1bCNn5EY lCHQsxNLCwYXSe/8idgq1a6YWrUC1i4bG0rft5diZhmA5oKc1aU1ELwwNxsG2IFrI+GHOzlx tBVKhR9cRpQrOoDYPOfXYkfOJxjpAHwm5tHsI1g8udbjMiN3t9R+Ve12iMADa3eUCUKGVfUZ VaShZXhWD/SeBV2td7J9HB3+VvYoYB2BxIKutYJc6Cd222mnLtc/jOgFLohSevPZW7/J61S+ LABXfQN2iM6t4pjMKt9UM5BdcusXg0qqGWxCCKfZw3jGPmiB/SCc1/nysb8BicYrCNvOb74+ 4X0lq47kDaBCyhSbQW/o6VqqU2DMB7M+bYxt/GzXF43764u9fohy8S5Wdplki5iMcwfUZ6+A 2EarfdsnBYbbKtXaqQsDjzVOwHl7kFxywIlpNJg56Ebtd7MdnpyZqgif8Qntbgcww6gFH21/ BjvwdkUZpVaMl45921JbiD7i7ikuIqiDfCX4X62Bt3lXPmp2DS28nK0DZLTgtQE1gcx3eXSI s3TTgveBN/RsBNW+wnNscjlZDPsQj1LF4ME32YicKtD1hoIGDkYxBg1NGYAyc4M3V0KplBeM 4wT1jdJV7WIyG2GuAvcQY5vAEG7epW4OGyuJ9VgCbeCn0jwtgatoFrxx0kpEySjlJrZiNG2P OOXFfBaNk9EggeQgjEXE0znEre0PekL4g30VROMAs5LMFtM55TCfey788DgBwWfgBQIEKpOi u1iAEOIqLq6/Vk0o12UbciJNHOwvi/GnnZ0UP17yINDJeBAwz0dxU6vUGq/IbgCOn70nlklV rRI6j1ySaykutwoQ6h2Aun529Xv2fVQd2Sm4XeDnAiHQG8Xew/vi7vbh7ndP0lb1uNGPa92U bi3wdNa0exOAzgzFBEtvSrW6bam/64DUGmeus7GDbThBahX/4Ztifbanh8vvcpyexV1eSGvo BPLOCyB2kFtKXcjwAIBodnNZO0MO58cCwS1Jhwx48mL/4P5CBuw//31CBhip3jtSBNUvgssT WkAjGNm01nqM/JdwxPGcJ9Prmbi/z4OtciHY++6774I3YlVicbUMSuez6DIaBd9/GUX0639f TuajaDCEXBU/3HOuCivsgBDHz8SVKBV9QH//j22Iggo1ONQEhPJahBxjCfINgx70yPgos8EM UStolkBLKfAYs/YKgSAEgYBKIHrFRKBrIK7hk5ko0J/Zpzi2vyZ0U6UYNwmEX0Lx5yhz/Jhl aBh9TMIIUiYLKQgy0ifxXLeJH3uTxXhuDnc8EYDhLO596Yd4mCTp0vhqGvfEEWIBQJMQ4S28 6M2Hxsj75yFfaYyPvVk0FztqGvX1R9XqbGJ2Sd55kK0zvvJ817O60bI48oFVkdMf9M12R9EV zQsW2Czojc15zSfzaBgm8WcPHQi28sn8ewZpiI2qcDpHGIfX+s5Zty1sYWwV6EUC4geIPTP7 Elvj5trmaBCrNv5vDAF+CZao2X44jiKznz4QNKjqdB/4aTj5aoIlbr1kspj1Yqcmf+S6N9og I3/xxGy+mPgRNAkrGU8ujK84qmg4tUYx7M0QFCRGiKo8mhpbLxSUSyRhrcuXHmSRhu+JvY6w 3eHzRahpw79gfROE8SFgevbem2g68RIObQyFo2D8lTO1E/Jsg5dlCytZCqeyMbulQL7AmXr2 mAVbGEwH8XjuKfgSQpi48GIQDylTlrV3JmMOtwdbBt3Cbb5C6mPIPDaf4H96qJi0sDONx7jh ILhVzA7V9iCIKm7I6gbcM0hzlU9Mw8nHCWaWz9xg+ImHKChh3/t1z/t1V6+eVpAvpr6vahOA YciSISehczQh/4hm/TSvtRX6OR3TZ1sd7/tug8uZ0tDRBuUIE5NnDt4zcnq2VR9v+DkyHwlW O6LrctkHb1QA2rF3tmDi2Vw+tQUZIBH0Cf77zsckjl0eb3P3PrF2s5r3nAFA9clk4TjPZuV4 DbRI9H4MLzjy+xGIwezfjAFZUb0CspPAYae8lPFC2kKbt10kIcDbX5LFufPR4jNyk33ZO3LF LRCAUkIUHMqiwOArqoV962+LjvgrPGqnPn4RTEYwuMV4INgRURAIhJVMBFDpRtATp1/fkOMS Gxvng3k4iqbvD/Y/IKoP9gnDEH9WfJeYxpeFdTc5E00vnF6GnPrTlYiAfeJ/0/wTwsYJ5FzE EUr+67Bv3uUk8wAvBz5sNzAESUwImhj/LexFhqBZxUfcFM/wMZnwrlzJZf1BDwTW5P3BB0vE /vL+0PjAtMAoFZvvSzxkgBsM1bUuTRC2gP6N3cYhlI3tRs9GS7hWAOua4hzx5YWz9JJn3FSZ QxgBmdoqdBH0zH0MQiiDnBKJ7m4D8k4MsMDOInTkh9CJKTIAYOBiQySfGIbyzskhWFkinVF4 kxkdZYC442BZNSNi/Ac1EHi2Zw8LL5JkWmEbS6BZgP4nPZ1g/shXyKnEvWWY+l1ca64yITCT uwHhwgxGOd1DYVb3UOY2noZwB+jCjDDdfOYAqDhrCFSKXWQXy1T23mIjVbtncEn+4JLcwSX5 g0vyB5csHxxcTbLHZqS1Txc6Weo9rTtp54+yylN7ygLw7Gyr3M7s7hmGlaP9yF+aOQQrgbqv lPOh+4p0fvOsUk5X7is2s4+77OrjcHIeDSUfwMS5Ttpxbu7hKB4Zn8zbHRwIqF0mNT6o32ot jM4J76qkUKHzQV3UICgq4NmoC9XwVVPcqGbXEj5198RkyNfun/2+uJlDW6ProD8ZRZylCbPC wO/BBVl+YKsq4R03P5xMpnyBcYumcyyBlr/C4za4zAWY93x7PqEE6KgayWhYlGQ0LMWP2bW3 lArFhR62ztwHMkyDiEG+Ho1GOzs7wdsYsuP8F2Q1oAynNZ3E5+slNANZtMF4xsSzqDLHxDFH gYncLEnFNViySrLkIdesypSxcY0Ej4ohL6sj7U5mcUgA5qUUGqFsREeBNebRfGHQbiwET1Ku vU8/ppBQC8mHgmQa9WKkRJdyKSAwJJ6mdnx1VH52Re04mAvZN2smoeanOJ7Char3CXw2T086 MmIXbiGL9mGryBgTdB0T9SHOF4bVxo6nKBgMkt5EIOLaT4uIdAXjpfV4Bi+FQrwRUOYuB4VT CLl00xpL1BcJaRSnfURGWvy+KVXqkG+afnsLCR4fPt4w1g91r2wWgtXlQ2CUQGYAthgRu12h FFlUEo9oASZBcj3uXc4mY6Ds83j+NY7HkvuoB29FR+GAmPpjyt5hLpataUImaGiiUGQGtcoA BVI0ApjOhgMua6LGBf4gjxWFQrZBFuQ3+wUpWtx1Nyb9c/jVVu0KNnVOxyTyP4S11ZrwGOyC lMrljaiHXYmL7kbSw9EKcXkjpk7I3GsmLlgglG+wVdfHqUDpoXsWYCTuUJPWr4SpGjyvij+B q84jGRMAgl8H4kyYzK53IHOPQfEYGNuW9or88XLq+2pJZsa2hfPL25YqSLWnStw2aS5vrH2z JC6pPSlTODaePEgiLuIv8bhvl2RNSlDAex1W8EPG8PLDi6ZHJ2Vn3RkLzEX8xRqdJS7bn7MG Lcri9zrK4QdTPnpoC89HJvc75zHQr9YoDInZ7tCQldMFLCoW1R/Upj2YxDOYRA8mSQ8myRpM kjWYxBxMYg3GGQqfAMl7M8ojpPoxo05qOuhqIkAm1tXPK0lq2ZXkfZT+/t4IHvnBPGpncRwq KcwDpVvpn3sbF5+T4WT+PhXM0OxGQrHgmwksX9U8VHfRm5LOyDMIWfbeCdVotKqqW2yAgpVi 6npMkDWBA4stTOZzTNOX3l6xHxPi83t2Jv1gKzj1M9+V77zFNQA4OFrNJswxCunADpeQeMcm ZXY6sd6n41+6y2pXcOblFPIElHbhjM/oETx4irOgNxmBJCnOIrR4AtFpBi8iyTwJQJLDZLaG AgJvDSHIZKA9/NX/WoRIHKJKz1vtIaTAUqMia9RoNoOEj5i/heJdgGnQl0F/EQ1Rr5aAbJzM J2AlgGmUAPLjRIg4czrcA2V7tROUhslEHXpw/E2nME0pZJyWyts/nJSlcWuszFp18iOUjrEP eZTO/439vn3bCLaekyVfoagV10/ZuG9AwxNdKNtZU45hHdR7yyvgAwvtLFixXP7ecgv4YAj2 +GwA3izijjQM9ESKwYFhYriBTJeEaTEBQhIYXQ4u+I9oDmIwJqgWdKkg9jWETK/cDxTp8iOV kKY4KaIh7aJkJ/vg/BgCIWwh10WJ0EKHEhKXa0t9a2NTkpO66lcp+yMyn/M2QiEUlR1SiYmH 5+yz0cdYDIlTvAD3S6BJ/CV7HPJX5Aiy1fFihEA5W4H+lJU8ulBxgzBKLAXg3CpyRUBzQlJV 8NHsxNZ2jkNLoyvumOOY10X2jRdWGKp5yfUDDJcByHthDghnXg17Ys5pQL1GwUPxX6PESfOC JWL7Y84WXDf4LUv3CzXwYPnVWmqZCw0ao3OpH8hHWiMTDR5XnIQn42SeRx9DIREm713TeUsL XB9Q6sAv4t7fB/e5Vok2Ne8bda97v7f/DFKh/Qo7ESw/i2jRif/u47+H+O9z/PekiIbL+O+z IlXZw6K9Y/y3gv9W8V8E3j/Af5/gv0+5yv4z/PM7/LeE/2L1/TL+i43sYyMHe1zlAAdzgK0d 4JAOsM2Dp/gvNnWATR2UucohAh8i2CGCHWK/hwh8iMCH2O+hqoJdH2LXTxAJT7DfJ9jUE+z3 CTb4RM7lCbb2BFt7guN/isBPEewp9vsU+336HVd5isBPseunVAX7fYr9PsN+n2G/zw64yjPs +hm2+QzbfIb9PsOmnmEjz3FdnkuMPccWnmPF57hGz3FFvkOw73BI3+H37465ync4jO9wGN8h cAnnUsJ+S9hvCSuW5FxKOIASzqWEwyhhIyVs5BjncowjOZZzOcYhHWObx9jmMc7lGJs6xkbK 2G/5CVcpI1gZuy4jcBmBy9hvmapgv+UqV6lg1xXsuoKtVbDfCvZbwQYr2FSlJKtgO1XETxWr V7F6FStWEVeQdObmyGeGKY3wYJv9fyx8RELq8QIA --4ZLFUWh1odzi/v6L-- From tgraf@suug.ch Sun Feb 6 10:53:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 10:54:05 -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 j16Irwai010031 for ; Sun, 6 Feb 2005 10:53:58 -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 2D8D5F; Sun, 6 Feb 2005 19:53:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5DAF21C0EA; Sun, 6 Feb 2005 19:54:17 +0100 (CET) Date: Sun, 6 Feb 2005 19:54:17 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-ID: <20050206185417.GU31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050128230327.GV31837@postel.suug.ch> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 595 Lines: 15 > NLMSG_GOODSIZE specifies a good default size for the skb tailroom > used in netlink messages when the size is unknown at the time of > the allocation. > > The current value doesn't make much sense anymore because > skb_shared_info isn't taken into account which means that > depending on the architecture NLMSG_GOOSIZE can exceed PAGE_SIZE > resulting in a waste of almost a complete page. > > Using SKB_MAXORDER solves this potential leak at the cost of > slightly smaller but safer sizes for some architectures. > > Signed-off-by: Thomas Graf Dave, did you get this one? From rkagan@mail.ru Sun Feb 6 11:20:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 11:20:44 -0800 (PST) Received: from Apachihuilliztli.mtu.ru (apachihuilliztli.mtu.ru [195.34.32.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16JKbV9011298 for ; Sun, 6 Feb 2005 11:20:39 -0800 Received: from umail.ru (umail.mtu.ru [195.34.32.101]) by Apachihuilliztli.mtu.ru (Postfix) with ESMTP id 045834DF0A2; Sun, 6 Feb 2005 22:19:16 +0300 (MSK) (envelope-from rkagan@mail.ru) Received: from [83.237.53.120] (HELO localhost) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP id 397882792; Sun, 06 Feb 2005 22:19:16 +0300 Date: Sun, 6 Feb 2005 22:19:18 +0300 From: Roman Kagan To: chas3@users.sourceforge.net Cc: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org Subject: Re: [Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated) Message-ID: <20050206191918.GA2369@katya> Mail-Followup-To: Roman Kagan , chas3@users.sourceforge.net, netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, usbatm@lists.infradead.org References: <20050204201327.GA2439@katya> <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502060133.j161XIj3007281@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.7i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: rkagan@mail.ru Precedence: bulk X-list: netdev Content-Length: 908 Lines: 20 On Sat, Feb 05, 2005 at 08:33:18PM -0500, chas williams - CONTRACTOR wrote: > In message <20050204201327.GA2439@katya>,Roman Kagan writes: > >initializing atm_dev. I suspect the only way to fix it is to split the > >atm_dev initialization into two stages, allocation and registration, as > >it is done for net_device. > > yeah which is why i just wanted to convert atm_dev to just be a netdevice. > the code is already written and "stable". Is it publically available? Linux-ATM CVS appears to contain no kernelspace code. I'm just curious how atm_dev attributes are mapped to net_device's, which doesn't look easy with the current atm_dev and net_device. Also, is it scheduled for inclusion in the mainline any time soon? If it is, maybe we shouldn't create an atm-specific user-visible interface in sysfs and hotplug which is going to be obsoleted by the net generic one in the near future? Roman. From hadi@cyberus.ca Sun Feb 6 11:49:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 11:49:16 -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 j16JnBg1012398 for ; Sun, 6 Feb 2005 11:49:12 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CxsP6-0003ws-Oi for netdev@oss.sgi.com; Sun, 06 Feb 2005 14:49:08 -0500 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 1CxsP4-0005tJ-V0; Sun, 06 Feb 2005 14:49:07 -0500 Subject: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-hXDhNYmEsldW+1l6It/N" Organization: jamalopolous Message-Id: <1107719343.1055.22.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 14:49:04 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 Content-Length: 3521 Lines: 130 --=-hXDhNYmEsldW+1l6It/N Content-Type: text/plain Content-Transfer-Encoding: 7bit bug is around since 2.1.x; never cared about chasing it until now because it is affecting someone i know. Dave, please apply. I will prepare a 2.4.x version. To see the problem: tc qdisc add dev eth0 ingress #add two filters at different prio levels tc filter add dev eth0 parent ffff: protocol ip prio 6 \ u32 match ip src 10.0.0.210/32 flowid 1:16 # tc filter add dev eth0 parent ffff: protocol ip prio 7 \ u32 match ip src 10.0.0.144/32 flowid 1:15 #now list them.. root@jdev:/# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 801: ht divisor 1 filter protocol ip pref 6 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801: ht divisor 1 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 filter protocol ip pref 7 u32 fh 800: ht divisor 1 filter protocol ip pref 7 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 each filter is listed in each priority. So if you had 5 rules in 5 prios (which is where sherlock started) you see 25 outputs. AFTER FIX: --------- root@jdev:/usr/src# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 match 0a0000d2/ffffffff at 12 filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 match 0a000090/ffffffff at 12 cheers, jamal --=-hXDhNYmEsldW+1l6It/N Content-Disposition: attachment; filename=u32multi_p Content-Type: text/plain; name=u32multi_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 2611-rc3+bk3/net/sched/cls_api.c 2005/02/06 16:28:26 1.1 +++ 2611-rc3+bk3/net/sched/cls_api.c 2005/02/06 16:41:47 @@ -326,6 +326,7 @@ { struct tcmsg *tcm; struct nlmsghdr *nlh; + int ret; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); @@ -339,8 +340,11 @@ tcm->tcm_handle = fh; if (RTM_DELTFILTER != event) { tcm->tcm_handle = 0; - if (tp->ops->dump && tp->ops->dump(tp, fh, skb, tcm) < 0) - goto rtattr_failure; + if (tp->ops->dump) { + ret = tp->ops->dump(tp, fh, skb, tcm); + if (ret < 0) + goto rtattr_failure; + } } nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -348,6 +352,8 @@ nlmsg_failure: rtattr_failure: skb_trim(skb, b - skb->data); + if (ret == -ENOENT) + return skb->len; return -1; } --- 2611-rc3+bk3/net/sched/cls_u32.c 2005/02/06 16:30:44 1.1 +++ 2611-rc3+bk3/net/sched/cls_u32.c 2005/02/06 16:33:13 @@ -76,6 +76,7 @@ char indev[IFNAMSIZ]; #endif u8 fshift; + u32 prio; struct tcf_result res; struct tc_u_hnode *ht_down; #ifdef CONFIG_CLS_U32_PERF @@ -641,6 +642,7 @@ memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; n->handle = handle; + n->prio = tp->prio; { u8 i = 0; u32 mask = s->hmask; @@ -736,6 +738,9 @@ if (n == NULL) return skb->len; + if (n->prio != tp->prio) + return -ENOENT; + t->tcm_handle = n->handle; rta = (struct rtattr*)b; --=-hXDhNYmEsldW+1l6It/N-- From akpm@osdl.org Sun Feb 6 12:26:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:26:20 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16KQEHU017228 for ; Sun, 6 Feb 2005 12:26:14 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id j16KQ8l21411; Sun, 6 Feb 2005 12:26:08 -0800 Date: Sun, 6 Feb 2005 12:26:04 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: mh+kernel-bugzilla@zugschlus.de Subject: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Message-Id: <20050206122604.74a41796.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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2004 Lines: 50 Begin forwarded message: Date: Sun, 6 Feb 2005 04:08:01 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses http://bugme.osdl.org/show_bug.cgi?id=4177 Summary: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Kernel Version: 2.6.current, 2.4.current Status: NEW Severity: low Owner: acme@conectiva.com.br Submitter: mh+kernel-bugzilla@zugschlus.de This wishlist item is mostly relevant to German users. In Germany, Deutsche Telekom has a near monopoly regarding DSL connections to residential homes. They are, however, required, to resell their network to other ISPs which has led to a rather interesting combination of Internet tariffs and feature sets available via Deutsche Telekom T-DSL connections. Technical Basis for the T-DSL customer interface is PPPoE over a bridged ATM session, so it is technically possible to have multiple PPPoE sessions on the same line, allowing concurrent use of more than a single ISP which might be interesting with special interest services like streaming, fixed IP address and/or flat rate. However, Deutsche Telekom technically forbids multiple PPPoE sessions originating from a single MAC address, so one needs multiple network interfaces to originate the PPPoE sessions from. Sven Geggus has a patch against rp-pppoed, which allows to fake the sending MAC address for additional PPPoE sessions, circumventing the artificially introduced limitation of the T-DSL connection. The patch is available on http://geggus.net/sven/rp-pppoe-fakemac.diff Please consider adding that possibility to the kernel PPPoE code as well. Greetings Marc ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From 64vn@cardvn.net Sun Feb 6 12:39:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:39:56 -0800 (PST) Received: from isp-go.FPT.NET (isp-go.fpt.net [210.245.0.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Kdltw017955 for ; Sun, 6 Feb 2005 12:39:48 -0800 Received: from isp-mta2.fpt.vn ([210.245.0.151]) by isp-go.FPT.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 03:39:40 +0700 Received: from [203.210.206.111] by isp-mta2.fpt.vn [210.245.0.151] Message-ID: <4206808A.1050304@cardvn.net> Date: Mon, 07 Feb 2005 03:39:38 +0700 From: Nguyen Dinh Nam <64vn@cardvn.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses References: <20050206122604.74a41796.akpm@osdl.org> In-Reply-To: <20050206122604.74a41796.akpm@osdl.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2005 20:39:40.0499 (UTC) FILETIME=[FB3CF230:01C50C8B] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: 64vn@cardvn.net Precedence: bulk X-list: netdev Content-Length: 2297 Lines: 60 I have another situation - there are 2 different PPPoE access concentrators available on 1 interface. So I want to be able to specify the MAC address (or AC Name, or Service Name) of the AC to connect to Thanks Andrew Morton wrote: >Begin forwarded message: > >Date: Sun, 6 Feb 2005 04:08:01 -0800 >From: bugme-daemon@osdl.org >To: bugme-new@lists.osdl.org >Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses > > >http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > >This wishlist item is mostly relevant to German users. In >Germany, Deutsche Telekom has a near monopoly regarding DSL >connections to residential homes. They are, however, required, to >resell their network to other ISPs which has led to a rather >interesting combination of Internet tariffs and feature sets available >via Deutsche Telekom T-DSL connections. > >Technical Basis for the T-DSL customer interface is PPPoE over a >bridged ATM session, so it is technically possible to have multiple >PPPoE sessions on the same line, allowing concurrent use of more than >a single ISP which might be interesting with special interest services >like streaming, fixed IP address and/or flat rate. > >However, Deutsche Telekom technically forbids multiple PPPoE sessions >originating from a single MAC address, so one needs multiple network >interfaces to originate the PPPoE sessions from. > >Sven Geggus has a patch against rp-pppoed, which allows to fake the >sending MAC address for additional PPPoE sessions, circumventing the >artificially introduced limitation of the T-DSL connection. The patch >is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > >Please consider adding that possibility to the kernel PPPoE code as well. > >Greetings >Marc > >------- 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 Sun Feb 6 12:44:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:44:27 -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 j16KiMmm018501 for ; Sun, 6 Feb 2005 12:44:23 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxtGW-0005SO-PW for netdev@oss.sgi.com; Sun, 06 Feb 2005 15:44:20 -0500 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 1CxtGU-0003tG-Ez; Sun, 06 Feb 2005 15:44:18 -0500 Subject: 2.4.29 version: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> References: <1107719343.1055.22.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-i+I4Hm8GUCMTgdvgQnby" Organization: jamalopolous Message-Id: <1107722655.1054.24.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 15:44:15 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2021 Lines: 84 --=-i+I4Hm8GUCMTgdvgQnby Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-02-06 at 14:49, jamal wrote: > bug is around since 2.1.x; never cared about chasing it until now > because it is affecting someone i know. > Dave, please apply. I will prepare a 2.4.x version. > Attached. cheers, jamal --=-i+I4Hm8GUCMTgdvgQnby Content-Disposition: attachment; filename=p2429 Content-Type: text/plain; name=p2429; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- cls_api.c.orig 2004-02-18 08:36:32.000000000 -0500 +++ cls_api.c 2005-02-06 12:21:32.976531360 -0500 @@ -289,6 +289,7 @@ { struct tcmsg *tcm; struct nlmsghdr *nlh; + int ret; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); @@ -300,14 +301,19 @@ tcm->tcm_handle = 0; tcm->tcm_info = TC_H_MAKE(tp->prio, tp->protocol); RTA_PUT(skb, TCA_KIND, IFNAMSIZ, tp->ops->kind); - if (tp->ops->dump && tp->ops->dump(tp, fh, skb, tcm) < 0) - goto rtattr_failure; + if (tp->ops->dump) { + ret = tp->ops->dump(tp, fh, skb, tcm); + if (ret < 0) + goto rtattr_failure; + } nlh->nlmsg_len = skb->tail - b; return skb->len; nlmsg_failure: rtattr_failure: skb_trim(skb, b - skb->data); + if (ret == -ENOENT) + return skb->len; return -1; } --- cls_u32.c.orig 2004-11-17 06:54:22.000000000 -0500 +++ cls_u32.c 2005-02-06 12:25:31.000346240 -0500 @@ -61,6 +61,7 @@ #ifdef CONFIG_NET_CLS_POLICE struct tcf_police *police; #endif + u32 prio; struct tcf_result res; struct tc_u_hnode *ht_down; struct tc_u32_sel sel; @@ -577,6 +578,7 @@ memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key)); n->ht_up = ht; n->handle = handle; + n->prio = tp->prio; err = u32_set_parms(tp->q, base, ht, n, tb, tca[TCA_RATE-1]); if (err == 0) { struct tc_u_knode **ins; @@ -639,6 +641,9 @@ if (n == NULL) return skb->len; + if (n->prio != tp->prio) + return -ENOENT; + t->tcm_handle = n->handle; rta = (struct rtattr*)b; --=-i+I4Hm8GUCMTgdvgQnby-- From acme@conectiva.com.br Sun Feb 6 12:48:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:48:26 -0800 (PST) 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 j16KmJAw019037 for ; Sun, 6 Feb 2005 12:48:20 -0800 Received: from [200.138.51.5] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1CxsbT-00067Q-00; Sun, 06 Feb 2005 18:01:56 -0200 Received: from [192.168.1.6] (amd64.kerneljanitors.org [192.168.1.6]) by oops.ghostprotocols.net (Postfix) with ESMTP id 511A41462D; Sun, 6 Feb 2005 18:48:15 -0200 (BRST) Message-ID: <420683CB.2010205@conectiva.com.br> Date: Sun, 06 Feb 2005 18:53:31 -0200 From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. User-Agent: Mozilla Thunderbird 1.0 (X11/20041220) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: mostrows@speakeasy.net Cc: Networking Team Subject: Re: [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses References: <200502061207.j16C7UOB009882@fire-1.osdl.org> In-Reply-To: <200502061207.j16C7UOB009882@fire-1.osdl.org> X-Enigmail-Version: 0.86.1.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 version 0.81, clamav-milter version 0.81b 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: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 1862 Lines: 44 bugme-daemon@osdl.org escreveu: > http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > > This wishlist item is mostly relevant to German users. In > Germany, Deutsche Telekom has a near monopoly regarding DSL > connections to residential homes. They are, however, required, to > resell their network to other ISPs which has led to a rather > interesting combination of Internet tariffs and feature sets available > via Deutsche Telekom T-DSL connections. > > Technical Basis for the T-DSL customer interface is PPPoE over a > bridged ATM session, so it is technically possible to have multiple > PPPoE sessions on the same line, allowing concurrent use of more than > a single ISP which might be interesting with special interest services > like streaming, fixed IP address and/or flat rate. > > However, Deutsche Telekom technically forbids multiple PPPoE sessions > originating from a single MAC address, so one needs multiple network > interfaces to originate the PPPoE sessions from. > > Sven Geggus has a patch against rp-pppoed, which allows to fake the > sending MAC address for additional PPPoE sessions, circumventing the > artificially introduced limitation of the T-DSL connection. The patch > is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > > Please consider adding that possibility to the kernel PPPoE code as well. > > Greetings > Marc > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > From hadi@cyberus.ca Sun Feb 6 12:51:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 12:51:10 -0800 (PST) Received: from mx04.cyberus.ca (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Kp57l019573 for ; Sun, 6 Feb 2005 12:51:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cyberus.ca with esmtp (Exim 4.30) id 1CxtMw-0007dd-IE for netdev@oss.sgi.com; Sun, 06 Feb 2005 13:50:58 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CxtMy-0004bz-S3; Sun, 06 Feb 2005 15:51:01 -0500 Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses From: jamal Reply-To: hadi@cyberus.ca To: Andrew Morton Cc: netdev@oss.sgi.com, mh+kernel-bugzilla@zugschlus.de In-Reply-To: <20050206122604.74a41796.akpm@osdl.org> References: <20050206122604.74a41796.akpm@osdl.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107723057.1055.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 15:50:57 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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 Content-Length: 2351 Lines: 61 Does that patch help at all? Seems to me all it enables is session setup, but after that what happens? Do packets go out with the MAC address you just spoofed for the data as well? cheers, jamal On Sun, 2005-02-06 at 15:26, Andrew Morton wrote: > Begin forwarded message: > > Date: Sun, 6 Feb 2005 04:08:01 -0800 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses > > > http://bugme.osdl.org/show_bug.cgi?id=4177 > > Summary: Please consider adding possibility to have multiple > PPPoE sessions with different MAC addresses > Kernel Version: 2.6.current, 2.4.current > Status: NEW > Severity: low > Owner: acme@conectiva.com.br > Submitter: mh+kernel-bugzilla@zugschlus.de > > > This wishlist item is mostly relevant to German users. In > Germany, Deutsche Telekom has a near monopoly regarding DSL > connections to residential homes. They are, however, required, to > resell their network to other ISPs which has led to a rather > interesting combination of Internet tariffs and feature sets available > via Deutsche Telekom T-DSL connections. > > Technical Basis for the T-DSL customer interface is PPPoE over a > bridged ATM session, so it is technically possible to have multiple > PPPoE sessions on the same line, allowing concurrent use of more than > a single ISP which might be interesting with special interest services > like streaming, fixed IP address and/or flat rate. > > However, Deutsche Telekom technically forbids multiple PPPoE sessions > originating from a single MAC address, so one needs multiple network > interfaces to originate the PPPoE sessions from. > > Sven Geggus has a patch against rp-pppoed, which allows to fake the > sending MAC address for additional PPPoE sessions, circumventing the > artificially introduced limitation of the T-DSL connection. The patch > is available on http://geggus.net/sven/rp-pppoe-fakemac.diff > > Please consider adding that possibility to the kernel PPPoE code as well. > > Greetings > Marc > > ------- 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 Sun Feb 6 13:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:03:11 -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 j16L33OI020273 for ; Sun, 6 Feb 2005 13:03:04 -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 1CxtY4-0006Rz-00; Mon, 07 Feb 2005 08:02:28 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CxtXS-0006Iq-00; Mon, 07 Feb 2005 08:01:50 +1100 Date: Mon, 7 Feb 2005 08:01:50 +1100 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, mirko.parthey@informatik.tu-chemnitz.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0) Message-ID: <20050206210150.GA24206@gondor.apana.org.au> References: <20050205064643.GA29758@gondor.apana.org.au> <20050205104559.GA30981@gondor.apana.org.au> <20050206114145.GA20883@gondor.apana.org.au> <20050206.213018.92031627.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206.213018.92031627.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 543 Lines: 15 On Sun, Feb 06, 2005 at 09:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()? Great, that definitely fixes the local address problem. I'm not sure about anycast routes though. Who's going to delete them when the real device goes down? 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 Feb 6 13:15:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:15:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LFi8K021157 for ; Sun, 6 Feb 2005 13:15:45 -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 1CxtdR-0001vM-00; Sun, 06 Feb 2005 13:08:01 -0800 Date: Sun, 6 Feb 2005 13:08:00 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETLINK: Use SKB_MAXORDER to calculate NLMSG_GOODSIZE Message-Id: <20050206130800.7b775e1a.davem@davemloft.net> In-Reply-To: <20050206185417.GU31837@postel.suug.ch> References: <20050128230327.GV31837@postel.suug.ch> <20050206185417.GU31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.0 (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 version 0.81, clamav-milter version 0.81b 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: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 188 Lines: 7 On Sun, 6 Feb 2005 19:54:17 +0100 Thomas Graf wrote: > Dave, did you get this one? Yes I did. I'm just busy with all the memory barrier stuff this past few days, sorry. From mh+kernel-bugzilla@zugschlus.de Sun Feb 6 13:25:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:25:11 -0800 (PST) Received: from torres.int.l21.ma.zugschlus.de (Debian-exim@5301d.unt0.torres.l21.ma.zugschlus.de [217.151.83.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LP7xY021833 for ; Sun, 6 Feb 2005 13:25:08 -0800 Received: from mh by torres.int.l21.ma.zugschlus.de with local (Exim 4.44) id 1Cxtts-0006UD-9z; Sun, 06 Feb 2005 22:25:00 +0100 Date: Sun, 6 Feb 2005 22:25:00 +0100 From: Marc Haber To: jamal Cc: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses Message-ID: <20050206212500.GF17682@torres.l21.ma.zugschlus.de> References: <20050206122604.74a41796.akpm@osdl.org> <1107723057.1055.28.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107723057.1055.28.camel@jzny.localdomain> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: mh+kernel-bugzilla@zugschlus.de Precedence: bulk X-list: netdev Content-Length: 806 Lines: 21 On Sun, Feb 06, 2005 at 03:50:57PM -0500, jamal wrote: > Does that patch help at all? It helps with the user space pppoed, yes. > Seems to me all it enables is session setup, but after that what > happens? Do packets go out with the MAC address you just spoofed > for the data as well? With user space pppoed, yes. When applied to the normal pppd, using kernel pppoe, only session setup goes out with the fake MAC, and this doesn't lead to a useable pppoe session, of course. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From tgraf@suug.ch Sun Feb 6 13:29:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:29:13 -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 j16LT8le022419 for ; Sun, 6 Feb 2005 13:29: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 CF956F; Sun, 6 Feb 2005 22:28:45 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8AA6E1C0EA; Sun, 6 Feb 2005 22:29:28 +0100 (CET) Date: Sun, 6 Feb 2005 22:29:28 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-ID: <20050206212928.GV31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 724 Lines: 13 * jamal <1107719343.1055.22.camel@jzny.localdomain> 2005-02-06 14:49 > > bug is around since 2.1.x; never cared about chasing it until now > because it is affecting someone i know. Good catch, I've put a workaround for this into libnl a while back. I wasn't sure whether it's supposed to be a feature or not. ;-> Another quite anoying detail is the fact that cbq uses the same handle for both the root qdisc and root class which makes it impossible to uniquely assign filters attached to it, i.e. listing filters based on parent == XX: && dev == %DEV will result in the filters being listed for both the qdisc and the class. I haven't found a fix that wouldn't break many scripts so if you have a good idea, go ahead. ;-> From kaber@trash.net Sun Feb 6 13:40:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:40:32 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LePBe023114 for ; Sun, 6 Feb 2005 13:40:26 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1Cxu8A-00027r-D6; Sun, 06 Feb 2005 22:39:46 +0100 Message-ID: <42068EA2.6030507@trash.net> Date: Sun, 06 Feb 2005 22:39:46 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> In-Reply-To: <1107719343.1055.22.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------060009020002090402080907" X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2700 Lines: 89 This is a multi-part message in MIME format. --------------060009020002090402080907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit jamal wrote: >bug is around since 2.1.x; never cared about chasing it until now >because it is affecting someone i know. >Dave, please apply. I will prepare a 2.4.x version. > The patch is wrong. The "divisor"-lines are missing in the output with your patch and it only hides the real error. ->walk is supposed to walk all filters of the given priority/protocol, but u32 walks all filters. This patch fixes it. Output with new patch: filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 0 success 0) match 0a0000d2/ffffffff at 12 (success 0 ) filter protocol ip pref 7 u32 filter protocol ip pref 7 u32 fh 801: ht divisor 1 filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:15 (rule hit 0 success 0) match 0a000090/ffffffff at 12 (success 0 ) Signed-off-by: Patrick McHardy BTW: u32_walk seems to have another bug, it uses tcf_walker->count and tcf_walker->skip for skipping over both hnodes and knodes and doesn't skip hnodes properly at all. I'll have a look at this now. Regards Patrick >AFTER FIX: >--------- > >root@jdev:/usr/src# tc -s filter show parent ffff: dev eth0 >filter protocol ip pref 6 u32 >filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 >flowid 1:16 > match 0a0000d2/ffffffff at 12 > filter protocol ip pref 7 u32 > filter protocol ip pref 7 u32 fh 801::800 order 2048 key ht 801 bkt 0 >flowid 1:15 > match 0a000090/ffffffff at 12 > > > --------------060009020002090402080907 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/sched/cls_u32.c 1.25 vs edited ===== --- 1.25/net/sched/cls_u32.c 2005-01-11 20:25:16 +01:00 +++ edited/net/sched/cls_u32.c 2005-02-06 22:20:33 +01:00 @@ -91,6 +91,7 @@ { struct tc_u_hnode *next; u32 handle; + u32 prio; struct tc_u_common *tp_c; int refcnt; unsigned divisor; @@ -323,6 +324,7 @@ root_ht->divisor = 0; root_ht->refcnt++; root_ht->handle = tp_c ? gen_new_htid(tp_c) : 0x80000000; + root_ht->prio = tp->prio; if (tp_c == NULL) { tp_c = kmalloc(sizeof(*tp_c), GFP_KERNEL); @@ -703,6 +705,8 @@ return; for (ht = tp_c->hlist; ht; ht = ht->next) { + if (ht->prio != tp->prio) + continue; if (arg->count >= arg->skip) { if (arg->fn(tp, (unsigned long)ht, arg) < 0) { arg->stop = 1; --------------060009020002090402080907-- From hadi@cyberus.ca Sun Feb 6 13:42:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:42:25 -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 j16LgLcN023554 for ; Sun, 6 Feb 2005 13:42:21 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxuAd-00031k-2N for netdev@oss.sgi.com; Sun, 06 Feb 2005 16:42:19 -0500 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 1CxuAa-0002Cq-Nw; Sun, 06 Feb 2005 16:42:17 -0500 Subject: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050206212928.GV31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107726133.1055.34.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 16:42:13 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 754 Lines: 20 On Sun, 2005-02-06 at 16:29, Thomas Graf wrote: > assign filters attached to it, i.e. listing filters based on > parent == XX: && dev == %DEV will result in the filters being listed > for both the qdisc and the class. I haven't found a fix that wouldn't > break many scripts so if you have a good idea, go ahead. ;-> I cant say ive run into this one - mostly i attach filters to root. Example script? BTW, cycles allow me to work on the eaction stuff today. So far ive come to the conclusion that whats really needed to simplify writting some actions is to just provide generic methods they can use without them necessarily knowing details. I hope to test later on, maybe write a simple action and its user apce piece, and post patch. cheers, jamal From hadi@cyberus.ca Sun Feb 6 13:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:45:20 -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 j16LjGRf024161 for ; Sun, 6 Feb 2005 13:45:16 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CxuDS-0004Pj-Er for netdev@oss.sgi.com; Sun, 06 Feb 2005 16:45:14 -0500 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 1CxuDP-0002Tv-3q; Sun, 06 Feb 2005 16:45:11 -0500 Subject: Re: Fw: [Bugme-new] [Bug 4177] New: Please consider adding possibility to have multiple PPPoE sessions with different MAC addresses From: jamal Reply-To: hadi@cyberus.ca To: Marc Haber Cc: Andrew Morton , netdev@oss.sgi.com In-Reply-To: <20050206212500.GF17682@torres.l21.ma.zugschlus.de> References: <20050206122604.74a41796.akpm@osdl.org> <1107723057.1055.28.camel@jzny.localdomain> <20050206212500.GF17682@torres.l21.ma.zugschlus.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107726307.1054.38.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 16:45:08 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 442 Lines: 15 On Sun, 2005-02-06 at 16:25, Marc Haber wrote: > On Sun, Feb 06, 2005 at 03:50:57PM -0500, jamal wrote: > > Does that patch help at all? > > It helps with the user space pppoed, yes. Remind me again: With user space pppoe if you have a web server that people access from outside world, all packets go to user space and then back to the kernel before hitting user space again? Only in such a case can i see this working ... cheers, jamal From kaber@trash.net Sun Feb 6 13:48:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:48:05 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16Lm1dq024733 for ; Sun, 6 Feb 2005 13:48:01 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CxuFX-00029N-0C; Sun, 06 Feb 2005 22:47:23 +0100 Message-ID: <4206906A.2060501@trash.net> Date: Sun, 06 Feb 2005 22:47:22 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> In-Reply-To: <20050206212928.GV31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 495 Lines: 15 Thomas Graf wrote: >Another >quite anoying detail is the fact that cbq uses the same handle for >both the root qdisc and root class which makes it impossible to uniquely >assign filters attached to it, i.e. listing filters based on >parent == XX: && dev == %DEV will result in the filters being listed >for both the qdisc and the class. > CBQ and HFSC only support filters attached to classes for exactly this reason :) Shouldn't make any difference from a users perspective. Regards Patrick From kaber@trash.net Sun Feb 6 13:55:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 13:55:54 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16LtnEa025506 for ; Sun, 6 Feb 2005 13:55:50 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1CxuNa-0006Cv-QS; Sun, 06 Feb 2005 22:55:42 +0100 Message-ID: <4206925E.8030107@trash.net> Date: Sun, 06 Feb 2005 22:55:42 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> In-Reply-To: <42068EA2.6030507@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com 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: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1207 Lines: 46 Patrick McHardy wrote: > The patch is wrong. The "divisor"-lines are missing in the output with > your patch and it only hides the real error. ->walk is supposed to walk > all filters of the given priority/protocol, but u32 walks all filters. > This patch fixes it. Output with new patch: The patch also applies to 2.4. Regards Patrick > >------------------------------------------------------------------------ > >===== net/sched/cls_u32.c 1.25 vs edited ===== >--- 1.25/net/sched/cls_u32.c 2005-01-11 20:25:16 +01:00 >+++ edited/net/sched/cls_u32.c 2005-02-06 22:20:33 +01:00 >@@ -91,6 +91,7 @@ > { > struct tc_u_hnode *next; > u32 handle; >+ u32 prio; > struct tc_u_common *tp_c; > int refcnt; > unsigned divisor; >@@ -323,6 +324,7 @@ > root_ht->divisor = 0; > root_ht->refcnt++; > root_ht->handle = tp_c ? gen_new_htid(tp_c) : 0x80000000; >+ root_ht->prio = tp->prio; > > if (tp_c == NULL) { > tp_c = kmalloc(sizeof(*tp_c), GFP_KERNEL); >@@ -703,6 +705,8 @@ > return; > > for (ht = tp_c->hlist; ht; ht = ht->next) { >+ if (ht->prio != tp->prio) >+ continue; > if (arg->count >= arg->skip) { > if (arg->fn(tp, (unsigned long)ht, arg) < 0) { > arg->stop = 1; > > From hadi@cyberus.ca Sun Feb 6 14:02:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:02:22 -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 j16M2Hxi026105 for ; Sun, 6 Feb 2005 14:02:18 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1CxuTx-0002Tx-M8 for netdev@oss.sgi.com; Sun, 06 Feb 2005 17:02:17 -0500 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 1CxuTt-0004BI-C6; Sun, 06 Feb 2005 17:02:13 -0500 Subject: Re: patch: annoying u32 double listing From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <42068EA2.6030507@trash.net> References: <1107719343.1055.22.camel@jzny.localdomain> <42068EA2.6030507@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1107727330.1053.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 17:02:10 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 468 Lines: 16 On Sun, 2005-02-06 at 16:39, Patrick McHardy wrote: > jamal wrote: > > >bug is around since 2.1.x; never cared about chasing it until now > >because it is affecting someone i know. > >Dave, please apply. I will prepare a 2.4.x version. > > > The patch is wrong. The "divisor"-lines are missing in the output with I should have caught that output missing divisor ;-> Dave please apply Patricks version. Should probably apply cleanly on 2.4.x as well. cheers, jamal From tgraf@suug.ch Sun Feb 6 14:11:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:12:01 -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 j16MBtfB026957 for ; Sun, 6 Feb 2005 14:11:55 -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 A583384; Sun, 6 Feb 2005 23:11:32 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 4FF2A1C0EA; Sun, 6 Feb 2005 23:12:15 +0100 (CET) Date: Sun, 6 Feb 2005 23:12:15 +0100 From: Thomas Graf To: Patrick McHardy Cc: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: annoying u32 double listing Message-ID: <20050206221215.GW31837@postel.suug.ch> References: <1107719343.1055.22.camel@jzny.localdomain> <20050206212928.GV31837@postel.suug.ch> <4206906A.2060501@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4206906A.2060501@trash.net> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 916 Lines: 19 * Patrick McHardy <4206906A.2060501@trash.net> 2005-02-06 22:47 > Thomas Graf wrote: > > >Another > >quite anoying detail is the fact that cbq uses the same handle for > >both the root qdisc and root class which makes it impossible to uniquely > >assign filters attached to it, i.e. listing filters based on > >parent == XX: && dev == %DEV will result in the filters being listed > >for both the qdisc and the class. > > > CBQ and HFSC only support filters attached to classes for exactly this > reason :) Shouldn't make any difference from a users perspective. I'm aware of it and that's not the problem. The problem is that if the user requests the filters attached to parent XX: he can't tell whether the qdisc or class parent is meant without checking for hardcoded qdisc kinds which makes it pretty much impossible to generate qdisc/class/filter trees in a generic way. It's just something anoying not a bug. From hadi@cyberus.ca Sun Feb 6 14:13:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Feb 2005 14:13:55 -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 j16MDme6027383 for ; Sun, 6 Feb 2005 14:13:49 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1Cxuf4-0001wv-Ig for netdev@oss.sgi.com; Sun, 06 Feb 2005 17:13:46 -0500 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 1Cxuf2-0005Ji-9g; Sun, 06 Feb 2005 17:13:44 -0500 Subject: instead of eaction From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-ib5mRFwAOsTDqQaOBM5K" Organization: jamalopolous Message-Id: <1107728020.1055.50.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Feb 2005 17:13:41 -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b 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: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 7877 Lines: 320 --=-ib5mRFwAOsTDqQaOBM5K Content-Type: text/plain Content-Transfer-Encoding: 7bit I think i am going to throw out the idea of eaction; instead j